# Prerequisites to enabling Runtime Monitoring
Prerequisites
To enable Runtime Monitoring and manage the GuardDuty security agent, you must meet the prerequisites for each resource type that you want to monitor for threat detection. Each resource type has different prerequisites. For example, GuardDuty supports different OS distributions based on the resource type.
When you want to monitor only Amazon EC2 resources, you will follow the prerequisites for Amazon EC2 instances. If at a later time, you choose to monitor Amazon EKS resources, you must follow the prerequisites specific to Amazon EKS clusters.
The following sections include prerequisites based on the resource type.
**Topics**
+ [
# Prerequisites for Amazon EC2 instance support
](prereq-runtime-monitoring-ec2-support.md)
+ [
# Prerequisites for Amazon Fargate (Amazon ECS only) support
](prereq-runtime-monitoring-ecs-support.md)
+ [
# Prerequisites for Amazon EKS cluster support
](prereq-runtime-monitoring-eks-support.md)
# Prerequisites for Amazon EC2 instance support
For EC2 instance
This section includes the prerequisites for monitoring runtime behavior of your Amazon EC2 instances. After these prerequisites are met, see [Enabling GuardDuty Runtime Monitoring](runtime-monitoring-configuration.md).
**Topics**
+ [
## Make EC2 instances SSM managed (for automated agent configuration only)
](#ssm-managed-prereq-ec2)
+ [
## Validate architectural requirements
](#validating-architecture-req-ec2)
+ [
## Validating your organization service control policy in a multi-account environment
](#validate-organization-scp-ec2)
+ [
## When using automated agent configuration
](#runtime-ec2-prereq-automated-agent)
+ [
## CPU and memory limit for GuardDuty agent
](#ec2-cpu-memory-limits-gdu-agent)
+ [
## Next step
](#next-step-after-prereq-ec2)
## Make EC2 instances SSM managed (for automated agent configuration only)
Make EC2 instances SSM managed (for automated agent only)
GuardDuty uses Amazon Systems Manager (SSM) to automatically deploy, install, and manage the security agent on your instances. If you plan to manually install and manage the GuardDuty agent, SSM is not required.
To manage your Amazon EC2 instances with Systems Manager, see [Setting up Systems Manager for Amazon EC2 instances](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) in the *Amazon Systems Manager User Guide*.
## Validate architectural requirements
The architecture of your OS distribution might impact how the GuardDuty security agent will behave. You must meet the following requirements before using Runtime Monitoring for Amazon EC2 instances:
+ Kernel support includes `eBPF`, `Tracepoints` and `Kprobe`. For CPU architectures, Runtime Monitoring supports AMD64 (`x64`) and ARM64 (Graviton2 and above)[1](#runtime-monitoring-ec2-graviton-2-support).
The following table shows the OS distribution that has been verified to support the GuardDuty security agent for Amazon EC2 instances.
[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
1. Runtime Monitoring for Amazon EC2 resources doesn't support the first generation Graviton instance such as A1 instance types.
1. Support for various operating systems - GuardDuty has verified Runtime Monitoring support for the operating distribution listed in the preceding table. While the GuardDuty security agent may run on operating systems not listed in the preceding table, the GuardDuty team cannot guarantee the expected security value.
1. For any kernel version, you must set the `CONFIG_DEBUG_INFO_BTF` flag to `y` (meaning *true*). This is required so that the GuardDuty security agent can run as expected.
1. For kernel versions 5.10 and earlier, the GuardDuty security agent uses locked memory in RAM (`RLIMIT_MEMLOCK`) to function as expected. If your system's `RLIMIT_MEMLOCK` value is set too low, GuardDuty recommends setting both hard and soft limits to at least 32 MB. For information about verifying and modifying the default `RLIMIT_MEMLOCK` value, see [Viewing and updating `RLIMIT_MEMLOCK` values](#runtime-monitoring-ec2-modify-rlimit-memlock).
1. For Ubuntu 24.04, the kernel versions 6.13 and 6.14 support EC2 agent versions only 1.9.2 and above.
+ Additional requirements - Only if you have Amazon ECS/Amazon EC2
For Amazon ECS/Amazon EC2, we recommend that you use the latest Amazon ECS-optimized AMIs (dated September 29, 2023 or later), or use Amazon ECS agent version v1.77.0.
### Viewing and updating `RLIMIT_MEMLOCK` values
When your system's `RLIMIT_MEMLOCK` limit is set too low, GuardDuty security agent may not perform as designed. GuardDuty recommends that both hard and soft limits must be at least 32 MB. If you don't update the limits, GuardDuty will be unable to monitor the runtime events for your resource. When `RLIMIT_MEMLOCK` is above the minimum stated limits, it becomes optional for you to update these limits.
You can modify the default `RLIMIT_MEMLOCK` value either before or after installing the GuardDuty security agent.
**To view `RLIMIT_MEMLOCK` values**
1. Run `ps aux | grep guardduty`. This will output the process ID (`pid`).
1. Copy the process ID (`pid`) from the output of the previous command.
1. Run `grep "Max locked memory" /proc/pid/limits` after replacing the `pid` with the process ID copied from the previous step.
This will display the maximum locked memory for running the GuardDuty security agent.
**To update `RLIMIT_MEMLOCK` values**
1. If the `/etc/systemd/system.conf.d/NUMBER-limits.conf` file exists, then comment out the line of `DefaultLimitMEMLOCK` from this file. This file sets a default `RLIMIT_MEMLOCK` with high priority, which overwrites your settings in the `/etc/systemd/system.conf` file.
1. Open the `/etc/systemd/system.conf` file and uncomment the line that has `#DefaultLimitMEMLOCK=`.
1. Update the default value by providing both hard and soft `RLIMIT_MEMLOCK` limits to at least 32MB. The update should look like this: `DefaultLimitMEMLOCK=32M:32M`. The format is `soft-limit:hard-limit`.
1. Run `sudo reboot`.
## Validating your organization service control policy in a multi-account environment
If you have set up a service control policy (SCP) to manage permissions in your organization, validate that permissions boundary allows the `guardduty:SendSecurityTelemetry` action. It is required for GuardDuty to support Runtime Monitoring across different resource types.
If you are a member account, connect with the associated delegated administrator. For information about managing SCPs for your organization, see [Service control policies (SCPs)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps.html).
## When using automated agent configuration
To [Use automated agent configuration (recommended)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2), your Amazon Web Services account must meet the following prerequisites:
+ When using inclusion tags with automated agent configuration, for GuardDuty to create an SSM association for a new instance, ensure that the new instance is SSM managed and shows up under **Fleet Manager** in the [https://console.amazonaws.cn/systems-manager/](https://console.amazonaws.cn/systems-manager/) console.
+ When using exclusion tags with automated agent configuration:
+ Add the `GuardDutyManaged`:`false` tag before configuring the GuardDuty automated agent for your account.
Ensure that you add the exclusion tag to your Amazon EC2 instances before you launch them. Once you have enabled automated agent configuration for Amazon EC2, any EC2 instance that launches without an exclusion tag will be covered under GuardDuty automated agent configuration.
+ Enable **Allow tags in metadata** setting for your instances. This setting is required because GuardDuty needs to read the exclusion tag from the instance metadata service (IMDS) to determine whether it should exclude the instance from agent installation. For more information, see [Enable access to tags in instance metadata](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) in the *Amazon EC2 User Guide*.
## CPU and memory limit for GuardDuty agent
CPU and memory limit
**CPU limit**
The maximum CPU limit for the GuardDuty security agent associated with Amazon EC2 instances is 10 percent of the total vCPU cores. For example, if your EC2 instance has 4 vCPU cores, then the security agent can use a maximum of 40 percent out of the total available 400 percent.
**Memory limit**
From the memory associated with your Amazon EC2 instance, there is a limited memory that the GuardDuty security agent can use.
The following table shows the memory limit.
[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
## Next step
The next step is to configure Runtime Monitoring and also manage the security agent (automatically or manually).
# Prerequisites for Amazon Fargate (Amazon ECS only) support
For Fargate (ECS only) cluster
This section includes the prerequisites for monitoring runtime behavior of your Fargate-Amazon ECS resources. After these prerequisites are met, see [Enabling GuardDuty Runtime Monitoring](runtime-monitoring-configuration.md).
**Topics**
+ [
## Validating architectural requirements
](#validating-architecture-req-ecs)
+ [
## Prerequisites for container image access
](#before-enable-runtime-monitoring-ecs)
+ [
## Validating your organization service control policy in a multi-account environment
](#validate-organization-scp-ecs)
+ [
## Validating role permissions and policy permissions boundary
](#guardduty-runtime-monitoring-ecs-permission-boundary)
+ [
## CPU and memory limits
](#ecs-runtime-agent-cpu-memory-limits)
## Validating architectural requirements
The platform that you use may impact how GuardDuty security agent supports GuardDuty in receiving the runtime events from your Amazon ECS clusters. You must validate that you're using one of the verified platforms.
**Initial considerations:**
The Amazon Fargate platform for your Amazon ECS clusters must be Linux. The corresponding platform version must be at least `1.4.0`, or `LATEST`. For more information about the platform versions, see [Linux platform versions](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/platform-linux-fargate.html) in the *Amazon Elastic Container Service Developer Guide*.
The Windows platform versions are not yet supported.
### Verified platforms
The OS distribution and CPU architecture impacts the support provided by the GuardDuty security agent. The following table shows the verified configuration for deploying the GuardDuty security agent and configuring Runtime Monitoring.
| OS distribution**[1](#runtime-monitoring-ecs-os-support)** | Kernel support | CPU architecture x64 (AMD64) | CPU architecture Graviton (ARM64) |
| --- | --- | --- | --- |
| Linux | eBPF, Tracepoints, Kprobe | Supported | Supported |
1Support for various operating systems - GuardDuty has verified Runtime Monitoring support for the operating distribution listed in the preceding table. While the GuardDuty security agent may run on operating systems not listed in the preceding table, the GuardDuty team cannot guarantee the expected security value.
## Prerequisites for container image access
The following prerequisites help you access the GuardDuty sidecar container image from the Amazon ECR repository.
### Permissions requirements
The task execution role requires certain Amazon Elastic Container Registry (Amazon ECR) permissions to download the GuardDuty security agent container image:
```
...
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
...
```
To further restrict the Amazon ECR permissions, you can add the Amazon ECR repository URI that hosts the GuardDuty security agent for Amazon Fargate (Amazon ECS only). For more information, see [Amazon ECR repository hosting GuardDuty agent](runtime-monitoring-ecr-repository-gdu-agent.md).
You can either use the [AmazonECSTaskExecutionRolePolicy](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/task_execution_IAM_role.html) managed policy or add the above permissions to your `TaskExecutionRole` policy.
### Task definition configuration
When creating or updating Amazon ECS services, you need to provide subnet information in your task definition:
Running the [CreateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_CreateService.html) and [UpdateService](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_UpdateService.html) APIs in the *Amazon Elastic Container Service API Reference* requires you to pass the subnet information. For more information, see [Amazon ECS task definitions](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/task_definitions.html) in the *Amazon Elastic Container Service Developer Guide*.
### Network connectivity requirements
You must ensure network connectivity to download the GuardDuty container image from Amazon ECR. This requirement is specific to GuardDuty because it uses Amazon ECR to host its security agent. Depending on your network configuration, you need to implement one of the following options:
**Option 1 - Using public network access (if available)**
If your Fargate tasks run in subnets with outbound internet access, no additional network configuration is required.
**Option 2 - Using Amazon VPC endpoints (for private subnets)**
If your Fargate tasks run in private subnets without internet access, you must configure VPC endpoints for ECR to ensure that the ECR repository URI that hosts the GuardDuty security agent is network accessible. Without these endpoints, tasks in private subnets cannot download the GuardDuty container image.
For VPC endpoint setup instructions, see [Create the VPC endpoints for Amazon ECR](https://docs.amazonaws.cn/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) in the *Amazon Elastic Container Registry User Guide*.
For information about enabling Fargate to download the GuardDuty container, see [Using Amazon ECR images with Amazon ECS](https://docs.amazonaws.cn/AmazonECR/latest/userguide/ECR_on_ECS.html) in the *Amazon Elastic Container Registry User Guide*.
### Security group configuration
The GuardDuty container images are in Amazon ECR and require Amazon S3 access. This requirement is specific to downloading container images from Amazon ECR. For tasks with restricted network access, you must configure your security groups to allow access to S3.
Add an outbound rule in your security group that allows traffic to the [S3 managed prefix list (`pl-xxxxxxxx`) on port 443](https://docs.amazonaws.cn/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security). To add an outbound rule, see [Configure security group rules](https://docs.amazonaws.cn/vpc/latest/userguide/working-with-security-group-rules.html) in the *Amazon VPC User Guide*.
To view your Amazon-managed prefix lists in the console or describe them by using Amazon Command Line Interface (Amazon CLI), see [Amazon-managed prefix lists](https://docs.amazonaws.cn/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) in the *Amazon VPC User Guide*.
## Validating your organization service control policy in a multi-account environment
This section explains how to validate your service control policy (SCP) settings to ensure Runtime Monitoring works as expected across your organization.
If you have set up one or more service control policies to manage permissions in your organization, you must validate that it doesn't deny the `guardduty:SendSecurityTelemetry` action. For information about how SCPs work, see [SCP evaluation](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) in the *Amazon Organizations User Guide*.
If you are a member account, connect with the associated delegated administrator. For information about managing SCPs for your organization, see [Service control policies (SCPs)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *Amazon Organizations User Guide*.
Perform the following steps for all the SCPs that you have set up in your multi-account environment:
**To validate `guardduty:SendSecurityTelemetry` is not denied in SCP**
1. Sign in to the Organizations console at [https://console.amazonaws.cn/organizations/](https://console.amazonaws.cn/organizations/). You must sign in as an IAM role, or sign in as the root user [(not recommended)](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) in the organization's management account.
1. In the left navigation pane, select **Policies**. Then, under **Supported policy types**, select **Service control policies**.
1. On the **Service control policies** page, choose the name of the policy that you want to validate.
1. On the policy's detail page, view the **Content** of this policy. Make sure that it doesn't deny the `guardduty:SendSecurityTelemetry` action.
The following SCP policy is an example for *not denying* the `guardduty:SendSecurityTelemetry` action:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"guardduty:SendSecurityTelemetry"
],
"Resource": "*"
}
]
}
```
------
If your policy denies this action, you must update the policy. For more information, see [Update a service control policy (SCP)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_policies_update.html#update_policy) in the *Amazon Organizations User Guide*.
## Validating role permissions and policy permissions boundary
Use the following steps to validate that the permissions boundaries associated with the role and its policy **doesn't** the restrict `guardduty:SendSecurityTelemetry` action.
**To view permissions boundary for roles and its policy**
1. Sign in to the Amazon Web Services Management Console and open the IAM console at [https://console.amazonaws.cn/iam/](https://console.amazonaws.cn/iam/).
1. In the left navigation pane, under **Access management**, choose **Roles**.
1. On the **Roles** page, select the role *`TaskExecutionRole`* that you may have created.
1. On the selected role's page, under the **Permissions** tab, expand the policy name associated with this role. Then, validate that this policy doesn't restrict `guardduty:SendSecurityTelemetry`.
1. If the **Permissions boundary** is set, then expand this section. Then, expand each policy to review that it doesn't restrict the `guardduty:SendSecurityTelemetry` action. The policy should appear similar to this [Example SCP policy](#ecs-runtime-scp-not-deny-policy-example).
As needed, perform one of the following actions:
+ To modify the policy, select **Edit**. On the **Modify permissions** page for this policy, update the policy in the **Policy editor**. Make sure that the JSON schema remains valid. Then, choose **Next**. Then, you can review and save the changes.
+ To change this permissions boundary and choose another boundary, choose **Change boundary**.
+ To remove this permissions boundary, choose **Remove boundary**.
For information about managing policies, see [Policies and permissions in Amazon Identity and Access Management](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
## CPU and memory limits
In the Fargate task definition, you must specify the CPU and memory value at the task level. The following table shows the valid combinations of task-level CPU and memory values, and the corresponding GuardDuty security agent maximum memory limit for the GuardDuty container.
[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html)
After you enable Runtime Monitoring and assess that the coverage status of your cluster is **Healthy**, you can set up and view the Container insight metrics. For more information, [Setting up monitoring on Amazon ECS cluster](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent).
The next step is to configure Runtime Monitoring and also configure the security agent.
# Prerequisites for Amazon EKS cluster support
For EKS cluster
This section includes the prerequisites for monitoring runtime behavior of your Amazon EKS resources. These prerequisites are crucial for the GuardDuty agent to function as expected. After these prerequisites are met, see [Enabling GuardDuty Runtime Monitoring](runtime-monitoring-configuration.md) to start monitoring your resources.
## Support for Amazon EKS features
Runtime Monitoring **supports** Amazon EKS clusters running on Amazon EC2 instances and Amazon EKS Auto Mode.
Runtime Monitoring **doesn't support** Amazon EKS clusters with Amazon EKS Hybrid Nodes, and those running on Amazon Fargate.
For information about these Amazon EKS features, see [What is Amazon EKS?](https://docs.amazonaws.cn/eks/latest/userguide/what-is-eks.html) in the **Amazon EKS User Guide**.
## Validating architectural requirements
The platform that you use may impact how GuardDuty security agent supports GuardDuty in receiving the runtime events from your EKS clusters. You must validate that you're using one of the verified platforms. If you're managing the GuardDuty agent manually, ensure that the Kubernetes version supports the GuardDuty agent version that is currently in use.
### Verified platforms
The OS distribution, kernel version, and CPU architecture affect the support provided by the GuardDuty security agent. Kernel support includes `eBPF`, `Tracepoints` and `Kprobe`. For CPU architectures, Runtime Monitoring supports AMD64 (`x64`) and ARM64(Graviton2 and above)[1](#runtime-monitoring-eks-graviton-2-support).
The following table shows the verified configuration for deploying the GuardDuty security agent and configuring EKS Runtime Monitoring.
| OS distribution**[2](#runtime-monitoring-eks-os-support)** | Kernel version**[3](#runtime-monitoring-eks-kernel-version-required-flag)** | Supported Kubernetes version |
| --- | --- | --- |
| Bottlerocket | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 |
| Ubuntu | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| Amazon Linux 2 | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| Amazon Linux 2023*[5](#runtime-eks-al2023-support-v1.6.0)* | 5.4, 5.10, 5.15, 6.1[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| RedHat 9.4 | 5.14[4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 |
| Fedora 34 | 5.11, 5,17 | v1.21 - v1.35 |
| Fedora 40 | 6.8 | v1.28 - v1.35 |
| Fedora 41 | 6.12 | v1.28 - v1.35 |
| CentOS Stream 9 | 5.14 | v1.21 - v1.35 |
1. Runtime Monitoring for Amazon EKS clusters doesn't support the first generation Graviton instance such as A1 instance types.
1. Support for various operating systems - GuardDuty has verified Runtime Monitoring support for the operating distribution listed in the preceding table. While the GuardDuty security agent may run on operating systems not listed in the preceding table, the GuardDuty team cannot guarantee the expected security value.
1. For any kernel version, you must set the `CONFIG_DEBUG_INFO_BTF` flag to `y` (meaning *true*). This is required so that the GuardDuty security agent can run as expected.
1. Presently, with Kernel version `6.1`, GuardDuty can't generate [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md) that are related to [Domain Name System (DNS) events](runtime-monitoring-collected-events.md#eks-runtime-dns-events).
1. Runtime Monitoring supports AL2023 with the release of the GuardDuty security agent v1.6.0 and above. For more information, see [GuardDuty security agent versions for Amazon EKS resources](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history).
#### Kubernetes versions supported by GuardDuty security agent
The following table shows the Kubernetes versions for your EKS clusters that are supported by GuardDuty security agent.
| Amazon EKS add-on GuardDuty security agent version | Kubernetes version |
| --- | --- |
| v1.12.1 (latest - v1.12.1-eksbuild.2) | 1.28 - 1.35 |
| v1.11.0 (latest - v1.11.0-eksbuild.4) | 1.28 - 1.34 |
| v1.10.0 (latest - v1.10.0-eksbuild.2) | 1.21 - 1.33 |
| v1.9.0 (latest - v1.9.0-eksbuild.2) v1.8.1 (latest - v1.8.1-eksbuild.2) | 1.21 - 1.32 |
| v1.7.1 v1.7.0 v1.6.1 | 1.21 - 1.31 |
| v1.6.0 v1.5.0 v1.4.1 v1.4.0 v1.3.1 | 1.21 - 1.29 |
| v1.3.0 v1.2.0 | 1.21 - 1.28 |
| v1.1.0 | 1.21 - 1.26 |
| v1.0.0 | 1.21 - 1.25 |
Some of the GuardDuty security agent versions will reach end of standard support.
For information about the agent release versions, see [GuardDuty security agent versions for Amazon EKS resources](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history).
### CPU and memory limits
The following table shows the CPU and memory limits for the Amazon EKS add-on for GuardDuty (`aws-guardduty-agent`).
| Parameter | Minimum limit | Maximum limit |
| --- | --- | --- |
| CPU | 200m | 1000m |
| Memory | 256 Mi | 1024 Mi |
When you use Amazon EKS add-on version 1.5.0 or above, GuardDuty provides the capability to configure the add-on schema for your CPU and memory values. For information about the configurable range, see [Configurable parameters and values](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values).
After you enable EKS Runtime Monitoring and assess the coverage status of your EKS clusters, you can set up and view the container insight metrics. For more information, see [Setting up CPU and memory monitoring](runtime-monitoring-setting-cpu-mem-monitoring.md).
## Validating your organization service control policy
If you have set up a service control policy (SCP) to manage permissions in your organization, validate that permissions boundary is not restricting `guardduty:SendSecurityTelemetry`. It is required for GuardDuty to support Runtime Monitoring across different resource types.
If you are a member account, connect with the associated delegated administrator. For information about managing SCPs for your organization, see [Service control policies (SCPs)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps.html).