# GuardDuty Runtime Monitoring
<a name="runtime-monitoring"></a>

Runtime Monitoring observes and analyzes operating system-level, networking, and file events to help you detect potential threats in specific AWS workloads in your environment. 

**Supported AWS resources in Runtime Monitoring** – GuardDuty had initially released Runtime Monitoring to support only Amazon Elastic Kubernetes Service (Amazon EKS) resources. Now, you can use the Runtime Monitoring feature to provide threat detection for your AWS Fargate Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Compute Cloud (Amazon EC2) resources as well.

GuardDuty doesn't support Amazon EKS clusters running on AWS Fargate.

In this document and other sections related to Runtime Monitoring, GuardDuty uses the terminology of **resource type** to refer to Amazon EKS, Fargate Amazon ECS, and Amazon EC2 resources.

Runtime Monitoring uses a GuardDuty security agent that adds visibility into runtime behavior, such as file access, process execution, command line arguments, and network connections. For each resource type that you want to monitor for potential threats, you can manage the security agent for that specific resource type either automatically or manually (with an exception to Fargate (Amazon ECS only)). Managing the security agent automatically means that you permit GuardDuty to install and update the security agent on your behalf. On the other hand, when you manage the security agent for your resources manually, you are responsible for installing and updating the security agent, as needed. 

With this extended capability, GuardDuty can help you identify and respond to potential threats that may target applications and data running in your individual workloads and instances. For example, a threat can potentially start by compromising a single container that runs a vulnerable web application. This web application might have access permissions to the underlying containers and workloads. In this scenario, incorrectly configured credentials could potentially lead to a broader access to the account, and the data stored within it.

By analyzing the runtime events of the individual containers and workloads, GuardDuty can potentially identify compromise of a container and associated AWS credentials in an initial phase, and detect attempts to escalate privileges, suspicious API requests, and malicious access to the data in your environment.

**Topics**
+ [How it works](how-does-runtime-monitoring-work.md)
+ [How does 30-day free trial work in Runtime Monitoring](runtime-monitoring-free-trial-works.md)
+ [Prerequisites to enabling Runtime Monitoring](runtime-monitoring-prerequisites.md)
+ [Enabling GuardDuty Runtime Monitoring](runtime-monitoring-configuration.md)
+ [Managing GuardDuty security agents](runtime-monitoring-managing-agents.md)
+ [Reviewing runtime coverage statistics and troubleshooting issues](runtime-monitoring-assessing-coverage.md)
+ [Setting up CPU and memory monitoring](runtime-monitoring-setting-cpu-mem-monitoring.md)
+ [Using shared VPC with Runtime Monitoring](runtime-monitoring-shared-vpc.md)
+ [Using Infrastructure as Code (IaC) with GuardDuty automated security agents](using-iac-with-gdu-automated-agents-runtime-monitoring.md)
+ [Collected runtime event types that GuardDuty uses](runtime-monitoring-collected-events.md)
+ [Amazon ECR repository hosting GuardDuty agent](runtime-monitoring-ecr-repository-gdu-agent.md)
+ [Two security agents on same underlying host](two-security-agents-installed-on-ec2-node.md)
+ [EKS Runtime Monitoring in GuardDuty](eks-runtime-monitoring-guardduty.md)
+ [GuardDuty security agent release versions](runtime-monitoring-agent-release-history.md)
+ [Disabling, uninstalling, and cleaning up resources in Runtime Monitoring](runtime-monitoring-agent-resource-clean-up.md)

# How it works
<a name="how-does-runtime-monitoring-work"></a>

To use Runtime Monitoring, you must enable Runtime Monitoring and then manage the GuardDuty security agent. The following list explains this two-step process:

1. **Enable Runtime Monitoring** for your account so that GuardDuty can accept the runtime events that it receives from your Amazon EC2 instances, Amazon ECS clusters, and Amazon EKS workloads.

1. **Manage GuardDuty agent** for the individual resources for which you want to monitor the runtime behavior. Based on the resource type, you can choose to:
   + Use automated agent configuration, where GuardDuty manages the agent deployment and automatically an Amazon Virtual Private Cloud (Amazon VPC) endpoint.
   + Install agent manually, which requires you to create the VPC endpoint as a prerequisite.

   The security agent uses VPC endpoint to deliver events to GuardDuty, ensuring that the data remains within the AWS network. This approach enhances security and allows GuardDuty to monitor and analyze runtime behavior across your resources (Amazon EKS, Amazon EC2, and AWS Fargate-Amazon ECS). GuardDuty uses [Instance identity roles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#ec2-instance-identity-roles) that authenticates the security agent for each resource type to send the associated runtime events to the VPC endpoint.

**Note**  
GuardDuty doesn't make the runtime events accessible to you.

When you manage the security agent (either manually or through GuardDuty) in EKS Runtime Monitoring or Runtime Monitoring for EC2 instances, and GuardDuty is presently deployed on an Amazon EC2 instance and receives the [Collected runtime event types](runtime-monitoring-collected-events.md) from this instance, GuardDuty will not charge your AWS account for the analysis of VPC flow logs from this Amazon EC2 instance. This helps GuardDuty avoid double usage cost in the account.

The following topics explain how enabling Runtime Monitoring and managing GuardDuty security agent works differently for each resource type.

**Topics**
+ [How Runtime Monitoring works with Amazon EKS clusters](how-runtime-monitoring-works-eks.md)
+ [How Runtime Monitoring works with Amazon EC2 instances](how-runtime-monitoring-works-ec2.md)
+ [How Runtime Monitoring works with Fargate (Amazon ECS only)](how-runtime-monitoring-works-ecs-fargate.md)
+ [After you enable Runtime Monitoring](runtime-monitoring-after-configuration.md)

# How Runtime Monitoring works with Amazon EKS clusters
<a name="how-runtime-monitoring-works-eks"></a>

Runtime Monitoring uses an [EKS add-on `aws-guardduty-agent`](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#workloads-add-ons-available-eks), also called as GuardDuty security agent. After GuardDuty security agent gets deployed on your EKS clusters, GuardDuty is able to receive runtime events for these EKS clusters. 

**Notes**  
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 AWS Fargate.  
For information about these Amazon EKS features, see [What is Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) in the **Amazon EKS User Guide**.

You can monitor the runtime events of your Amazon EKS clusters at either account or cluster level. You can manage the GuardDuty security agent for only those Amazon EKS clusters that you want to monitor for threat detection. You can manage the GuardDuty security agent either manually or by allowing GuardDuty to manage it on your behalf, by using Automated agent configuration.

When you use the automated agent configuration approach to allow GuardDuty to manage the deployment of the security agent on your behalf, it will automatically **create an Amazon Virtual Private Cloud (Amazon VPC) endpoint**. The security agent delivers the runtime events to GuardDuty by using this Amazon VPC endpoint. 

Along with the VPC endpoint, GuardDuty also creates a new security group. The inbound (ingress) rules control the traffic that's allowed to reach the resources, that are associated with the security group. GuardDuty adds inbound rules that match the VPC CIDR range for your resource, and also adapts to it when the CIDR range changes. For more information, see [VPC CIDR range](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*.

**Notes**  
There is no additional cost for the usage of the VPC endpoint.
Working with centralized VPC with automated agent – When you use GuardDuty automated agent configuration for a resource type, GuardDuty will create a VPC endpoint on your behalf for all the VPCs. This includes the centralized VPC and spoke VPCs. GuardDuty doesn't support creating a VPC endpoint only for the centralized VPC. For more information about how the centralized VPC works, see [Interface VPC endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) in the *AWS Whitepaper - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure*.

## Approaches to manage GuardDuty security agent in Amazon EKS clusters
<a name="eksrunmon-approach-to-monitor-eks-clusters"></a>

Prior to September 13, 2023, you could configure GuardDuty to manage the security agent at the account level. This behavior indicated that by default, GuardDuty will manage the security agent on all the EKS clusters that belong to an AWS account. Now, GuardDuty provides a granular capability to help you choose the EKS clusters where you want GuardDuty to manage the security agent.

When you choose to [Manage GuardDuty security agent manually](#eks-runtime-using-gdu-agent-manually), you can still select the EKS clusters that you want to monitor. However, to manage the agent manually, creating a Amazon VPC endpoint for your AWS account is a prerequisite.

**Note**  
Regardless of the approach that you use to manage the GuardDuty security agent, EKS Runtime Monitoring is always enabled at the account level. 

**Topics**
+ [Manage security agent through GuardDuty](#eks-runtime-using-gdu-agent-management-auto)
+ [Manage GuardDuty security agent manually](#eks-runtime-using-gdu-agent-manually)

### Manage security agent through GuardDuty
<a name="eks-runtime-using-gdu-agent-management-auto"></a>

GuardDuty deploys and manages the security agent on your behalf. At any point in time, you can monitor the EKS clusters in your account by using one of the following approaches.

**Topics**
+ [Monitor all EKS clusters](#gdu-security-agent-all-eks-custers)
+ [Exclude selective EKS clusters](#eks-runtime-using-exclusion-tags)
+ [Include selective EKS clusters](#eks-runtime-using-inclusion-tags)

#### Monitor all EKS clusters
<a name="gdu-security-agent-all-eks-custers"></a>

Use this approach when you want GuardDuty to deploy and manage the security agent for all the EKS clusters in your account. By default, GuardDuty will also deploy the security agent on a potentially new EKS cluster created in your account.

**Impact of using this approach**  
+ GuardDuty creates an Amazon Virtual Private Cloud (Amazon VPC) endpoint through which the GuardDuty security agent delivers the runtime events to GuardDuty. There is no additional cost for the creation of the Amazon VPC endpoint when you manage the security agent through GuardDuty.
+ It is required that your worker node has a valid network path to an active `guardduty-data` VPC endpoint. GuardDuty deploys the security agent on your EKS clusters. Amazon Elastic Kubernetes Service (Amazon EKS) will coordinate the deployment of the security agent on the nodes within the EKS clusters.
+ On the basis of IP availability, GuardDuty selects the subnet to create a VPC endpoint. If you use advanced network topologies, you must validate that the connectivity is possible.

#### Exclude selective EKS clusters
<a name="eks-runtime-using-exclusion-tags"></a>

Use this approach when you want GuardDuty to manage the security agent for all EKS clusters in your account but exclude selective EKS clusters. This method uses a tag-based[1](#eks-runtime-inclusion-exclusion-tags) approach wherein you can tag the EKS clusters for which you don't want to receive the runtime events. The pre-defined tag must have `GuardDutyManaged`-`false` as the key-value pair.

**Impact of using this approach**  
This approach requires that you to enable GuardDuty agent auto-management only after adding tags to the EKS clusters that you want to exclude from monitoring.  
Therefore, the impact when you [Manage security agent through GuardDuty](#eks-runtime-using-gdu-agent-management-auto) applies to this approach too. When you add tags prior to enabling GuardDuty agent auto-management, GuardDuty will neither deploy nor manage the security agent for the EKS clusters that are excluded from monitoring.

**Considerations**  
+ You must add the tag key-value pair as `GuardDutyManaged`:`false` for the selective EKS clusters before enabling Automated agent configuration otherwise, the GuardDuty security agent will be deployed on all the EKS clusters until you use the tag.
+ You must prevent the tags from being modified, except by trusted identities.
**Important**  
Manage permissions for modifying the value of the `GuardDutyManaged` tag for your EKS cluster by using service control policies or IAM policies. For more information, see [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide* or [Control access to AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) in the *IAM User Guide*.
+ For a potentially new EKS cluster that you don't want to monitor, make sure to add the `GuardDutyManaged`-`false` key-value pair at the time of creating this EKS cluster.
+ This approach will also have the same consideration as specified for [Monitor all EKS clusters](#gdu-security-agent-all-eks-custers).

#### Include selective EKS clusters
<a name="eks-runtime-using-inclusion-tags"></a>

Use this approach when you want GuardDuty to deploy and manage the updates to the security agent only for selective EKS clusters in your account. This method uses a tag-based[1](#eks-runtime-inclusion-exclusion-tags) approach wherein you can tag the EKS cluster for which you want to receive the runtime events.

**Impact of using this approach**  
+ By using inclusion tags, GuardDuty will automatically deploy and manage the security agent only for the selective EKS clusters that are tagged with `GuardDutyManaged`-`true` as the key-value pair.
+ Using this approach will also have the same impact as specified for [Monitor all EKS clusters](#gdu-security-agent-all-eks-custers). 

**Considerations**  
+ If the value of the `GuardDutyManaged` tag is not set to `true`, the inclusion tag will not work as expected and this may impact monitoring your EKS cluster.
+ To ensure that your selective EKS clusters are being monitored, you need to prevent the tags from being modified, except by trusted identities.
**Important**  
Manage permissions for modifying the value of the `GuardDutyManaged` tag for your EKS cluster by using service control policies or IAM policies. For more information, see [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide* or [Control access to AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) in the *IAM User Guide*.
+ For a potentially new EKS cluster that you don't want to monitor, make sure to add the `GuardDutyManaged`-`false` key-value pair at the time of creating this EKS cluster.
+ This approach will also have the same consideration as specified for [Monitor all EKS clusters](#gdu-security-agent-all-eks-custers).<a name="eks-runtime-inclusion-exclusion-tags"></a>

1For more information about tagging selective EKS clusters, see [Tagging your Amazon EKS resources](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) in the **Amazon EKS User Guide**.

### Manage GuardDuty security agent manually
<a name="eks-runtime-using-gdu-agent-manually"></a>

Use this approach when you want deploy and manage the GuardDuty security agent on all of your EKS clusters manually. Ensure that EKS Runtime Monitoring is enabled for your accounts. The GuardDuty security agent may not work as expected if you don't enable EKS Runtime Monitoring.

**Impact of using this approach**  
You will need to coordinate the deployment of the GuardDuty security agent within your EKS clusters across all accounts and AWS Regions where this feature is available. You will also need to update the agent version when GuardDuty releases it. For more information about agent versions for EKS, see [GuardDuty security agent versions for Amazon EKS resources](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history).

**Considerations**  
You must support secure data flow while monitoring for and addressing coverage gaps as new clusters and workloads are continuously deployed.

# How Runtime Monitoring works with Amazon EC2 instances
<a name="how-runtime-monitoring-works-ec2"></a>

Your Amazon EC2 instances can run multiple types of applications and workloads in your AWS environment. When you enable Runtime Monitoring and manage the GuardDuty security agent, GuardDuty helps you detect threats in your existing Amazon EC2 instances and potentially new ones. This feature also supports Amazon ECS managed Amazon EC2 instances. For more see [Managed Instances support in Guardduty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_managed-instances.html).

**Note**  
Runtime Monitoring doesn't support applications running on [Amazon ECS Managed Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html).

Enabling Runtime Monitoring makes GuardDuty ready to consume runtime events from currently running and new processes within Amazon EC2 instances. GuardDuty requires a security agent to send runtime events from your EC2 instance to GuardDuty. 

For Amazon EC2 instances, GuardDuty security agent operates at the instance level. You can decide if you want to monitor all or selective Amazon EC2 instances in your account. If you want to manage selective instances, the security agent is required only for these instances.

GuardDuty can also consume runtime events from new tasks and existing tasks running in Amazon EC2 instances within Amazon ECS clusters. 

To install the GuardDuty security agent, Runtime Monitoring provides the following two options:
+ [Use automated agent configuration (recommended)](#use-automated-agent-config-ec2), or
+ [Manage security agent manually](#ec2-security-agent-option2-manual)

## Use automated agent configuration through GuardDuty (recommended)
<a name="use-automated-agent-config-ec2"></a>

Use automated agent configuration that permits GuardDuty to install the security agent on your Amazon EC2 instances on your behalf. GuardDuty also manages the updates to the security agent.

By default, GuardDuty installs the security agent on all the instances in your account. If you'd want GuardDuty to install and manage the security agent for selected EC2 instances only, add inclusion or exclusion tags to your EC2 instances, as needed.

Sometimes, you may not want to monitor runtime events for all the Amazon EC2 instances that belong to your account. For cases when you want to monitor the runtime events for a limited number of instances, add an inclusion tag as `GuardDutyManaged`:`true` to these selected instances. Starting with the availability of automated agent configuration for Amazon EC2, if your EC2 instance has an inclusion tag (`GuardDutyManaged`:`true`), GuardDuty will honor the tag and manage the security agent for the selected instances even when you do not explicitly enable automated agent configuration.

On the other hand, if there are a limited number of EC2 instances for which you don't want to monitor runtime events, add an exclusion tag (`GuardDutyManaged`:`false`) to these selected instances. GuardDuty will honor the exclusion tag by **neither** installing **nor** managing the security agent for these EC2 resources.

### Impact
<a name="impact-automated-security-agent-ec2"></a>

When you use automated agent configuration in an AWS account or an organization, you permit GuardDuty to take the following steps on your behalf:
+ GuardDuty creates one SSM association for all your Amazon EC2 instances that are SSM managed and appear under **Fleet Manager** in the [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) console. 
+ Using inclusion tags with automated agent configuration disabled – After enabling Runtime Monitoring, when you don't enable automated agent configuration but add inclusion tag to your Amazon EC2 instance, it means that you are permitting GuardDuty to manage the security agent on your behalf. SSM association will then install the security agent in each instance that has the inclusion tag (`GuardDutyManaged`:`true`).
+ If you enable automated agent configuration – The SSM association will then install the security agent in all the EC2 instances that belong to your account. 
+ Using exclusion tags with automated agent configuration – Before you enable automated agent configuration, when you add exclusion tag to your Amazon EC2 instance, it means that you are permitting GuardDuty to prevent installing and managing the security agent for this selected instance.

  Now, when you enable automated agent configuration, the SSM association will install and manage the security agent in all the EC2 instances except the ones that are tagged with the exclusion tag. 
+ GuardDuty creates VPC endpoints in all the VPCs, including shared VPCs, as long as there is at least one Linux EC2 instance in that VPC that are not in the terminated or shutting-down instance states. This includes the centralized VPC and spoke VPCs. GuardDuty doesn't support creating a VPC endpoint only for the centralized VPC. For more information about how the centralized VPC works, see [Interface VPC endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) in the *AWS Whitepaper - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure*.

  For information about different instance states, see [Instance lifecycle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html) in the *Amazon EC2 User Guide*.

  GuardDuty also supports [Using shared VPC with Runtime Monitoring](runtime-monitoring-shared-vpc.md). When all the prerequisites are considered for your organization and AWS account, GuardDuty will use the shared VPC to receive runtime events.
**Note**  
There is no additional cost for the usage of the VPC endpoint.
+ Along with the VPC endpoint, GuardDuty also creates a new security group. The inbound (ingress) rules control the traffic that's allowed to reach the resources, that are associated with the security group. GuardDuty adds inbound rules that match the VPC CIDR range for your resource, and also adapts to it when the CIDR range changes. For more information, see [VPC CIDR range](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*.

## Manage security agent manually
<a name="ec2-security-agent-option2-manual"></a>

There are two ways to manage the security agent for Amazon EC2 manually:
+ Use GuardDuty managed documents in AWS Systems Manager to install the security agent on your Amazon EC2 instances that are already SSM managed.

  Whenever you launch a new Amazon EC2 instance, ensure that it is SSM enabled.
+ Use RPM package manager (RPM) scripts to install the security agent on your Amazon EC2 instances, whether or not they are SSM managed.

## Next step
<a name="next-step-prerequisites-ec2"></a>

To get started with Runtime Monitoring configuration to monitor your Amazon EC2 instances, see [Prerequisites for Amazon EC2 instance support](prereq-runtime-monitoring-ec2-support.md).

# How Runtime Monitoring works with Fargate (Amazon ECS only)
<a name="how-runtime-monitoring-works-ecs-fargate"></a>

When you enable Runtime Monitoring, GuardDuty becomes ready to consume the runtime events from a task. These tasks run within the Amazon ECS clusters, which in turn run on the AWS Fargate instances. For GuardDuty to receive these runtime events, you must use the fully-managed, dedicated security agent.

**Note**  
Runtime Monitoring doesn't support applications running on [Amazon ECS Managed Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html).

You can allow GuardDuty to manage the GuardDuty security agent on your behalf, by using Automated agent configuration for an AWS account or an organization. GuardDuty will start deploying the security agent to the new Fargate tasks that are launched in your Amazon ECS clusters. The following list specifies what to expect when you enable the GuardDuty security agent.**Impact of enabling GuardDuty security agent**

**GuardDuty creates a virtual private cloud (VPC) endpoint and security group**  
+ When you deploy the GuardDuty security agent, GuardDuty will create a VPC endpoint through which the security agent delivers the runtime events to GuardDuty.

  Along with the VPC endpoint, GuardDuty also creates a new security group. The inbound (ingress) rules control the traffic that's allowed to reach the resources, that are associated with the security group. GuardDuty adds inbound rules that match the VPC CIDR range for your resource, and also adapts to it when the CIDR range changes. For more information, see [VPC CIDR range](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*.
+ Working with centralized VPC with automated agent – When you use GuardDuty automated agent configuration for a resource type, GuardDuty will create a VPC endpoint on your behalf for all the VPCs. This includes the centralized VPC and spoke VPCs. GuardDuty doesn't support creating a VPC endpoint only for the centralized VPC. For more information about how the centralized VPC works, see [Interface VPC endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) in the *AWS Whitepaper - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure*.
+ There is no additional cost for the usage of the VPC endpoint.

**GuardDuty adds a sidecar container**  
For a new Fargate task or service that starts running, a GuardDuty container (sidecar) attaches itself to each container within the Amazon ECS Fargate task. The GuardDuty security agent runs within the attached GuardDuty container. This helps GuardDuty to collect the runtime events of each container running within these tasks.  
The GuardDuty sidecar container image is stored in Amazon Elastic Container Registry (Amazon ECR), with its image layers stored in Amazon S3. When your task starts, it needs to pull this image from ECR. Depending on your network configuration, this may require specific settings to ensure access to both ECR and S3. For example, if you're using security groups with restricted access, you'll need to allow access to the S3 managed prefix list. For more information on how to do this, see [Prerequisites for container image access](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs).  
When you start a Fargate task, should the GuardDuty container (sidecar) be unable to launch in a healthy state, Runtime Monitoring is designed to not prevent the tasks from running.  
By default, a Fargate task is immutable. GuardDuty will not deploy the sidecar when a task is already in a running state. If you want to monitor a container in an already running task, you can stop the task and start it again.

## Approaches to manage GuardDuty security agent in Amazon ECS-Fargate resources
<a name="gdu-runtime-approaches-agent-deployment-ecs-clusters"></a>

Runtime Monitoring provides you the option to detect potential security threats on either all of the Amazon ECS clusters (account level) or selective clusters (cluster level) in your account. When you enable Automated agent configuration for each Amazon ECS Fargate task that will run, GuardDuty will add a sidecar container for each container workload within that task. The GuardDuty security agent gets deployed to this sidecar container. This is how GuardDuty gets visibility into the runtime behavior of the containers inside the Amazon ECS tasks.

Runtime Monitoring supports managing the security agent for your Amazon ECS clusters (AWS Fargate) only through GuardDuty. There is no support for managing the security agent manually on Amazon ECS clusters.

Before you configure your accounts, assess if you want to monitor the runtime behavior of all the containers that belong to the Amazon ECS tasks, or include or exclude specific resources. Consider the following approaches.

**Monitor for all Amazon ECS clusters**  
This approach will help you detect potential security threats at account level. Use this approach when you want GuardDuty to detect potential security threats for all the Amazon ECS clusters that belong to your account.

**Exclude specific Amazon ECS clusters**  
Use this approach when you want GuardDuty to detect potential security threats for most of the Amazon ECS clusters in your AWS environment but exclude some of the clusters. This approach helps you monitor the runtime behavior of the containers within your Amazon ECS tasks at the cluster level. For example, the number of Amazon ECS clusters that belong to your account are 1000. However, you want to monitor only 930 Amazon ECS clusters.  
This approach requires you to add a pre-defined GuardDuty tag to the Amazon ECS clusters that you don't want to monitor. For more information, see [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md).

**Include specific Amazon ECS clusters**  
Use this approach when you want GuardDuty to detect potential security threats for some of the Amazon ECS clusters. This approach helps you monitor the runtime behavior of the containers within your Amazon ECS tasks at the cluster level. For example, the number of Amazon ECS clusters that belong to your account are 1000. However, you want to monitor 230 clusters only.  
This approach requires you to add a pre-defined GuardDuty tag to the Amazon ECS clusters that you want to monitor. For more information, see [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md).

# After you enable Runtime Monitoring
<a name="runtime-monitoring-after-configuration"></a>

After you enable Runtime Monitoring and install GuardDuty security agent in your standalone account or multiple member accounts, you can take the following steps to ensure that the protection plan setting is working as expected, and monitor how much memory and CPU does GuardDuty security agent uses. 

**Assess runtime coverage**  
GuardDuty recommends you to continuously assess the coverage status of the resource where you have deployed the security agent. The coverage status could be either **Healthy** or **Unhealthy**. A **Healthy** coverage status indicates that GuardDuty is receiving the runtime events from the corresponding resource when there is an operating system-level activity.  
When the coverage status becomes **Healthy** for the resource, GuardDuty is able to receive the runtime events and analyze them for threat detection. When GuardDuty detects a potential security threat in the tasks or applications running in your container workloads and instances, GuardDuty generates [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md).  
You can also configure an Amazon EventBridge (EventBridge) to receive a notification when the coverage status changes from **Unhealthy** to **Healthy** and otherwise. For more information, see [Reviewing runtime coverage statistics and troubleshooting issues](runtime-monitoring-assessing-coverage.md).

**Set up CPU and memory monitoring for GuardDuty security agent**  
After you have assessed that the coverage status shows as **Healthy**, you can evaluate the performance of the security agent for your resource type. For Amazon EKS clusters that have the security agent release v1.5 or above, GuardDuty supports configuring the parameters of the (add-on) security agent. For more information, see [Setting up CPU and memory monitoring](runtime-monitoring-setting-cpu-mem-monitoring.md).

**GuardDuty detects potential threats**  
As GuardDuty starts to receive the runtime events for your resource, it starts analyzing those events. When GuardDuty detects a potential security threat in any of your Amazon EC2 instances, Amazon ECS clusters, or Amazon EKS clusters, it generates one or more [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md). You can access the finding details to view the impacted resource details.

# How does 30-day free trial work in Runtime Monitoring
<a name="runtime-monitoring-free-trial-works"></a>

The 30-day free trial period works differently for the new GuardDuty accounts and the existing accounts that have already enabled EKS Runtime Monitoring prior to when Runtime Monitoring capability extended to Amazon EC2 instances and AWS Fargate (Amazon ECS only).

## I am using GuardDuty trial period or I have never enabled EKS Runtime Monitoring
<a name="enabled-gdu-first-time-or-never-enabled-eks-30-day"></a>

The following list explains how the 30-day free trial period works if you're either using the GuardDuty 30-day trial period or have never enabled EKS Runtime Monitoring:
+ When you enable GuardDuty for the first time, Runtime Monitoring and EKS Runtime Monitoring will not be enabled by default.

  When you enable Runtime Monitoring for your account or organization, make sure to also configure the GuardDuty security agent for the resource that you want to monitor for threat detection. For example, if you want to use Runtime Monitoring for your Amazon EC2 instances, then after you enable Runtime Monitoring, you must also configure the security agent for Amazon EC2. You can choose to do this either manually or automatically through GuardDuty.
+ The Runtime Monitoring protection plan is enabled at the **account level**. The 30-day free trial period works at the **resource level**. After the GuardDuty security agent gets deployed to a specific resource type, the 30-day free trial starts when GuardDuty receives its **first runtime event** associated with this resource type. For example, you have deployed the GuardDuty agent at the resource level (for Amazon EC2 instance, Amazon ECS cluster, and Amazon EKS cluster). When GuardDuty receives the first runtime event for an Amazon EC2 instance, the 30-day free trial will start for Amazon EC2 only.
+ When you want to enable only EKS Runtime Monitoring – When you enable GuardDuty for the first time, EKS Runtime Monitoring is not enabled by default (after the release of Runtime Monitoring). You will need to enable EKS Runtime Monitoring. To use it optimally, make sure that you either manage the GuardDuty security agent manually or enable automated agent configuration so that GuardDuty manages the agent on your behalf. Your 30-day free trial period for EKS Runtime Monitoring starts when GuardDuty receives its first runtime event for the Amazon EKS resource. 

# I enabled EKS Runtime Monitoring prior to the launch of Runtime Monitoring
<a name="enabled-eks-gdu-prior-runtime-monitoring-30-day"></a>

Use this section only when EKS Runtime Monitoring was enabled for your AWS account, and now you want to migrate to Runtime Monitoring.

The following list includes scenarios that might apply to your use case of enabling Runtime Monitoring:
+ For an existing GuardDuty account that has the EKS Runtime Monitoring protection plan enabled and uses the GuardDuty console experience to use this protection plan – With the announcement of Runtime Monitoring, the EKS Runtime Monitoring console experience has now been consolidated into Runtime Monitoring. Your existing configuration for EKS Runtime Monitoring remains the same. You can continue to use the API/CLI support to perform operations associated with EKS Runtime Monitoring. 
+ To use EKS Runtime Monitoring as a part of Runtime Monitoring, you will need to configure Runtime Monitoring for your account or organization. To keep the same configuration for Runtime Monitoring, see [Migrating from EKS Runtime Monitoring to Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md). However, this will not impact your 30-day free trial for Amazon EKS resource. 
+ The Runtime Monitoring protection plan is enabled at the account level per Region. After the GuardDuty security agent gets deployed to one of the specified resource types (Amazon EC2 instance and Amazon ECS cluster), the 30-day free trial starts when GuardDuty receives the first runtime event associated with the resource. There is a 30-day free trial associated with each resource type. 

  For example, after enabling Runtime Monitoring, you choose to deploy the GuardDuty agent only on Amazon EC2 instance, the 30-day free trial for this resource will start only when GuardDuty receives its first runtime event for an Amazon EC2 instance. Later, when you deploy the GuardDuty agent for Fargate (Amazon ECS only), the 30-day free trial for this resource will start only when GuardDuty receives its first runtime event for Amazon ECS cluster. Considering you already have EKS Runtime Monitoring enabled for your account, GuardDuty doesn't reset the 30-day free trial for an Amazon EKS resource.

# Prerequisites to enabling Runtime Monitoring
<a name="runtime-monitoring-prerequisites"></a>

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 AWS 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
<a name="prereq-runtime-monitoring-ec2-support"></a>

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)
<a name="ssm-managed-prereq-ec2"></a>

GuardDuty uses AWS 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.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) in the *AWS Systems Manager User Guide*.

## Validate architectural requirements
<a name="validating-architecture-req-ec2"></a>

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.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

  1. <a name="runtime-monitoring-ec2-graviton-2-support"></a>Runtime Monitoring for Amazon EC2 resources doesn't support the first generation Graviton instance such as A1 instance types.

  1. <a name="runtime-monitoring-ec2-os-support"></a>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. <a name="runtime-monitoring-ec2-kernel-version-required-flag"></a>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. <a name="runtime-monitoring-ec2-kernel-5-10"></a>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. <a name="runtime-monitoring-ec2-ubuntu-noble-agent-version"></a>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
<a name="runtime-monitoring-ec2-modify-rlimit-memlock"></a>

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
<a name="validate-organization-scp-ec2"></a>

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.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

## When using automated agent configuration
<a name="runtime-ec2-prereq-automated-agent"></a>

To [Use automated agent configuration (recommended)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2), your AWS 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.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/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.aws.amazon.com/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
<a name="ec2-cpu-memory-limits-gdu-agent"></a>

**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.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

## Next step
<a name="next-step-after-prereq-ec2"></a>

The next step is to configure Runtime Monitoring and also manage the security agent (automatically or manually).

# Prerequisites for AWS Fargate (Amazon ECS only) support
<a name="prereq-runtime-monitoring-ecs-support"></a>

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
<a name="validating-architecture-req-ecs"></a>

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 AWS 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.aws.amazon.com/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
<a name="ecs-verified-platforms-gdu-agent"></a>

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 | <a name="runtime-monitoring-ecs-os-support"></a>

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
<a name="before-enable-runtime-monitoring-ecs"></a>

The following prerequisites help you access the GuardDuty sidecar container image from the Amazon ECR repository.

### Permissions requirements
<a name="ecs-runtime-permissions-requirements"></a>

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 AWS 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.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) managed policy or add the above permissions to your `TaskExecutionRole` policy.

### Task definition configuration
<a name="ecs-runtime-task-definition"></a>

When creating or updating Amazon ECS services, you need to provide subnet information in your task definition:

Running the [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) and [UpdateService](https://docs.aws.amazon.com/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.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) in the *Amazon Elastic Container Service Developer Guide*.

### Network connectivity requirements
<a name="ecs-runtime-network-requirements"></a>

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.aws.amazon.com/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.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) in the *Amazon Elastic Container Registry User Guide*.

### Security group configuration
<a name="ecs-runtime-security-group-requirements"></a>

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.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security). To add an outbound rule, see [Configure security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) in the *Amazon VPC User Guide*.

To view your AWS-managed prefix lists in the console or describe them by using AWS Command Line Interface (AWS CLI), see [AWS-managed prefix lists](https://docs.aws.amazon.com/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
<a name="validate-organization-scp-ecs"></a>

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.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) in the *AWS 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.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS 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.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/). You must sign in as an IAM role, or sign in as the root user [(not recommended)](https://docs.aws.amazon.com/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.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy) in the *AWS Organizations User Guide*.

## Validating role permissions and policy permissions boundary
<a name="guardduty-runtime-monitoring-ecs-permission-boundary"></a>

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 AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/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 AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.

## CPU and memory limits
<a name="ecs-runtime-agent-cpu-memory-limits"></a>

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.aws.amazon.com/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
<a name="prereq-runtime-monitoring-eks-support"></a>

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
<a name="runtime-monitoring-eks-feature-support"></a>

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 AWS Fargate.

For information about these Amazon EKS features, see [What is Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) in the **Amazon EKS User Guide**.

## Validating architectural requirements
<a name="eksrunmon-supported-platform-concepts"></a>

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
<a name="eksrunmon-verified-platform"></a>

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. <a name="runtime-monitoring-eks-graviton-2-support"></a>Runtime Monitoring for Amazon EKS clusters doesn't support the first generation Graviton instance such as A1 instance types.

1. <a name="runtime-monitoring-eks-os-support"></a>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. <a name="runtime-monitoring-eks-kernel-version-required-flag"></a>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. <a name="v6.1-kernel-dns-findings-unsupported-eks"></a>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. <a name="runtime-eks-al2023-support-v1.6.0"></a>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
<a name="gdu-agent-supported-k8-version"></a>

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
<a name="eks-runtime-agent-limits"></a>

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
<a name="validate-organization-scp-eks"></a>

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.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

# Enabling GuardDuty Runtime Monitoring
<a name="runtime-monitoring-configuration"></a>

Before enabling Runtime Monitoring in your account, make sure that the resource type for which you want to monitor the runtime events, supports the platforms requirements. For more information, see [Prerequisites](runtime-monitoring-prerequisites.md).

If you have been using EKS Runtime Monitoring prior to the launch of Runtime Monitoring, you can use the APIs to check and update the existing configuration for EKS Runtime Monitoring. You can also migrate your existing configuration from EKS Runtime Monitoring to Runtime Monitoring. For more information, see [Migrating from EKS Runtime Monitoring to Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md).

**Note**  
Presently, this documentation provides steps to enable Runtime Monitoring for your accounts and organization by console only. You can also enable Runtime Monitoring by using [API Actions](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Operations.html) or [AWS CLI for GuardDuty](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/guardduty/index.html#cli-aws-guardduty).

You can configure Runtime Monitoring by using the steps in the following topics.

**Topics**
+ [Enabling Runtime Monitoring for multiple-account environments](enable-runtime-monitoring-multiple-acc-env.md)
+ [Enabling Runtime Monitoring for a standalone account](enable-runtime-monitoring-standalone-acc.md)

# Enabling Runtime Monitoring for multiple-account environments
<a name="enable-runtime-monitoring-multiple-acc-env"></a>

In a multiple-account environments, only the delegated GuardDuty administrator account can enable or disable Runtime Monitoring for the member accounts, and manage automated agent configuration for the resource types belonging to the member accounts in their organization. The GuardDuty member accounts can't modify this configuration from their accounts. The delegated GuardDuty administrator account account manages their member accounts using AWS Organizations. For more information about multi-account environments, see [Managing multiple accounts](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).

## For delegated GuardDuty administrator account
<a name="runtime-monitoring-config-delegated-admin"></a>

**To enable Runtime Monitoring for delegated GuardDuty administrator account**

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. Under the **Configuration** tab, choose **Edit** in the **Runtime Monitoring configuration** section.

1. 

**Using Enable for all accounts**

   If you want to enable Runtime Monitoring for all the accounts that belong to the organization, including the delegated GuardDuty administrator account, then choose **Enable for all accounts**.

1. 

**Using Configure accounts manually**

   If you want to enable Runtime Monitoring for each member account individually, then choose **Configure accounts manually**.

   1. Choose **Enable** under the **Delegated Administrator (this account)** section.

1. For GuardDuty to receive the runtime events from one or more resource types – an Amazon EC2 instance, Amazon ECS cluster, or an Amazon EKS cluster, use the following options to manage the security agent for these resources:

**To enable GuardDuty security agent**
   + [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
   + [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
   + [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
   + [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
   + [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)

## For all member accounts
<a name="runtime-monitoring-config-all-member-accounts"></a>

**To enable Runtime Monitoring for all member accounts in the organization**

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

   Sign in using the delegated GuardDuty administrator account.

1. In the navigation pane, choose **Runtime Monitoring**.

1. On the Runtime Monitoring page, under the **Configuration** tab, choose **Edit** in the **Runtime Monitoring configuration** section.

1. Choose **Enable for all accounts**.

1. For GuardDuty to receive the runtime events from one or more resource types – an Amazon EC2 instance, Amazon ECS cluster, or an Amazon EKS cluster, use the following options to manage the security agent for these resources:

**To enable GuardDuty security agent**
   + [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
   + [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
   + [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
   + [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
   + [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)

## For all existing active member accounts
<a name="runtime-monitoring-all-existing-active-member-accounts"></a>

**To enable Runtime Monitoring for existing member accounts in the organization**

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

   Sign in using the delegated GuardDuty administrator account for the organization.

1. In the navigation pane, choose **Runtime Monitoring**.

1. On the **Runtime Monitoring** page, under the **Configuration** tab, you can view the current status of the Runtime Monitoring configuration. 

1. Within the Runtime Monitoring pane, under the **Active member accounts** section, choose **Actions**.

1. From the **Actions** dropdown menu, choose **Enable for all existing active member accounts**.

1. Choose **Confirm**.

1. For GuardDuty to receive the runtime events from one or more resource types – an Amazon EC2 instance, Amazon ECS cluster, or an Amazon EKS cluster, use the following options to manage the security agent for these resources:

**To enable GuardDuty security agent**
   + [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
   + [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
   + [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
   + [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
   + [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)

**Note**  
It may take up to 24 hours to update the configuration for the member accounts.

## Auto-enable Runtime Monitoring for new member accounts only
<a name="runtime-monitoring-configure-auto-enable-new-members"></a>

**To enable Runtime Monitoring for new member accounts in your organization**

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

   Sign in using the designated delegated GuardDuty administrator account of the organization.

1. In the navigation pane, choose **Runtime Monitoring**

1. Under the **Configuration** tab, choose **Edit** in the **Runtime Monitoring configuration** section.

1. Choose **Configure accounts manually**.

1. Select **Automatically enable for new member accounts**.

1. For GuardDuty to receive the runtime events from one or more resource types – an Amazon EC2 instance, Amazon ECS cluster, or an Amazon EKS cluster, use the following options to manage the security agent for these resources:

**To enable GuardDuty security agent**
   + [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
   + [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
   + [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
   + [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
   + [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)

## For selective active member accounts only
<a name="runtime-monitoring-enable-selective-member-accounts"></a>

**To enable Runtime Monitoring for individual active member accounts**

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

   Sign in using the delegated GuardDuty administrator account credentials.

1. In the navigation pane, choose **Accounts**.

1. On the **Accounts** page, review values in the **Runtime Monitoring** and **Manage agent automatically** columns. These values indicate whether Runtime Monitoring and GuardDuty agent management are **Enabled** or **Not enabled** for the corresponding account.

1. From the Accounts table, select the account for which you want to enable Runtime Monitoring. You can choose multiple accounts at a time.

1. Choose **Confirm**.

1. Choose **Edit protection plans**. Choose the appropriate action.

1. Choose **Confirm**.

1. For GuardDuty to receive the runtime events from one or more resource types – an Amazon EC2 instance, Amazon ECS cluster, or an Amazon EKS cluster, use the following options to manage the security agent for these resources:

**To enable GuardDuty security agent**
   + [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
   + [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
   + [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
   + [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
   + [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)

# Enabling Runtime Monitoring for a standalone account
<a name="enable-runtime-monitoring-standalone-acc"></a>

A standalone account owns the decision to enable or disable a protection plan in their AWS account in a specific AWS Region. 

If your account is associated with a GuardDuty administrator account through AWS Organizations, or by the method of invitation, this section doesn't apply to your account. For more information, see [Enabling Runtime Monitoring for multiple-account environments](enable-runtime-monitoring-multiple-acc-env.md).

After you enable Runtime Monitoring, ensure to install GuardDuty security agent through automated configuration or manual deployment. As a part of completing all the steps listed in the following procedure, make sure to install the security agent.

**To enable Runtime Monitoring in standalone account**

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. Under the **Configuration** tab, choose **Enable** to enable Runtime Monitoring for your account.

1. For GuardDuty to receive the runtime events from one or more resource types – an Amazon EC2 instance, Amazon ECS cluster, or an Amazon EKS cluster, use the following options to manage the security agent for these resources:

**To enable GuardDuty security agent**
   + [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
   + [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
   + [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
   + [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
   + [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)

# Managing GuardDuty security agents
<a name="runtime-monitoring-managing-agents"></a>

You can manage the GuardDuty security agent for the resource that you want to monitor. If you want to monitor more than one resource type, make sure to manage the GuardDuty agent for that resource.

The following topics will help you with the next steps to manage the security agent.

**Topics**
+ [Enabling automated security agent for Amazon EC2 instance](managing-gdu-agent-ec2-automated.md)
+ [Managing security agent manually for Amazon EC2 resource](managing-gdu-agent-ec2-manually.md)
+ [Managing automated security agent for Fargate (Amazon ECS only)](managing-gdu-agent-ecs-automated.md)
+ [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md)
+ [Managing security agent manually for Amazon EKS cluster](managing-gdu-agent-eks-manually.md)
+ [Configure GuardDuty security agent (add-on) parameters for Amazon EKS](guardduty-configure-security-agent-eks-addon.md)
+ [Validating VPC endpoint configuration](validate-vpc-endpoint-config-runtime-monitoring.md)

# Enabling automated security agent for Amazon EC2 instance
<a name="managing-gdu-agent-ec2-automated"></a>

This section includes steps to enable GuardDuty automated agent for your Amazon EC2 resources in your standalone account or a multiple-account environment. 

Before you continue, make sure to follow all the [Prerequisites for Amazon EC2 instance support](prereq-runtime-monitoring-ec2-support.md).

If you are migrating from managing the GuardDuty agent manually to enabling GuardDuty automated agent, then before following the steps to enable GuardDuty automated agent, see [Migrating from Amazon EC2 manual agent to automated agent](migrate-from-ec2-manual-to-automated-agent.md).

# Enabling GuardDuty agent for Amazon EC2 resources in multiple-account environment
<a name="manage-agent-ec2-multi-account-env"></a>

In a multiple-account environments, only the delegated GuardDuty administrator account can enable or disable automated agent configuration for the resource types belonging to the member accounts in their organization. The GuardDuty member accounts can't modify this configuration from their accounts. The delegated GuardDuty administrator account account manages their member accounts using AWS Organizations. For more information about multi-account environments, see [Managing multiple accounts](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).

## For delegated GuardDuty administrator account
<a name="configure-for-delegated-admin"></a>

------
#### [ Configure for all instances ]

If you chose **Enable for all accounts** for Runtime Monitoring, then choose one of the following options for the delegated GuardDuty administrator account:
+ **Option 1**

  Under **Automated agent configuration**, in the **EC2** section, select **Enable for all accounts**.
+ **Option 2**
  + Under **Automated agent configuration**, in the **EC2** section, select **Configure accounts manually**.
  + Under **Delegated Administrator (this account)**, choose **Enable**.
+ Choose **Save**.

If you chose **Configure accounts manually** for Runtime Monitoring, then perform the following steps:
+ Under **Automated agent configuration**, in the **EC2** section, select **Configure accounts manually**.
+ Under **Delegated Administrator (this account)**, choose **Enable**.
+ Choose **Save**.

Regardless of which option you choose to enable the automated agent configuration for delegated GuardDuty administrator account, you can verify that the SSM association that GuardDuty creates will install and manage the security agent on all the EC2 resources belonging to this account.

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Open the **Targets** tab for the SSM association (`GuardDutyRuntimeMonitoring-do-not-delete`). Observe that the **Tag key** appears as **InstanceIds**. 

------
#### [ Using inclusion tag in selected instances ]

**To configure GuardDuty agent for selected Amazon EC2 instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

   Adding this tag will permit GuardDuty to install and manage the security agent for these selected EC2 instances. You **don't** need to enable automated agent configuration explicitly.

1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent only on the EC2 resources that are tagged with the inclusion tags. 

   Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Open the **Targets** tab for the SSM association that gets created (`GuardDutyRuntimeMonitoring-do-not-delete`). The **Tag key** appears as **tag:GuardDutyManaged**.

------
#### [ Using exclusion tag in selected instances ]

**Note**  
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.

**To configure GuardDuty agent for selected Amazon EC2 instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

1. 

**For the [exclusion tags to be available](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:**

   1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**.

      If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step.

   1. Under the **Actions** menu, choose **Instance settings**.

   1. Choose **Allow tags in instance metadata**.

1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab.

------

You can now assess the runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md).

## Auto-enable for all member accounts
<a name="auto-enable-all-member-accounts"></a>

**Note**  
It may take up to 24 hours to update the configuration for the member accounts.

------
#### [ Configure for all instances ]

The following steps assume that you chose **Enable for all accounts** in the Runtime Monitoring section:

1. Choose **Enable for all accounts** in the **Automated agent configuration** section for **Amazon EC2**. 

1. You can verify that the SSM association that GuardDuty creates (`GuardDutyRuntimeMonitoring-do-not-delete`) will install and manage the security agent on all the EC2 resources belonging to this account.

   1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Open the **Targets** tab for the SSM association. Observe that the **Tag key** appears as **InstanceIds**. 

------
#### [ Using inclusion tag in selected instances ]

**To configure GuardDuty agent for selected Amazon EC2 instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`true` tag to the EC2 instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

   Adding this tag will permit GuardDuty to install and manage the security agent for these selected EC2 instances. You **don't ** need to enable automated agent configuration explicitly.

1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent on all the EC2 resources belonging to your account.

   1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Open the **Targets** tab for the SSM association (`GuardDutyRuntimeMonitoring-do-not-delete`). Observe that the **Tag key** appears as **InstanceIds**. 

------
#### [ Using exclusion tag in selected instances ]

**Note**  
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.

**To configure GuardDuty security agent for selected Amazon EC2 instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

1. 

**For the [exclusion tags to be available](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:**

   1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**.

      If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step.

   1. Under the **Actions** menu, choose **Instance settings**.

   1. Choose **Allow tags in instance metadata**.

1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab.

------

You can now assess the runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md).

## Auto-enable for new member accounts only
<a name="auto-enable-new-member-accounts"></a>

The delegated GuardDuty administrator account can set the automated agent configuration for Amazon EC2 resource to enable automatically for the new member accounts as they join the organization. 

------
#### [ Configure for all instances ]

The following steps assume that you selected **Automatically enable for new member accounts** under the **Runtime Monitoring** section:

1. In the navigation pane, choose **Runtime Monitoring**.

1. On the **Runtime Monitoring** page, choose **Edit**.

1. Select **Automatically enable for new member accounts**. This step ensures that whenever a new account joins your organization, automated agent configuration for Amazon EC2 will be automatically enabled for their account. Only the delegated GuardDuty administrator account of the organization can modify this selection.

1. Choose **Save**.

When a new member account joins the organization, this configuration will be enabled for them automatically. For GuardDuty to manage the security agent for the Amazon EC2 instances that belong to this new member account, make sure that all the prerequisites [For EC2 instance](prereq-runtime-monitoring-ec2-support.md) are met.

When an SSM association gets created (`GuardDutyRuntimeMonitoring-do-not-delete`), you can verify that the SSM association will install and manage the security agent on all the EC2 instances belonging to the new member account.
+ Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
+ Open the **Targets** tab for the SSM association. Observe that the **Tag key** appears as **InstanceIds**.

------
#### [ Using inclusion tag in selected instances ]

**To configure GuardDuty security agent for selected instances in your account**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

   Adding this tag will permit GuardDuty to install and manage the security agent for these selected instances. You don't need to enable automated agent configuration explicitly.

1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent only on the EC2 resources that are tagged with the inclusion tags. 

   1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Open the **Targets** tab for the SSM association that gets created. The **Tag key** appears as **tag:GuardDutyManaged**.

------
#### [ Using exclusion tag in selected instances ]

**Note**  
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.

**To configure GuardDuty security agent for specific instances in your standalone account**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

1. 

**For the [exclusion tags to be available](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:**

   1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**.

      If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step.

   1. Under the **Actions** menu, choose **Instance settings**.

   1. Choose **Allow tags in instance metadata**.

1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab.

------

You can now assess the runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md).

## Selective member accounts only
<a name="enable-selective-member-accounts-only"></a>

------
#### [ Configure for all instances ]

1. On the **Accounts** page, select one or more accounts for which you want to enable **Runtime Monitoring-Automated agent configuration (Amazon EC2)**. Make sure that the accounts that you select in this step already have Runtime Monitoring enabled.

1. From **Edit protection plans**, choose the appropriate option to enable **Runtime Monitoring-Automated agent configuration (Amazon EC2)**.

1. Choose **Confirm**.

------
#### [ Using inclusion tag in selected instances ]

**To configure GuardDuty security agent for selected instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

   Adding this tag will permit GuardDuty to manage the security agent for your tagged Amazon EC2 instances. You don't need to explicitly enable automated agent configuration (**Runtime Monitoring - Automated agent configuration (EC2)**.

------
#### [ Using exclusion tag in selected instances ]

**Note**  
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.

**To configure GuardDuty security agent for selected instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`false` tag to the EC2 instances that you **don't** want GuardDuty to monitor or detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

1. 

**For the [exclusion tags to be available](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:**

   1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**.

      If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step.

   1. Under the **Actions** menu, choose **Instance settings**.

   1. Choose **Allow tags in instance metadata**.

1. After you have added the exclusion tag, perform the same steps as specified in the **Configure for all instances** tab.

------

You can now assess [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md).

# Enabling GuardDuty automated agent for Amazon EC2 resources in a standalone account
<a name="manage-agent-ec2-standalone-account"></a>

A standalone account owns the decision to enable or disable a protection plan in their AWS account in a specific AWS Region. 

If your account is associated with a GuardDuty administrator account through AWS Organizations, or by the method of invitation, this section doesn't apply to your account. For more information, see [Enabling Runtime Monitoring for multiple-account environments](enable-runtime-monitoring-multiple-acc-env.md).

After you enable Runtime Monitoring, ensure to install GuardDuty security agent through automated configuration or manual deployment. As a part of completing all the steps listed in the following procedure, make sure to install the security agent.

Based on your preference to monitor all or selective Amazon EC2 resources, choose a preferred method and follow the steps in the following table.

------
#### [ Configure for all instances ]

**To configure Runtime Monitoring for all instances in your standalone account**

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. Under the **Configuration** tab, choose **Edit**.

1. In the **EC2** section, choose **Enable**.

1. Choose **Save**.

1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent on all the EC2 resources belonging to your account.

   1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Open the **Targets** tab for the SSM association (`GuardDutyRuntimeMonitoring-do-not-delete`). Observe that the **Tag key** appears as **InstanceIds**. 

------
#### [ Using inclusion tag in selected instances ]

**To configure GuardDuty security agent for selected Amazon EC2 instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`true` tag to the instances that you want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

1. You can verify that the SSM association that GuardDuty creates will install and manage the security agent only on the EC2 resources that are tagged with the inclusion tags. 

   Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Open the **Targets** tab for the SSM association that gets created (`GuardDutyRuntimeMonitoring-do-not-delete`). The **Tag key** appears as **tag:GuardDutyManaged**.

------
#### [ Using exclusion tag in selected instances ]

**Note**  
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.

**To configure GuardDuty security agent for selected Amazon EC2 instances**

1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Add the `GuardDutyManaged`:`false` tag to the instances that you **don't** want GuardDuty to monitor and detect potential threats. For information about adding this tag, see [To add a tag to an individual resource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).

1. 

**For the [exclusion tags to be available](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) in the instance metadata, perform the following steps:**

   1. Under the **Details** tab of your instance, view the status for **Allow tags in instance metadata**.

      If it is currently **Disabled**, use the following steps to change the status to **Enabled**. Otherwise, skip this step.

   1. Select the instance for which you want to allow tags.

   1. Under the **Actions** menu, choose **Instance settings**.

   1. Choose **Allow tags in instance metadata**.

   1. Under **Access to tags in instance metadata**, select **Allow**.

   1. Choose **Save**.

1. After you have added the exclusion tag perform the same steps as sepcified in the **Configure for all instances** tab.

------

You can now assess runtime [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md).

# Migrating from Amazon EC2 manual agent to automated agent
<a name="migrate-from-ec2-manual-to-automated-agent"></a>

This section applies to your AWS account if you were previously managing the security agent manually and now want to use the GuardDuty automated agent configuration. If this doesn't apply to you, continue with configuring the security agent for your account.

When you enable GuardDuty automated agent, GuardDuty manages the security agent on your behalf. For information about what steps does GuardDuty take, see [Use automated agent configuration (recommended)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2).

## Clean up resources
<a name="ec2-clean-up-migrate-from-manual-to-automated"></a>

**Delete SSM association**  
+ Delete any SSM association that you may have created when you were managing the security agent for Amazon EC2 manually. For more information, see [Deleting associations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html).
+ This is done so that GuardDuty can take over the management of SSM actions whether you use automated agents at the account level or instance level (by using inclusion or exclusion tags). For more information about what SSM actions can GuardDuty take, see [Service-linked role permissions for GuardDuty](slr-permissions.md).
+ When you delete an SSM association that was previously created for managing the security agent manually, there might be a brief period of overlap when GuardDuty creates an SSM association for managing the security agent automatically. During this period, you could experience conflicts based on SSM scheduling. For more information, see [Amazon EC2 SSM scheduling](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-scheduler.html).

**Manage inclusion and exclusion tags for your Amazon EC2 instances**  
+ **Inclusion tags** – When you don't enable GuardDuty automated agent configuration but tag any of your Amazon EC2 instances with an inclusion tag (`GuardDutyManaged`:`true`), GuardDuty creates an SSM association that will install and manage the security agent on the selected EC2 instances. This is an expected behavior that helps you manage the security agent on selected EC2 instances only. For more information, see [How Runtime Monitoring works with Amazon EC2 instances](how-runtime-monitoring-works-ec2.md).

  To prevent GuardDuty from installing and managing the security agent, remove the inclusion tag from these EC2 instances. For more information, see [Add and delete tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags) in the *Amazon EC2 User Guide*.
+ **Exclusion tags** – When you want to enable GuardDuty automated agent configuration for all the EC2 instances in your account, make sure that no EC2 instance is tagged with an exclusion tag (`GuardDutyManaged`:`false`).

# Managing security agent manually for Amazon EC2 resource
<a name="managing-gdu-agent-ec2-manually"></a>

This section provides the steps to manually install and update the security agent for your Amazon EC2 resources.

After you enable Runtime Monitoring, you will need to install the GuardDuty security agent manually. To manage the GuardDuty security agent manually, you must first create an Amazon VPC endpoint manually. After this, you can install the security agent so that GuardDuty will start receiving the runtime events from the Amazon EC2 instances. When GuardDuty releases a new agent version for this resource, you can update the agent version in your account.

The following topics include the steps to continuously manage the security agent for your Amazon EC2 resources.

**Topics**
+ [Prerequisite – Creating Amazon VPC endpoint manually](creating-vpc-endpoint-ec2-agent-manually.md)
+ [Installing the security agent manually](installing-gdu-security-agent-ec2-manually.md)
+ [Updating the GuardDuty security agent for Amazon EC2 instance manually](gdu-update-security-agent-ec2.md)

# Prerequisite – Creating Amazon VPC endpoint manually
<a name="creating-vpc-endpoint-ec2-agent-manually"></a>

Before you can install the GuardDuty security agent, you must create an Amazon Virtual Private Cloud (Amazon VPC) endpoint. This will help GuardDuty receive the runtime events of your Amazon EC2 instances.

**Note**  
There is no additional cost for the usage of the VPC endpoint.

**To create a Amazon VPC endpoint**

1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **VPC private cloud**, choose **Endpoints**.

1. Choose **Create Endpoint**.

1. On the **Create endpoint** page, for **Service category**, choose **Other endpoint services**.

1. For **Service name**, enter **com.amazonaws.*us-east-1*.guardduty-data**.

   Make sure to replace *us-east-1* with your AWS Region. This must be the same Region as the Amazon EC2 instance that belongs to your AWS account ID.

1. Choose **Verify service**.

1. After the service name is successfully verified, choose the **VPC** where your instance resides. Add the following policy to restrict Amazon VPC endpoint usage to the specified account only. With the organization `Condition` provided below this policy, you can update the following policy to restrict access to your endpoint. To provide the Amazon VPC endpoint support to specific account IDs in your organization, see [Organization condition to restrict access to your endpoint](#gdu-runtime-ec2-organization-restrict-access-vpc-endpoint).

------
#### [ JSON ]

****  

   ```
   {
   	"Version":"2012-10-17",		 	 	 
   	"Statement": [
   		{
   			"Action": "*",
   			"Resource": "*",
   			"Effect": "Allow",
   			"Principal": "*"
   		},
   		{
   			"Condition": {
   				"StringNotEquals": {
   					"aws:PrincipalAccount": "111122223333" 
   				}
   			},
   			"Action": "*",
   			"Resource": "*",
   			"Effect": "Deny",
   			"Principal": "*"
   		}
   	]
   }
   ```

------

   The `aws:PrincipalAccount` account ID must match the account containing the VPC and VPC endpoint. The following list shows how to share the VPC endpoint with other AWS account IDs:<a name="gdu-runtime-ec2-organization-restrict-access-vpc-endpoint"></a>
   + To specify multiple accounts to access the VPC endpoint, replace `"aws:PrincipalAccount: "111122223333"` with the following block:

     ```
     "aws:PrincipalAccount": [
               "666666666666",
               "555555555555"
           ]
     ```

     Make sure to replace the AWS account IDs with the account IDs of those accounts that need to access the VPC endpoint.
   + To allow all the members from an organization to access the VPC endpoint, replace `"aws:PrincipalAccount: "111122223333"` with the following line:

     ```
     "aws:PrincipalOrgID": "o-abcdef0123"
     ```

     Make sure to replace the organization *o-abcdef0123* with your organization ID.
   + To restrict accessing a resource by an organization ID, add your `ResourceOrgID` to the policy. For more information, see [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid) in the *IAM User Guide*.

     ```
     "aws:ResourceOrgID": "o-abcdef0123"
     ```

1. Under **Additional settings**, choose **Enable DNS name**.

1. Under **Subnets**, choose the subnets in which your instance resides.

1. Under **Security groups**, choose a security group that has the in-bound port 443 enabled from your VPC (or your Amazon EC2 instance). If you don't already have a security group that has an in-bound port 443 enabled, see [Create a security group for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) in the *Amazon VPC User Guide*.

   If there is an issue while restricting the in-bound permissions to your VPC (or instance), you can the in-bound 443 port from any IP address `(0.0.0.0/0)`. However, GuardDuty recommends using IP addresses that matches the CIDR block for your VPC. For more information, see [VPC CIDR blocks](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*.

After you have followed the steps, see [Validating VPC endpoint configuration](validate-vpc-endpoint-config-runtime-monitoring.md) to ensure that the VPC endpoint was set up correctly.

# Installing the security agent manually
<a name="installing-gdu-security-agent-ec2-manually"></a>

GuardDuty provides the following two methods to install the GuardDuty security agent on your Amazon EC2 instances. Before proceeding, make sure to follow the steps under [Prerequisite – Creating Amazon VPC endpoint manually](creating-vpc-endpoint-ec2-agent-manually.md).

Choose a preferred access method to install the security agent in your Amazon EC2 resources.
+ [Method 1 - Using AWS Systems Manager](#install-gdu-by-using-sys-runtime-monitoring) – This method requires your Amazon EC2 instance to be AWS Systems Manager managed.
+ [Method 2 - Using Linux Package Managers](#install-gdu-by-rpm-scripts-runtime-monitoring) – You can use this method whether or not your Amazon EC2 instances are AWS Systems Manager managed. Based on your [OS distributions](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#validating-architecture-req-ec2), you can choose an appropriate method to install either RPM scripts or Debian scripts. If you use *Fedora* platform, then you must use this method to install the agent.

## Method 1 - Using AWS Systems Manager
<a name="install-gdu-by-using-sys-runtime-monitoring"></a>

To use this method, make sure that your Amazon EC2 instances are AWS Systems Manager managed and then install the agent.

### AWS Systems Manager managed Amazon EC2 instance
<a name="manage-ssm-ec2-instance-runtime-monitoring"></a>

Use the following steps to make your Amazon EC2 instances AWS Systems Manager managed.
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) helps you manage your AWS applications and resources end-to-end and enable secure operations at scale. 

  To manage your Amazon EC2 instances with AWS Systems Manager, see [Setting up Systems Manager for Amazon EC2 instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) in the *AWS Systems Manager User Guide*.
+ The following table shows the new GuardDuty managed AWS Systems Manager documents:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)

  For more information about AWS Systems Manager, see [Amazon EC2 Systems Manager Documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html) in the *AWS Systems Manager User Guide*.
**For Debian Servers**  
The Amazon Machine Images (AMIs) for Debian Server provided by AWS require you to install the AWS Systems Manager agent (SSM agent). You will need to perform an additional step to install the SSM agent to make your Amazon EC2 Debian Server instances SSM managed. For information about steps that you need to take, see [Manually installing SSM agent on Debian Server instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html) in the *AWS Systems Manager User Guide*.

**To install the GuardDuty agent for Amazon EC2 instance by using AWS Systems Manager**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Documents**

1. In **Owned by Amazon**, choose `AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin`.

1. Choose **Run Command**.

1. Enter the following Run Command parameters
   + Action: Choose **Install**.
   + Installation Type: Choose **Install or Uninstall.**
   + Name: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin`
   + Version: If this remains empty, you'll get latest version of the GuardDuty security agent. For more information about the release versions, [GuardDuty security agent versions for Amazon EC2 instances](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history).

1. Select the targeted Amazon EC2 instance. You can select one or more Amazon EC2 instances. For more information, see [AWS Systems Manager Running commands from the console](https://docs.aws.amazon.com/systems-manager/latest/userguide/running-commands-console.html) in the *AWS Systems Manager User Guide* 

1. Validate if the GuardDuty agent installation is healthy. For more information, see [Validating GuardDuty security agent installation status](#validate-ec2-gdu-agent-installation-healthy).

## Method 2 - Using Linux Package Managers
<a name="install-gdu-by-rpm-scripts-runtime-monitoring"></a>

With this method, you can install the GuardDuty security agent by running RPM scripts or Debian scripts. Based on the operating systems, you can choose a preferred method:
+ Use RPM scripts to install the security agent on OS distributions AL2, AL2023, RedHat, CentOS, or Fedora.
+ Use Debian scripts to install the security agent on OS distributions Ubuntu or Debian. For information about supported Ubuntu and Debian OS distributions, see [Validate architectural requirements](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2).

------
#### [ RPM installation ]
**Important**  
We recommend verifying the GuardDuty security agent RPM signature before installing it on your machine. 

1. Verify the GuardDuty security agent RPM signature

   1. 

**Prepare the template**

      Prepare the commands with appropriate public key, signature of x86\$164 RPM, signature of arm64 RPM, and the corresponding access link to the RPM scripts hosted in Amazon S3 buckets. Replace the value of the AWS Region, AWS account ID, and the GuardDuty agent version to access the RPM scripts.
      + **Public key**: 

        ```
        s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem
        ```
      + **GuardDuty security agent RPM signature**:  
Signature of x86\$164 RPM  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig
        ```  
Signature of arm64 RPM  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig
        ```
      + **Access links to the RPM scripts in Amazon S3 bucket**:  
Access link for x86\$164 RPM  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm
        ```  
Access link for arm64 RPM  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.rpm
        ```    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)

   1. 

**Download the template**

      In the following command to download appropriate public key, signature of x86\$164 RPM, signature of arm64 RPM, and the corresponding access link to the RPM scripts hosted in Amazon S3 buckets, make sure to replace the account ID with the appropriate AWS account ID and the Region with your current Region. 

      ```
      aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm ./amazon-guardduty-agent-1.9.2.x86_64.rpm
      aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig ./amazon-guardduty-agent-1.9.2.x86_64.sig
      aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem ./publickey.pem
      ```

   1. 

**Import the public key**

      Use the following command to import the public key to the database:

      ```
      gpg --import publickey.pem
      ```

      gpg shows import successfully

      ```
      gpg: key 093FF49D: public key "AwsGuardDuty" imported
      gpg: Total number processed: 1
      gpg:               imported: 1  (RSA: 1)
      ```

   1. 

**Verify the signature**

      Use the following command to verify the signature

      ```
      gpg --verify amazon-guardduty-agent-1.9.2.x86_64.sig amazon-guardduty-agent-1.9.2.x86_64.rpm
      ```

      If verification passes, you will see a message similar to the result below. You can now proceed to install the GuardDuty security agent using RPM.

      Example output:

      ```
      gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
      gpg: Good signature from "AwsGuardDuty"
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: 7478 91EF 5378 1334 4456  7603 06C9 06A7 093F F49D
      ```

      If verification fails, it means the signature on RPM has been potentially tampered. You must remove the public key from the database and retry the verification process.

      Example: 

      ```
      gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
      gpg: BAD signature from "AwsGuardDuty"
      ```

      Use the following command to remove the public key from the database:

      ```
      gpg --delete-keys AwsGuardDuty
      ```

      Now, try the verification process again.

1. [Connect with SSH from Linux or macOS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html).

1. Install the GuardDuty security agent by using the following command:

   ```
   sudo rpm -ivh amazon-guardduty-agent-1.9.2.x86_64.rpm
   ```

1. Validate if the GuardDuty agent installation is healthy. For more information about the steps, see [Validating GuardDuty security agent installation status](#validate-ec2-gdu-agent-installation-healthy).

------
#### [ Debian installation ]
**Important**  
We recommend verifying the GuardDuty security agent Debian signature before installing it on your machine. 

1. Verify the GuardDuty security agent Debian signature

   1. 

**Prepare templates for the appropriate public key, signature of amd64 Debian package, signature of arm64 Debian package, and the corresponding access link to the Debian scripts hosted in Amazon S3 buckets**

      In the following templates, replace the value of the AWS Region, AWS account ID, and the GuardDuty agent version to access the Debian package scripts. 
      + **Public key**: 

        ```
        s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem
        ```
      + **GuardDuty security agent Debian signature**:  
Signature of amd64  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig
        ```  
Signature of arm64  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig
        ```
      + **Access links to the Debian scripts in Amazon S3 bucket**:  
Access link for amd64  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb
        ```  
Access link for arm64  

        ```
        s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.deb
        ```    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)

   1. 

**Download the appropriate public key, signature of amd64, signature of arm64, and the corresponding access link to the Debian scripts hosted in Amazon S3 buckets**

      In the following commands, replace the account ID with the appropriate AWS account ID, and the Region with your current Region. 

      ```
      aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb ./amazon-guardduty-agent-1.9.2.amd64.deb
      aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig ./amazon-guardduty-agent-1.9.2.amd64.sig
      aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem ./publickey.pem
      ```

   1. Import the public key to the database

      ```
      gpg --import publickey.pem
      ```

      gpg shows import successfully

      ```
      gpg: key 093FF49D: public key "AwsGuardDuty" imported
      gpg: Total number processed: 1
      gpg:               imported: 1  (RSA: 1)
      ```

   1. Verify the signature

      ```
      gpg --verify amazon-guardduty-agent-1.9.2.amd64.sig amazon-guardduty-agent-1.9.2.amd64.deb
      ```

      After a successful verification, you will see a message similar to the following result:

      Example output:

      ```
      gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
      gpg: Good signature from "AwsGuardDuty"
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: 7478 91EF 5378 1334 4456  7603 06C9 06A7 093F F49D
      ```

      You can now proceed to install the GuardDuty security agent using Debian.

      However, if verification fails, it means the signature in Debian package has been potentially tampered. 

      Example: 

      ```
      gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
      gpg: BAD signature from "AwsGuardDuty"
      ```

      Use the following command to remove the public key from the database:

      ```
      gpg --delete-keys AwsGuardDuty
      ```

      Now, retry the verification process.

1. [Connect with SSH from Linux or macOS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html).

1. Install the GuardDuty security agent by using the following command:

   ```
   sudo dpkg -i amazon-guardduty-agent-1.9.2.amd64.deb
   ```

1. Validate if the GuardDuty agent installation is healthy. For more information about the steps, see [Validating GuardDuty security agent installation status](#validate-ec2-gdu-agent-installation-healthy).

------

## Out of memory error
<a name="out-of-memory-error-ec2-instal-agent-manual"></a>

If you experience an `out-of-memory` error while installing or updating the GuardDuty security agent for Amazon EC2 manually, see [Troubleshooting out of memory error](troubleshooting-guardduty-runtime-monitoring.md#troubleshoot-ec2-cpu-out-of-memory-error).

## Validating GuardDuty security agent installation status
<a name="validate-ec2-gdu-agent-installation-healthy"></a>

After you have performed the steps to install the GuardDuty security agent, use the following steps to validate the status of the agent:

**To validate if the GuardDuty security agent is healthy**

1. [Connect with SSH from Linux or macOS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html).

1. Run the following command to check the status of the GuardDuty security agent:

   ```
   sudo systemctl status amazon-guardduty-agent
   ```

If you want to view the security agent installation logs, they are available under `/var/log/amzn-guardduty-agent/`.

To view the logs, do `sudo journalctl -u amazon-guardduty-agent`.

# Updating the GuardDuty security agent for Amazon EC2 instance manually
<a name="gdu-update-security-agent-ec2"></a>

GuardDuty releases updates to the security agent versions. When you manage the security agent manually, you're responsible to update the agent for your Amazon EC2 instances. For information about new agent versions, see [GuardDuty security agent release versions](runtime-monitoring-agent-release-history.md) for Amazon EC2 instances. To receive notifications about a new agent version release, see [Subscribing to Amazon SNS GuardDuty announcements](guardduty_sns.md).

**To update the security agent for Amazon EC2 instance manually**  
The process to update the security agent is the same as installing the security agent. Depending on the method that you used to install the agent, you can perform the steps in [Installing the security agent manually](installing-gdu-security-agent-ec2-manually.md) for Amazon EC2 instances.  
If you use [Method 1 - By using AWS Systems Manager](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#manage-ssm-ec2-instance-runtime-monitoring), then you can update the security agent by using the **Run command**. Use the agent version to which you want to update.  
If you use [Method 2 - By using Linux Package Managers](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#heading:r2l:), you can use the scripts as specified in the [Installing the security agent manually](installing-gdu-security-agent-ec2-manually.md) section. The scripts already include the latest agent release version. For information about recently released agent versions, see [GuardDuty security agent versions for Amazon EC2 instances](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history).

After you update the security agent, you can check the installation status by looking at the logs. For more information, see [Validating GuardDuty security agent installation status](installing-gdu-security-agent-ec2-manually.md#validate-ec2-gdu-agent-installation-healthy).

# Managing automated security agent for Fargate (Amazon ECS only)
<a name="managing-gdu-agent-ecs-automated"></a>

Runtime Monitoring supports managing the security agent for your Amazon ECS clusters (AWS Fargate) only through GuardDuty. There is no support for managing the security agent manually on Amazon ECS clusters.

Before proceeding with the steps in this section, make sure to follow [Prerequisites for AWS Fargate (Amazon ECS only) support](prereq-runtime-monitoring-ecs-support.md).

Based on the [Approaches to manage GuardDuty security agent in Amazon ECS-Fargate resources](how-runtime-monitoring-works-ecs-fargate.md#gdu-runtime-approaches-agent-deployment-ecs-clusters), choose a preferred method to enable GuardDuty automated agent for your resources.

**Topics**

## Configuring GuardDuty agent for multi-account environment
<a name="ecs-fargate-manage-agent-multiple-accounts"></a>

In a multiple-account environment, only the delegated GuardDuty administrator account can enable or disable automated agent configuration for the member accounts, and manage automated agent configuration for Amazon ECS clusters that belong to the member accounts in their organization. A GuardDuty member account can't modify this configuration. The delegated GuardDuty administrator account manages their member accounts using AWS Organizations. For more information about multi-account environments, see [Managing multiple accounts in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).

### Enabling automated agent configuration for delegated GuardDuty administrator account
<a name="ecs-enable-automated-agent-config-delegatedadmin"></a>

------
#### [ Manage for all Amazon ECS clusters (account level) ]

If you chose **Enable for all accounts** for Runtime Monitoring, then you have the following options:
+ Choose **Enable for all accounts** in the Automated agent configuration section. GuardDuty will deploy and manage the security agent for all the Amazon ECS tasks that get launched.
+ Choose **Configure accounts manually**.

If you chose **Configure accounts manually** in the Runtime Monitoring section, then do the following:

1. Choose **Configure accounts manually** in the Automated agent configuration section.

1. Choose **Enable** in the **delegated GuardDuty administrator account (this account)** section.

Choose **Save**.

When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

For steps to update the service, see the following resources:
+ [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]

1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`.

1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. 
**Note**  
Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched.

   Under the **Configuration** tab, choose **Enable** in the **Automated agent configuration**.

   For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container.

1. Choose **Save**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]

1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`.

1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------
**Note**  
When using inclusion tags for your Amazon ECS clusters, you don't need to enable GuardDuty agent through automated agent congifuration explicitly.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------

### Auto-enable for all member accounts
<a name="ecs-auto-enable-all-member-accounts"></a>

------
#### [ Manage for all Amazon ECS clusters (account level) ]

The following steps assume that you chose **Enable for all accounts** in the Runtime Monitoring section.

1. Choose **Enable for all accounts** in the Automated agent configuration section. GuardDuty will deploy and manage the security agent for all the Amazon ECS tasks that get launched.

1. Choose **Save**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]

1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`.

1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. 
**Note**  
Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched.

   Under the **Configuration** tab, choose **Edit**.

1. Choose **Enable for all accounts** in the **Automated agent configuration** section

   For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container.

1. Choose **Save**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for selective (inclusion-only) Amazon ECS clusters (cluster level) ]

Regardless of how you choose to enable Runtime Monitoring, the following steps will help you monitor selective Amazon ECS Fargate tasks for all of the member accounts in your organization.

1. Do not enable any configuration in the Automated agent configuration section. Keep the Runtime Monitoring configuration the same as you selected in the previous step.

1. Choose **Save**.

1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------
**Note**  
When using inclusion tags for your Amazon ECS clusters, you don't need to enable **GuardDuty agent auto-management** explicitly.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------

### Enabling automated agent configuration for existing active member accounts
<a name="ecs-enable-existing-active-member-accounts"></a>

------
#### [ Manage for all Amazon ECS clusters (account level) ]

1. On the Runtime Monitoring page, under the **Configuration** tab, you can view the current status of Automated agent configuration.

1. Within the Automated agent configuration pane, under the **Active member accounts** section, choose **Actions**.

1. From **Actions**, choose **Enable for all existing active member accounts**. 

1. Choose **Confirm**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]

1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`.

1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. 
**Note**  
Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched.

   Under the **Configuration** tab, in the Automated agent configuration section, under **Active member accounts**, choose **Actions**.

1. From **Actions**, choose **Enable for all active member accounts**.

   For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container.

1. Choose **Confirm**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]

1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`.

1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------
**Note**  
When using inclusion tags for your Amazon ECS clusters, you don't need to enable **Automated agent configuration** explicitly.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------

### Auto-enable Automated agent configuration for new members
<a name="ecs-auto-enable-new-members-only"></a>

------
#### [ Manage for all Amazon ECS clusters (account level) ]

1. On the Runtime Monitoring page, choose **Edit** to update the existing configuration.

1. In the Automated agent configuration section, select **Automatically enable for new member accounts**.

1. Choose **Save**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]

1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`.

1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. 
**Note**  
Always add the exclusion tag to your Amazon ECS clusters before enabling Automated agent configuration for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched.

   Under the **Configuration** tab, select **Automatically enable for new member accounts** in the **Automated agent configuration** section.

   For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container.

1. Choose **Save**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]

1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`.

1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------
**Note**  
When using inclusion tags for your Amazon ECS clusters, you don't need to enable **Automated agent configuration** explicitly.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------

### Enabling Automated agent configuration for active member accounts selectively
<a name="ecs-enable-gdu-agent-individual-active-members"></a>

------
#### [ Manage for all Amazon ECS (account level) ]

1. On the Accounts page, select the accounts for which you want to enable Runtime Monitoring-Automated agent configuration (ECS-Fargate). You can select multiple accounts. Make sure that the accounts that you select in this step are already enabled with Runtime Monitoring.

1. From **Edit protection plans**, choose the appropriate option to enable **Runtime Monitoring-Automated agent configuration (ECS-Fargate)**.

1. Choose **Confirm**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]

1. Add a tag to this Amazon ECS cluster with the key-value pair as `GuardDutyManaged`-`false`.

1. Prevent modification of tags, except by the trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. 
**Note**  
Always add the exclusion tag to your Amazon ECS clusters before enabling GuardDuty agent auto-management for your account; otherwise the GuardDuty sidecar container will be attached to all the containers in the Amazon ECS tasks that get launched.

   On the Accounts page, select the accounts for which you want to enable Runtime Monitoring-Automated agent configuration (ECS-Fargate). You can select multiple accounts. Make sure that the accounts that you select in this step are already enabled with Runtime Monitoring.

   For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container.

1. From **Edit protection plans**, choose the appropriate option to enable **Runtime Monitoring-Automated agent configuration (ECS-Fargate)**.

1. Choose **Save**.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]

1. Make sure you don't enable **Automated agent configuration** (or **Runtime Monitoring-Automated agent configuration (ECS-Fargate)**) for the selected accounts that have the Amazon ECS clusters that you want to monitor. 

1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`.

1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "Null": {
                       "ecs:ResourceTag/GuardDutyManaged": false
                   }
               }
           },
           {
               "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
               "Effect": "Deny",
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],
               "Resource": [
                   "*"
               ],
               "Condition": {
                   "StringNotEquals": {
                       "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },
                   "ForAnyValue:StringEquals": {
                       "aws:TagKeys": [
                           "GuardDutyManaged"
                       ]   
                   }   
               }
           },
           {       
               "Sid": "DenyModifyTagsIfPrinTagNotExists",
               "Effect": "Deny", 
               "Action": [
                   "ecs:TagResource",
                   "ecs:UntagResource"
               ],      
               "Resource": [
                   "*"     
               ],      
               "Condition": {
                   "StringNotEquals": {
                       "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                   },      
                   "Null": {
                       "aws:PrincipalTag/GuardDutyManaged": true
                   }       
               }       
           }
       ]
   }
   ```

------
**Note**  
When using inclusion tags for your Amazon ECS clusters, you don't need to enable **Automated agent configuration** explicitly.

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

------

## Configuring GuardDuty agent for a standalone account
<a name="ecs-fargate-manage-agent-standalone-account"></a>

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. Under the **Configuration** tab:

   1. 

**To manage Automated agent configuration for all Amazon ECS clusters (account level)**

      Choose **Enable** in the **Automated agent configuration** section for **AWS Fargate (ECS only)**. When a new Fargate Amazon ECS task launches, GuardDuty will manage the deployment of the security agent.

      1. Choose **Save**.

   1. 

**To manage Automated agent configuration by excluding some of the Amazon ECS clusters (cluster level)**

      1. Add a tag to the Amazon ECS cluster for which you want to exclude all of the tasks. The key-value pair must be `GuardDutyManaged`-`false`.

      1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

         ```
         {
             "Version":"2012-10-17",		 	 	 
             "Statement": [
                 {
                     "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
                     "Effect": "Deny",
                     "Action": [
                         "ecs:TagResource",
                         "ecs:UntagResource"
                     ],
                     "Resource": [
                         "*"
                     ],
                     "Condition": {
                         "StringNotEquals": {
                             "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                             "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                         },
                         "Null": {
                             "ecs:ResourceTag/GuardDutyManaged": false
                         }
                     }
                 },
                 {
                     "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
                     "Effect": "Deny",
                     "Action": [
                         "ecs:TagResource",
                         "ecs:UntagResource"
                     ],
                     "Resource": [
                         "*"
                     ],
                     "Condition": {
                         "StringNotEquals": {
                             "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                             "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                         },
                         "ForAnyValue:StringEquals": {
                             "aws:TagKeys": [
                                 "GuardDutyManaged"
                             ]   
                         }   
                     }
                 },
                 {       
                     "Sid": "DenyModifyTagsIfPrinTagNotExists",
                     "Effect": "Deny", 
                     "Action": [
                         "ecs:TagResource",
                         "ecs:UntagResource"
                     ],      
                     "Resource": [
                         "*"     
                     ],      
                     "Condition": {
                         "StringNotEquals": {
                             "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                         },      
                         "Null": {
                             "aws:PrincipalTag/GuardDutyManaged": true
                         }       
                     }       
                 }
             ]
         }
         ```

------

      1. Under the **Configuration** tab, choose **Enable** in the **Automated agent configuration** section.
**Note**  
Always add the exclusion tag to your Amazon ECS cluster before enabling GuardDuty agent auto-management for your account; otherwise, the security agent will be deployed in all the tasks that are launched within the corresponding Amazon ECS cluster.

         For the Amazon ECS clusters that have not been excluded, GuardDuty will manage the deployment of the security agent in the sidecar container.

      1. Choose **Save**.

   1. 

**To manage Automated agent configuration by including some of the Amazon ECS clusters (cluster level)**

      1. Add a tag to an Amazon ECS cluster for which you want to include all of the tasks. The key-value pair must be `GuardDutyManaged`-`true`.

      1. Prevent modification of these tags, except by trusted entities. The policy provided in [Prevent tags from being modified except by authorized principles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) in the *AWS Organizations User Guide* has been modified to be applicable here.

------
#### [ JSON ]

****  

         ```
         {
             "Version":"2012-10-17",		 	 	 
             "Statement": [
                 {
                     "Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
                     "Effect": "Deny",
                     "Action": [
                         "ecs:TagResource",
                         "ecs:UntagResource"
                     ],
                     "Resource": [
                         "*"
                     ],
                     "Condition": {
                         "StringNotEquals": {
                             "ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                             "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                         },
                         "Null": {
                             "ecs:ResourceTag/GuardDutyManaged": false
                         }
                     }
                 },
                 {
                     "Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
                     "Effect": "Deny",
                     "Action": [
                         "ecs:TagResource",
                         "ecs:UntagResource"
                     ],
                     "Resource": [
                         "*"
                     ],
                     "Condition": {
                         "StringNotEquals": {
                             "aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
                             "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                         },
                         "ForAnyValue:StringEquals": {
                             "aws:TagKeys": [
                                 "GuardDutyManaged"
                             ]   
                         }   
                     }
                 },
                 {       
                     "Sid": "DenyModifyTagsIfPrinTagNotExists",
                     "Effect": "Deny", 
                     "Action": [
                         "ecs:TagResource",
                         "ecs:UntagResource"
                     ],      
                     "Resource": [
                         "*"     
                     ],      
                     "Condition": {
                         "StringNotEquals": {
                             "aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
                         },      
                         "Null": {
                             "aws:PrincipalTag/GuardDutyManaged": true
                         }       
                     }       
                 }
             ]
         }
         ```

------

1. When you want GuardDuty to monitor tasks that are part of a service, it requires a new service deployment after you enable Runtime Monitoring. If the last deployment for a specific ECS service was started before you enabled Runtime Monitoring, you can either restart the service, or update the service by using `forceNewDeployment`.

   For steps to update the service, see the following resources:
   + [Updating an Amazon ECS service using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.
   + [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) in the *Amazon Elastic Container Service API Reference*.
   + [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in the *AWS CLI Command Reference*.

# Managing security agent automatically for Amazon EKS resources
<a name="managing-gdu-agent-eks-automatically"></a>

Runtime Monitoring supports enabling the security agent through GuardDuty automated configuration and manually. This section provides the steps to enable automated agent configuration for Amazon EKS clusters.

Before proceeding, make sure that you have followed the [Prerequisites for Amazon EKS cluster support](prereq-runtime-monitoring-eks-support.md).

Based on your preferred approach on how to [Manage security agent through GuardDuty](how-runtime-monitoring-works-eks.md#eks-runtime-using-gdu-agent-management-auto), choose the steps in the following sections accordingly.

## Configuring Automated agent for multi-account environments
<a name="eks-runtime-monitoring-agent-manage-multiple-account"></a>

In a multiple-account environments, only the delegated GuardDuty administrator account can enable or disable Automated agent configuration for the member accounts, and manage Automated agent for the EKS clusters belonging to the member accounts in their organization. The GuardDuty member accounts can't modify this configuration from their accounts. The delegated GuardDuty administrator account account manages their member accounts using AWS Organizations. For more information about multi-account environments, see [Managing multiple accounts](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).

### Configuring Automated agent configuration for delegated GuardDuty administrator account
<a name="eks-runtime-configure-agent-delegated-admin"></a>


| **Preferred approach to manage GuardDuty security agent** | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  | If you chose **Enable for all accounts** in the Runtime Monitoring section, then you have the following options: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) If you chose **Configure accounts manually** in the Runtime Monitoring section, then do the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) Choose **Save**.  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
|  Monitor selective EKS clusters using inclusion tags  | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters in your account: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
| Manage the GuardDuty security agent manually | Regardless of how you chose to enable Runtime Monitoring, you can manage the security agent manually for your EKS clusters. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | 

### Auto-enable Automated agent for all member accounts
<a name="eks-runtime-monitoring-agent-auto-enable-existing-member-accounts"></a>

**Note**  
It may take up to 24 hours to update the configuration for the member accounts.


| **Preferred approach to manage GuardDuty security agent** | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  This topic is to enable Runtime Monitoring for all member accounts and therefore, the following steps assume that you must have chosen **Enable for all accounts** in the Runtime Monitoring section. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
|  Monitor selective EKS clusters using inclusion tags  | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters for all member accounts in your organization: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
| Manage the GuardDuty security agent manually | Regardless of how you chose to enable Runtime Monitoring, you can manage the security agent manually for your EKS clusters. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 

### Enabling automated agent for all existing active member accounts
<a name="eks-runtime-monitoring-agent-all-active-members"></a>

**Note**  
It may take up to 24 hours to update the configuration for the member accounts.

**To manage GuardDuty security agent for existing active member accounts in your organization**
+ For GuardDuty to receive the runtime events from the EKS clusters that belong to the existing active member accounts in the organization, you must choose a preferred approach to manage the GuardDuty security agent for these EKS clusters. For more information about each of these approaches, see [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)

### Auto-enable automated agent configuration for new members
<a name="eks-runtime-monitoring-agent-auto-enable-new-members"></a>


| **Preferred approach to manage GuardDuty security agent** | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tags) | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
|  Monitor selective EKS clusters using inclusion tags  | Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters for the new member accounts in your organization. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
|  Manage the GuardDuty security agent manually  | Regardless of how you chose to enable Runtime Monitoring, you can manage the security agent manually for your EKS clusters. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 

### Configuring Automated agent for active member accounts selectively
<a name="eks-runtime-monitoring-agent-selectively-member-accounts"></a>


| **Preferred approach to manage GuardDuty security agent** | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) | 
|  Monitor all EKS clusters but exclude some of them (using exclusion tags)  | From the following procedures, choose one of the scenarios that apply to you. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
|  Monitor selective EKS clusters using inclusion tags  |  Regardless of how you chose to enable Runtime Monitoring, the following steps will help you monitor selective EKS clusters that belong to the selected accounts: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 
|  Manage the GuardDuty security agent manually  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)  | 

## Configuring Automated agent for standalone account
<a name="eks-runtime-monitoring-agent-manage-standalone-account"></a>

A standalone account owns the decision to enable or disable a protection plan in their AWS account in a specific AWS Region. 

If your account is associated with a GuardDuty administrator account through AWS Organizations, or by the method of invitation, this section doesn't apply to your account. For more information, see [Enabling Runtime Monitoring for multiple-account environments](enable-runtime-monitoring-multiple-acc-env.md).

After you enable Runtime Monitoring, ensure to install GuardDuty security agent through automated configuration or manual deployment. As a part of completing all the steps listed in the following procedure, make sure to install the security agent.

Based on your preference to monitor all or selective Amazon EKS resources, choose a preferred method and follow the steps in the following table.

1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. In the navigation pane, choose **Runtime Monitoring**.

1. Under the **Configuration** tab, choose **Enable** to enable automated agent configuration for your account.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)

# Managing security agent manually for Amazon EKS cluster
<a name="managing-gdu-agent-eks-manually"></a>

This section describes how you can manage your Amazon EKS add-on agent (GuardDuty agent) after you enable Runtime Monitoring (or EKS Runtime Monitoring). To use Runtime Monitoring, you must enable Runtime Monitoring and configure the Amazon EKS add-on, `aws-guardduty-agent`. You require to perform both the steps for GuardDuty to detect potential threats and generate [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md).

For managing the agent manually, you need to create a VPC endpoint as a prerequisite. This helps GuardDuty receive the runtime events. After this, you can install the security agent so that GuardDuty will start receiving the runtime events from the Amazon EKS resources. When GuardDuty releases a new agent version for this resource, you can update the agent version in your account.

**Topics**
+ [Prerequisite – Creating an Amazon VPC endpoint](eksrunmon-prereq-deploy-security-agent.md)
+ [Installing GuardDuty security agent manually on Amazon EKS resources](eksrunmon-deploy-security-agent.md)
+ [Updating security agent manually for Amazon EKS resources](eksrunmon-update-security-agent.md)

# Prerequisite – Creating an Amazon VPC endpoint
<a name="eksrunmon-prereq-deploy-security-agent"></a>

Before you can install the GuardDuty security agent, you must create an Amazon Virtual Private Cloud (Amazon VPC) endpoint. This will help GuardDuty receive the runtime events of your Amazon EKS resources.

**Note**  
There is no additional cost for the usage of the VPC endpoint.

Choose a preferred access method to create an Amazon VPC endpoint.

------
#### [ Console ]

**To create a VPC endpoint**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Virtual private cloud**, choose **Endpoints**.

1. Choose **Create Endpoint**.

1. On the **Create endpoint** page, for **Service category**, choose **Other endpoint services**. 

1. For **Service name**, enter **com.amazonaws.*us-east-1*.guardduty-data**.

   Make sure to replace *us-east-1* with the correct Region. This must be the same Region as the EKS cluster that belongs to your AWS account ID. 

1. Choose **Verify service**. 

1. After the service name is successfully verified, choose the **VPC** where your cluster resides. Add the following policy to restrict VPC endpoint usage to specified account only. With the organization `Condition` provided below this policy, you can update the following policy to restrict access to your endpoint. To provide VPC endpoint support to specific account IDs in your organization, see [Organization condition to restrict access to your endpoint](#gdu-shared-vpc-endpoint-org).

------
#### [ JSON ]

****  

   ```
   {
   	"Version":"2012-10-17",		 	 	 
   	"Statement": [
   		{
   			"Action": "*",
   			"Resource": "*",
   			"Effect": "Allow",
   			"Principal": "*"
   		},
   		{
   			"Condition": {
   				"StringNotEquals": {
   					"aws:PrincipalAccount": "111122223333" 
   				}
   			},
   			"Action": "*",
   			"Resource": "*",
   			"Effect": "Deny",
   			"Principal": "*"
   		}
   	]
   }
   ```

------

   The `aws:PrincipalAccount` account ID must match the account containing the VPC and VPC endpoint. The following list shows how to share the VPC endpoint with other AWS account IDs:

**Organization condition to restrict access to your endpoint**
   + To specify multiple accounts to access the VPC endpoint, replace `"aws:PrincipalAccount": "111122223333"` with the following:

     ```
     "aws:PrincipalAccount": [
               "666666666666",
               "555555555555"
         ]
     ```
   + To allow all the members from an organization to access the VPC endpoint, replace `"aws:PrincipalAccount": "111122223333"` with the following:

     ```
     "aws:PrincipalOrgID": "o-abcdef0123"
     ```
   + To restrict accessing a resource to an organization ID, add your `ResourceOrgID` to the policy.

     For more information, see [ResourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid).

     ```
     "aws:ResourceOrgID": "o-abcdef0123"
     ```

1. Under **Additional settings**, choose **Enable DNS name**.

1. Under **Subnets**, choose the subnets in which your cluster resides.

1. Under **Security groups**, choose a security group that has the in-bound port 443 enabled from your VPC (or your EKS cluster). If you don't already have a security group that has an in-bound port 443 enabled, [Create a security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group).

   If there is an issue while restricting the in-bound permissions to your VPC (or instance), you can the in-bound 443 port from any IP address `(0.0.0.0/0)`. However, GuardDuty recommends using IP addresses that matches the CIDR block for your VPC. For more information, see [VPC CIDR blocks](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*.

------
#### [ API/CLI ]

**To create a VPC endpoint**
+ Invoke [CreateVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html).
+ Use the following values for the parameters:
  + For **Service name**, enter **com.amazonaws.*us-east-1*.guardduty-data**.

    Make sure to replace *us-east-1* with the correct Region. This must be the same Region as the EKS cluster that belongs to your AWS account ID. 
  + For [DNSOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DnsOptions.html), enable private DNS option by setting it to `true`. 
+ For AWS Command Line Interface, see [create-vpc-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-vpc-endpoint.html).

------

After you have followed the steps, see [Validating VPC endpoint configuration](validate-vpc-endpoint-config-runtime-monitoring.md) to ensure that the VPC endpoint was set up correctly.

# Installing GuardDuty security agent manually on Amazon EKS resources
<a name="eksrunmon-deploy-security-agent"></a>

This section describes how you can deploy the GuardDuty security agent for the first time for specific EKS clusters. Before you proceed with this section, make sure you have already set up the prerequisites and enabled Runtime Monitoring for your accounts. The GuardDuty security agent (EKS add-on) will not work if you do not enable Runtime Monitoring. 

Choose your preferred access method to deploy the GuardDuty security agent for the first time.

------
#### [ Console ]

1. Open the Amazon EKS console at [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).

1. Choose your **Cluster name**.

1. Choose the **Add-ons** tab.

1. Choose **Get more add-ons**.

1. On the **Select add-ons** page, choose **Amazon GuardDuty EKS Runtime Monitoring**.

1. GuardDuty recommends choosing the latest and default agent **Version**.

1. On the **Configure selected add-on settings** page, use the default settings. If the **Status** of your EKS add-on is **Requires activation**, choose **Activate GuardDuty**. This action will open the GuardDuty console to configure Runtime Monitoring for your accounts.

1. After you've configured Runtime Monitoring for your accounts, switch back to the Amazon EKS console. The **Status** of your EKS add-on should have changed to **Ready to install**. 

1. 

**(Optional) Providing EKS add-on configuration schema**

   For the add-on **Version**, if you choose **v1.5.0** or above, Runtime Monitoring supports configuring specific parameters of the GuardDuty agent. For information about parameter ranges, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md).

   1. Expand **Optional configuration settings** to view the configurable parameters and their expected value and format.

   1. Set the parameters. The values must be in the range provided in [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md).

   1. Choose **Save changes** to create the add-on based on the advanced configuration.

   1. For **Conflict resolution method**, the option that you choose will be used to resolve a conflict when you update the value of a parameter to a non-default value. For more information about the listed options, see [resolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) in the *Amazon EKS API Reference*.

1. Choose **Next**.

1. On the **Review and create** page, verify all the details, and choose **Create**.

1. Navigate back to the cluster details and choose the **Resources** tab. 

1. You can view the new pods with the prefix **aws-guardduty-agent**. 

------
#### [ API/CLI ]

You can configure the Amazon EKS add-on agent (`aws-guardduty-agent`) using either of the following options:
+ Run [CreateAddon](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateAddon.html) for your account.
+ 
**Note**  
For the add-on `version`, if you choose **v1.5.0 or above**, Runtime Monitoring supports configuring specific parameters of the GuardDuty agent. For more information, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md).

  Use the following values for the request parameters:
  + For `addonName`, enter `aws-guardduty-agent`.

    You can use the following AWS CLI example when using configurable values supported for add-on versions `v1.5.0` or above. Make sure to replace the placeholder values highlighted in red and the associated `Example.json` with the configured values.

    ```
    aws eks create-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json'
    ```  
**Example.json**  

    ```
    {
    	"priorityClassName": "aws-guardduty-agent.priorityclass-high",
    	"dnsPolicy": "Default",
    	"resources": {
    		"requests": {
    			"cpu": "237m",
    			"memory": "512Mi"
    		},
    		"limits": {
    			"cpu": "2000m",
    			"memory": "2048Mi"
    		}
    	}	
    }
    ```
  + For information about supported `addonVersion`, see [Kubernetes versions supported by GuardDuty security agent](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version).
+ Alternatively, you can use AWS CLI. For more information, see [create-addon](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html).

------

**Private DNS names for VPC endpoint**  
By default, the security agent resolves and connects to the private DNS name of the VPC endpoint. For a non-FIPS endpoint, your private DNS will appear in the following format:  
Non-FIPS endpoint – `guardduty-data.us-east-1.amazonaws.com`  
The AWS Region, *us-east-1*, will change based on your Region.

# Updating security agent manually for Amazon EKS resources
<a name="eksrunmon-update-security-agent"></a>

When you manage the GuardDuty security agent manually, you are responsible to update it for your account. For notification about new agent versions, you can subscribe to an RSS feed to [GuardDuty security agent release versions](runtime-monitoring-agent-release-history.md).

You can update the security agent to the latest version to benefit from the added support and improvements. If your current agent version is reaching an end of standard support, then to continue using Runtime Monitoring (or EKS Runtime Monitoring), you must update to a next available or the latest agent version. 

**Prerequisite**  
Before you update the security agent version, make sure that the agent version that you're planning to use now, is compatible with your Kubernetes version. For more information, see [Kubernetes versions supported by GuardDuty security agent](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version).

------
#### [ Console ]

1. Open the Amazon EKS console at [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).

1. Choose your **Cluster name**.

1. Under the **Cluster info**, choose the **Add-ons** tab.

1. Under the **Add-ons** tab, select **GuardDuty EKS Runtime Monitoring**.

1. Choose **Edit** to update the agent details.

1. On the **Configure GuardDuty EKS Runtime Monitoring** page, update the details.

1. 

**(Optional) Updating Optional configuration settings**

   If your EKS add-on **Version** is *1.5.0* or above, you can also update the add-on configuration schema.

   1. Expand **Optional configuration settings** to view the configuration schema.

   1. Update the parameter values based on the range provided in [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md).

   1. Choose **Save changes** to start the update.

   1. For **Conflict resolution method**, the option that you choose will be used to resolve a conflict when you update the value of a parameter to a non-default value. For more information about the listed options, see [resolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) in the *Amazon EKS API Reference*.

------
#### [ API/CLI ]

To update the GuardDuty security agent for your Amazon EKS clusters, see [Updating an add-on](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html#updating-an-add-on). 

**Note**  
For the add-on `version`, if you choose **1.5.0 or above**, Runtime Monitoring supports configuring specific parameters of the GuardDuty agent. For information about parameter ranges, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md).

You can use the following AWS CLI example when using configurable values supported for add-on versions *1.5.0 and above*. Make sure to replace the placeholder values highlighted in red and the associated `Example.json` with the configured values.

```
aws eks update-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json'
```

**Example.json**  

```
{
	"priorityClassName": "aws-guardduty-agent.priorityclass-high",
	"dnsPolicy": "Default",
	"resources": {
		"requests": {
			"cpu": "237m",
			"memory": "512Mi"
		},
		"limits": {
			"cpu": "2000m",
			"memory": "2048Mi"
		}
	}	
}
```

------

If your Amazon EKS add-on version is 1.5.0 or above, and you have configured the add-on schema, you can verify whether or not the values appear correctly for your cluster. For more information, see [Verifying configuration schema updates](guardduty-configure-security-agent-eks-addon.md#gdu-verify-eks-add-on-configuration-param).

# Configure GuardDuty security agent (add-on) parameters for Amazon EKS
<a name="guardduty-configure-security-agent-eks-addon"></a>

You can configure specific parameters of your GuardDuty security agent for Amazon EKS. This support is available for GuardDuty security agent version 1.5.0 and above. For information about latest add-on versions, see [GuardDuty security agent versions for Amazon EKS resources](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history).

**Why should I update the security agent configuration schema**  
Configuration schema for the GuardDuty security agent is the same across all containers within your Amazon EKS clusters. When the default values do not align with the associated workloads and instance size, consider configuring the CPU settings, memory settings, `PriorityClass`, and `dnsPolicy` settings. Regardless of how you manage the GuardDuty agent for your Amazon EKS clusters, you can configure or update the existing configuration of these parameters.

## Automated agent configuration behavior with configured parameters
<a name="preserve-config-param-eks-addon-auto-managed"></a>

When GuardDuty manages the security agent (EKS add-on) on your behalf, it updates the add-on, as needed. GuardDuty will set the value of the configurable parameters to a default value. However, you can still update the parameters to a desired value. If this leads to a conflict, the default option to [resolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) is `None`.

## Configurable parameters and values
<a name="gdu-eks-addon-configure-parameters-values"></a>

For information about the steps to configure the add-on parameters, see:
+ [Installing GuardDuty security agent manually on Amazon EKS resources](eksrunmon-deploy-security-agent.md) or
+ [Updating security agent manually for Amazon EKS resources](eksrunmon-update-security-agent.md)

The following tables provide the ranges and values that you can use to deploy the Amazon EKS add-on manually or update the existing add-on settings.

**CPU settings**      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
The `disableCpuLimits` parameter is available for GuardDuty security agent version 1.12.1-eksbuild.3 and later. On earlier versions, the add-on does not support this parameter, and the Amazon EKS add-on APIs (`CreateAddon`, `UpdateAddon`) return a validation error if you specify it.  
When you set `disableCpuLimits` to `true`, the security agent pod does not enforce a CPU limit. Other resource settings are unaffected.  
To disable CPU limits, use the following configuration:  

```
{"resources":{"disableCpuLimits":true}}
```

**Memory settings**      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)

**`PriorityClass` settings**  
When GuardDuty creates an Amazon EKS add-on for you, the assigned `PriorityClass` is `aws-guardduty-agent.priorityclass`. This means that no action will be taken based on the priority of the agent pod. You can configure this add-on parameter by choosing one of the following `PriorityClass` options:      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**1** Kubernetes provides these two `PriorityClass` options – `system-cluster-critical` and `system-node-critical`. For more information, see [PriorityClass](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption) in the *Kubernetes documentation*.

**`dnsPolicy` settings**  
Choose one of the following DNS policy options that Kubernetes supports. When no configuration is specified, `ClusterFirst` is used as the default value.  
+ `ClusterFirst`
+ `ClusterFirstWithHostNet`
+ `Default`
For information about these policies, see [Pod's DNS Policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy) in the *Kubernetes documentation*.

## Verifying configuration schema updates
<a name="gdu-verify-eks-add-on-configuration-param"></a>

After you have configured the parameters, perform the following steps to verify that the configuration schema has been updated:

1. Open the Amazon EKS console at [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).

1. In the navigation pane, choose **Clusters**.

1. On the **Clusters** page, select the **Cluster name** for which you want to verify the updates.

1. Choose the **Resources** tab.

1. From the **Resource types** pane, under **Workloads**, choose **DaemonSets**.

1. Select **aws-guardduty-agent**.

1. On the **aws-guardduty-agent** page, choose **Raw view** to view the unformatted JSON response. Verify that the configurable parameters display the value that you provided.

After you verify, switch to the GuardDuty console. Select the corresponding AWS Region and view the coverage status for your Amazon EKS clusters. For more information, see [Runtime coverage and troubleshooting for Amazon EKS clusters](eks-runtime-monitoring-coverage.md).

# Validating VPC endpoint configuration
<a name="validate-vpc-endpoint-config-runtime-monitoring"></a>

After you install the security agent manually or through GuardDuty automated configuration, you can use this document to validate that the VPC endpoint configuration. You can also use these steps after troubleshooting any [runtime coverage issue](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-assessing-coverage.html) for a resource type. You can ensure that the steps worked as expected and the coverage status would potentially show up as **Healthy**.

Use the following steps to validate that VPC endpoint configuration for your resource type is set up correctly in the VPC owner account:

1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Virtual private cloud**, choose **Your VPCs**.

1. On the **Your VPCs** page, choose **IPv4 CIDR** associated with your **VPC ID**.

1. In the navigation pane, under **Virtual private cloud**, choose **Endpoints**.

1. In the **Endpoints** table, select the row that has the **Service name** similar to **com.amazonaws.*us-east-1*.guardduty-data**. The Region (`us-east-1`) might be different for your endpoint.

1. A panel for endpoint details will appear. Under the **Security Groups** tab, select the associated **Group ID** link for more details.

1. In the **Security Groups** table, select the row that with the associated **Security group ID** to view the details.

1. Under the **Inbound rules** tab, ensure that there is an ingress policy with **Port range** as **443** and **Source** as the value copied from the **IPv4 CIDR**. Inbound rules control the incoming traffic that is allowed to reach the instance. The following image shows the inbound rules for a security group that is associated with the VPC used by the GuardDuty security agent.

   If you don't already have a security group that has an in-bound port 443 enabled, [Create a security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group) in the *Amazon EC2 User Guide*.

   If there is an issue while restricting the in-bound permissions to your VPC (or cluster), provide the support to in-bound 443 port from any IP address (0.0.0.0/0).

The following list includes good to know items after you install or update the security agent.

**Assess runtime coverage**  
The next step after installing or updating your security agent is to assess runtime coverage of your resources. If the runtime coverage status is **Unhealthy**, then you must troubleshoot the issue. For more information, see [Runtime coverage issues and troubleshooting](runtime-monitoring-assessing-coverage.md).   
If the status of the runtime coverage shows as **Healthy**, it indicates that Runtime Monitoring is able to collect and receive runtime events. For a list of these events, see [Collected runtime event types](runtime-monitoring-collected-events.md).

**Private DNS name for endpoint**  
After you install the GuardDuty security agent for your resources, by default, it will resolve and connect to the private DNS name of the VPC endpoint. For a non-FIPS endpoint, the private DNS will appear in the following format:  
`guardduty-data.us-east-1.amazonaws.com`  
The AWS Region, *us-east-1*, will change based on your Region.

**A host may get installed with two security agents**  
When working with GuardDuty security agent for an Amazon EC2 instance, you might install and use the agent on the underlying host within an Amazon EKS cluster. If you had already deployed a security agent on that EKS cluster, the same host could have two security agents running on it at the same time. For information about how GuardDuty works in this scenario, see [Security agents on same host](two-security-agents-installed-on-ec2-node.md).

# Reviewing runtime coverage statistics and troubleshooting issues
<a name="runtime-monitoring-assessing-coverage"></a>

After you enable Runtime Monitoring and the GuardDuty security agent gets deployed to your resource, GuardDuty provides coverage statistics for the corresponding resource type and individual coverage status for the resources that belong to your account. Coverage status is determined by making sure that you have enabled Runtime Monitoring, your Amazon VPC endpoint has been created, and the GuardDuty security agent for the corresponding resource has been deployed. A **Healthy** coverage status indicates that when there is a runtime event related to your resource, GuardDuty is able to receive the said runtime event through the Amazon VPC endpoint, and monitor the behavior. If there was an issue at the time of configuring Runtime Monitoring, creating an Amazon VPC endpoint, or deploying the GuardDuty security agent, the coverage status appears as **Unhealthy**. When the coverage status is unhealthy, GuardDuty will not be able to receive or monitor the runtime behavior of the corresponding resource, or generate any Runtime Monitoring findings.

The following topics will help you review coverage statistics, configure EventBridge notifications, and troubleshoot the coverage issues for a specific resource type.

**Topics**
+ [Runtime coverage and troubleshooting for Amazon EC2 instance](gdu-assess-coverage-ec2.md)
+ [Runtime coverage and troubleshooting for Amazon ECS clusters](gdu-assess-coverage-ecs.md)
+ [Runtime coverage and troubleshooting for Amazon EKS clusters](eks-runtime-monitoring-coverage.md)

# Runtime coverage and troubleshooting for Amazon EC2 instance
<a name="gdu-assess-coverage-ec2"></a>

For an Amazon EC2 resource, the runtime coverage is evaluated at the instance level. Your Amazon EC2 instances can run multiple types of applications and workloads amongst others in your AWS environment. This feature also supports Amazon ECS managed Amazon EC2 instances and if you have Amazon ECS clusters running on an Amazon EC2 instance, the coverage issues at the instance level will show up under Amazon EC2 runtime coverage. 

**Topics**
+ [Reviewing coverage statistics](#review-coverage-statistics-ec2-runtime-monitoring)
+ [Coverage status change with EventBridge notifications](#ec2-runtime-monitoring-coverage-status-change)
+ [Troubleshooting Amazon EC2 runtime coverage issues](#ec2-runtime-monitoring-coverage-issues-troubleshoot)

## Reviewing coverage statistics
<a name="review-coverage-statistics-ec2-runtime-monitoring"></a>

The coverage statistics for the Amazon EC2 instances associated with your own accounts or your member accounts is the percentage of the healthy EC2 instances over all EC2 instances in the selected AWS Region. The following equation represents this as:

*(Healthy instances/All instances)\$1100*

If you have also deployed the GuardDuty security agent for your Amazon ECS clusters, then any instance level coverage issue associated with Amazon ECS clusters running on an Amazon EC2 instance will appear as an Amazon EC2 instance runtime coverage issue. 

Choose one of the access methods to review the coverage statistics for your accounts.

------
#### [ Console ]
+ Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
+ In the navigation pane, choose **Runtime Monitoring**.
+ Choose the **Runtime coverage** tab.
+ Under the **EC2 instance runtime coverage** tab, you can view the coverage statistics aggregated by the coverage status of each Amazon EC2 instance that is available in the **Instances list** table. 
  + You can filter the **Instance list** table by the following columns:
    + **Account ID**
    + **Agent management type**
    + **Agent version**
    + **Coverage status**
    + **Instance ID**
    + **Cluster ARN**
+ If any of your EC2 instances have the **Coverage status** as **Unhealthy**, the **Issue** column includes additional information about the reason for the **Unhealthy** status.

------
#### [ API/CLI ]
+ Run the [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html) API with your own valid detector ID, current Region, and service endpoint. You can filter and sort the instance list using this API.
  + You can change the example `filter-criteria` with one of the following options for `CriterionKey`:
    + `ACCOUNT_ID`
    + `RESOURCE_TYPE`
    + `COVERAGE_STATUS`
    + `AGENT_VERSION`
    + `MANAGEMENT_TYPE`
    + `INSTANCE_ID`
    + `CLUSTER_ARN`
  + When the `filter-criteria` includes `RESOURCE_TYPE` as **EC2**, Runtime Monitoring doesn't support the use of **ISSUE** as the `AttributeName`. If you use it, the API response will result in `InvalidInputException`.

    You can change the example `AttributeName` in `sort-criteria` with the following options:
    + `ACCOUNT_ID`
    + `COVERAGE_STATUS`
    + `INSTANCE_ID`
    + `UPDATED_AT`
  + You can change the *max-results* (up to 50).
  + To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

  ```
  aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "EKS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }'  --max-results 5
  ```
+ Run the [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html) API to retrieve coverage aggregated statistics based on the `statisticsType`.
  + You can change the example `statisticsType` to one of the following options:
    + `COUNT_BY_COVERAGE_STATUS` – Represents coverage statistics for EKS clusters aggregated by coverage status.
    + `COUNT_BY_RESOURCE_TYPE` – Coverage statistics aggregated based on the type of AWS resource in the list.
    + You can change the example `filter-criteria` in the command. You can use the following options for `CriterionKey`:
      + `ACCOUNT_ID`
      + `RESOURCE_TYPE`
      + `COVERAGE_STATUS`
      + `AGENT_VERSION`
      + `MANAGEMENT_TYPE`
      + `INSTANCE_ID`
      + `CLUSTER_ARN`
  + To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

  ```
  aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
  ```

------

If the coverage status of your EC2 instance is **Unhealthy**, see [Troubleshooting Amazon EC2 runtime coverage issues](#ec2-runtime-monitoring-coverage-issues-troubleshoot).

## Coverage status change with EventBridge notifications
<a name="ec2-runtime-monitoring-coverage-status-change"></a>

The coverage status of your Amazon EC2 instance might appear as **Unhealthy**. To know when the coverage status changes, we recommend you to monitor the coverage status periodically, and troubleshoot if the status becomes **Unhealthy**. Alternatively, you can create an Amazon EventBridge rule to receive a notification when the coverage status changes from either **Unhealthy** to **Healthy** or otherwise. By default, GuardDuty publishes this in the [EventBridge bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) for your account.

### Sample notification schema
<a name="ec2-gdu-coverage-status-eventbridge-schema"></a>

In an EventBridge rule, you can use the pre-defined sample events and event patterns to receive coverage status notification. For more information about creating an EventBridge rule, see [Create rule](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule) in the *Amazon EventBridge User Guide*. 

Additionally, you can create a custom event pattern by using the following example notification schema. Make sure to replace the values for your account. To get notified when the coverage status of your Amazon EC2 instance changes from `Healthy` to `Unhealthy`, the `detail-type` should be *GuardDuty Runtime Protection Unhealthy*. To get notified when the coverage status changes from `Unhealthy` to `Healthy`, replace the value of `detail-type` with *GuardDuty Runtime Protection Healthy*.

```
{
  "version": "0",
  "id": "event ID",
  "detail-type": "GuardDuty Runtime Protection Unhealthy",
  "source": "aws.guardduty",
  "account": "AWS account ID",
  "time": "event timestamp (string)",
  "region": "AWS Region",
  "resources": [
       ],
  "detail": {
    "schemaVersion": "1.0",
    "resourceAccountId": "string",
    "currentStatus": "string",
    "previousStatus": "string",
    "resourceDetails": {
        "resourceType": "EC2",
        "ec2InstanceDetails": {
          "instanceId":"",
          "instanceType":"",
          "clusterArn": "",
          "agentDetails": {
            "version":""
          },
          "managementType":""
        }
    },
    "issue": "string",
    "lastUpdatedAt": "timestamp"
  }
}
```

## Troubleshooting Amazon EC2 runtime coverage issues
<a name="ec2-runtime-monitoring-coverage-issues-troubleshoot"></a>

If the coverage status of your Amazon EC2 instance is **Unhealthy**, you can view the reason under the **Issue** column.

If your EC2 instance is associated with an EKS cluster and the security agent for EKS was installed either manually or through automated agent configuration, then to troubleshoot the coverage issue, see [Runtime coverage and troubleshooting for Amazon EKS clusters](eks-runtime-monitoring-coverage.md).

The following table lists the issue types and the corresponding troubleshooting steps.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/gdu-assess-coverage-ec2.html)

# Runtime coverage and troubleshooting for Amazon ECS clusters
<a name="gdu-assess-coverage-ecs"></a>

The runtime coverage for Amazon ECS clusters includes the tasks running on AWS Fargate and Amazon ECS container instances[1](#ecs-container-instance).

For an Amazon ECS cluster that runs on Fargate, the runtime coverage is assessed at the task level. The ECS clusters runtime coverage includes those Fargate tasks that have started running after you have enabled Runtime Monitoring and automated agent configuration for Fargate (ECS only). By default, a Fargate task is immutable. GuardDuty will not be able to install the security agent to monitor containers on already running tasks. To include such a Fargate task, you must stop and start the task again. Make sure to check if the associated service is supported.

For information about Amazon ECS container, see [Capacity creation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-capacity.html).

**Topics**
+ [Reviewing coverage statistics](#ecs-review-coverage-statistics-ecs-runtime-monitoring)
+ [Coverage status change with EventBridge notifications](#ecs-runtime-monitoring-coverage-status-change)
+ [Troubleshooting Amazon ECS-Fargate runtime coverage issues](#ecs-runtime-monitoring-coverage-issues-troubleshoot)

## Reviewing coverage statistics
<a name="ecs-review-coverage-statistics-ecs-runtime-monitoring"></a>

The coverage statistics for the Amazon ECS resources associated with your own account or your member accounts is the percentage of the healthy Amazon ECS clusters over all the Amazon ECS clusters in the selected AWS Region. This includes the coverage for Amazon ECS clusters associated with both Fargate and Amazon EC2 instances. The following equation represents this as:

*(Healthy clusters/All clusters)\$1100*

### Considerations
<a name="considerations-ecs-coverage-review-stats"></a>
+ The coverage statistics for the ECS cluster include the coverage status of the Fargate tasks or ECS container instances associated with that ECS cluster. The coverage status of the Fargate tasks include tasks that either are in running state or have recently finished running. 
+ In the **ECS clusters runtime coverage** tab, the **Container instances covered** field indicates the coverage status of the container instances associated with your Amazon ECS cluster. 

  If your Amazon ECS cluster contains only Fargate tasks, the count appears as **0/0**.
+ If your Amazon ECS cluster is associated with an Amazon EC2 instance that doesn't have a security agent, the Amazon ECS cluster will also have an **Unhealthy** coverage status.

  To identify and troubleshoot the coverage issue for the associated Amazon EC2 instance, see [Troubleshooting Amazon EC2 runtime coverage issues](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot) for Amazon EC2 instances.

Choose one of the access methods to review the coverage statistics for your accounts.

------
#### [ Console ]
+ Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
+ In the navigation pane, choose **Runtime Monitoring**.
+ Choose the **Runtime coverage** tab.
+ Under the **ECS clusters runtime coverage** tab, you can view the coverage statistics aggregated by the coverage status of each Amazon ECS cluster that is available in the **Clusters list** table. 
  + You can filter the **Cluster list** table by the following columns:
    + **Account ID**
    + **Cluster Name**
    + **Agent management type**
    + **Coverage status**
+ If any of your Amazon ECS clusters have the **Coverage status** as **Unhealthy**, the **Issue** column includes additional information about the reason for the **Unhealthy** status.

  If you Amazon ECS clusters are associated with an Amazon EC2 instance, navigate to the **EC2 instance runtime coverage** tab and filter by the **Cluster name** field to view the associated **Issue**.

------
#### [ API/CLI ]
+ Run the [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html) API with your own valid detector ID, current Region, and service endpoint. You can filter and sort the instance list using this API.
  + You can change the example `filter-criteria` with one of the following options for `CriterionKey`:
    + `ACCOUNT_ID`
    + `ECS_CLUSTER_NAME`
    + `COVERAGE_STATUS`
    + `MANAGEMENT_TYPE`
  + You can change the example `AttributeName` in `sort-criteria` with the following options:
    + `ACCOUNT_ID`
    + `COVERAGE_STATUS`
    + `ISSUE`
    + `ECS_CLUSTER_NAME`
    + `UPDATED_AT`

      The field gets updated only when either a new task gets created in the associated Amazon ECS cluster or there is change in the corresponding coverage status.
  + You can change the *max-results* (up to 50).
  + To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

  ```
  aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "ECS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }'  --max-results 5
  ```
+ Run the [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html) API to retrieve coverage aggregated statistics based on the `statisticsType`.
  + You can change the example `statisticsType` to one of the following options:
    + `COUNT_BY_COVERAGE_STATUS` – Represents coverage statistics for ECS clusters aggregated by coverage status.
    + `COUNT_BY_RESOURCE_TYPE` – Coverage statistics aggregated based on the type of AWS resource in the list.
    + You can change the example `filter-criteria` in the command. You can use the following options for `CriterionKey`:
      + `ACCOUNT_ID`
      + `ECS_CLUSTER_NAME`
      + `COVERAGE_STATUS`
      + `MANAGEMENT_TYPE`
      + `INSTANCE_ID`
  + To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

  ```
  aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
  ```

------

For more information about coverage issues, see [Troubleshooting Amazon ECS-Fargate runtime coverage issues](#ecs-runtime-monitoring-coverage-issues-troubleshoot).

## Coverage status change with EventBridge notifications
<a name="ecs-runtime-monitoring-coverage-status-change"></a>

The coverage status of your Amazon ECS cluster might appear as **Unhealthy**. To know when the coverage status changes, we recommend you to monitor the coverage status periodically, and troubleshoot if the status becomes **Unhealthy**. Alternatively, you can create an Amazon EventBridge rule to receive a notification when the coverage status changes from either **Unhealthy** to **Healthy** or otherwise. By default, GuardDuty publishes this in the [EventBridge bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) for your account.

### Sample notification schema
<a name="ecs-gdu-coverage-status-eventbridge-schema"></a>

In an EventBridge rule, you can use the pre-defined sample events and event patterns to receive coverage status notification. For more information about creating an EventBridge rule, see [Create rule](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule) in the *Amazon EventBridge User Guide*. 

Additionally, you can create a custom event pattern by using the following example notification schema. Make sure to replace the values for your account. To get notified when the coverage status of your Amazon ECS cluster changes from `Healthy` to `Unhealthy`, the `detail-type` should be *GuardDuty Runtime Protection Unhealthy*. To get notified when the coverage status changes from `Unhealthy` to `Healthy`, replace the value of `detail-type` with *GuardDuty Runtime Protection Healthy*.

```
{
  "version": "0",
  "id": "event ID",
  "detail-type": "GuardDuty Runtime Protection Unhealthy",
  "source": "aws.guardduty",
  "account": "AWS account ID",
  "time": "event timestamp (string)",
  "region": "AWS Region",
  "resources": [
       ],
  "detail": {
    "schemaVersion": "1.0",
    "resourceAccountId": "string",
    "currentStatus": "string",
    "previousStatus": "string",
    "resourceDetails": {
        "resourceType": "ECS",
        "ecsClusterDetails": {
          "clusterName":"",
          "fargateDetails":{
            "issues":[],
            "managementType":""
          },
          "containerInstanceDetails":{
            "coveredContainerInstances":int,
            "compatibleContainerInstances":int
          }
        }
    },
    "issue": "string",
    "lastUpdatedAt": "timestamp"
  }
}
```

## Troubleshooting Amazon ECS-Fargate runtime coverage issues
<a name="ecs-runtime-monitoring-coverage-issues-troubleshoot"></a>

If the coverage status of your Amazon ECS cluster is **Unhealthy**, you can view the reason under the **Issue** column. 

The following table provides the recommended troubleshooting steps for Fargate (Amazon ECS only) issues. For information about Amazon EC2 instance coverage issues, see [Troubleshooting Amazon EC2 runtime coverage issues](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot) for Amazon EC2 instances.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/gdu-assess-coverage-ecs.html)

# Runtime coverage and troubleshooting for Amazon EKS clusters
<a name="eks-runtime-monitoring-coverage"></a>

After you enable Runtime Monitoring and install the GuardDuty security agent (add-on) for EKS either manually or through automated agent configuration, you can start assessing the coverage for your EKS clusters. 

**Topics**
+ [Reviewing coverage statistics](#reviewing-coverage-statistics-eks-runtime-monitoring)
+ [Coverage status change with EventBridge notifications](#eks-runtime-monitoring-coverage-status-change)
+ [Troubleshooting Amazon EKS runtime coverage issues](#eks-runtime-monitoring-coverage-issues-troubleshoot)

## Reviewing coverage statistics
<a name="reviewing-coverage-statistics-eks-runtime-monitoring"></a>

The coverage statistics for the EKS clusters associated with your own accounts or your member accounts is the percentage of the healthy EKS clusters over all EKS clusters in the selected AWS Region. The following equation represents this as:

*(Healthy clusters/All clusters)\$1100*

Choose one of the access methods to review the coverage statistics for your accounts.

------
#### [ Console ]
+ Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
+ In the navigation pane, choose **Runtime Monitoring**.
+ Choose the **EKS clusters runtime coverage** tab.
+ Under the **EKS clusters runtime coverage** tab, you can view the coverage statistics aggregated by the coverage status that is available in the **Clusters list** table. 
  + You can filter the **Clusters list** table by the following columns:
    + **Cluster name**
    + **Account ID**
    + **Agent management type**
    + **Coverage status**
    + **Add-on version**
+ If any of your EKS clusters have the **Coverage status** as **Unhealthy**, the **Issue** column may include additional information about the reason for the **Unhealthy** status.

------
#### [ API/CLI ]
+ Run the [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html) API with your own valid detector ID, Region, and service endpoint. You can filter and sort the cluster list using this API.
  + You can change the example `filter-criteria` with one of the following options for `CriterionKey`:
    + `ACCOUNT_ID`
    + `CLUSTER_NAME`
    + `RESOURCE_TYPE`
    + `COVERAGE_STATUS`
    + `ADDON_VERSION`
    + `MANAGEMENT_TYPE`
  + You can change the example `AttributeName` in `sort-criteria` with the following options:
    + `ACCOUNT_ID`
    + `CLUSTER_NAME`
    + `COVERAGE_STATUS`
    + `ISSUE`
    + `ADDON_VERSION`
    + `UPDATED_AT`
  + You can change the *max-results* (up to 50).
  + To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

  ```
  aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "EKS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }'  --max-results 5
  ```
+ Run the [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html) API to retrieve coverage aggregated statistics based on the `statisticsType`.
  + You can change the example `statisticsType` to one of the following options:
    + `COUNT_BY_COVERAGE_STATUS` – Represents coverage statistics for EKS clusters aggregated by coverage status.
    + `COUNT_BY_RESOURCE_TYPE` – Coverage statistics aggregated based on the type of AWS resource in the list.
    + You can change the example `filter-criteria` in the command. You can use the following options for `CriterionKey`:
      + `ACCOUNT_ID`
      + `CLUSTER_NAME`
      + `RESOURCE_TYPE`
      + `COVERAGE_STATUS`
      + `ADDON_VERSION`
      + `MANAGEMENT_TYPE`
  + To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

  ```
  aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
  ```

------

If the coverage status of your EKS cluster is **Unhealthy**, see [Troubleshooting Amazon EKS runtime coverage issues](#eks-runtime-monitoring-coverage-issues-troubleshoot).

## Coverage status change with EventBridge notifications
<a name="eks-runtime-monitoring-coverage-status-change"></a>

The coverage status of an EKS cluster in your account may show up as **Unhealthy**. To detect when the coverage status becomes **Unhealthy**, we recommend you monitor the coverage status periodically and troubleshoot, if the status is **Unhealthy**. Alternatively, you can create an Amazon EventBridge rule to notify you when the coverage status changes from either `Unhealthy` to `Healthy` or otherwise. By default, GuardDuty publishes this in the [EventBridge bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) for your account.

### Sample notification schema
<a name="coverage-status-eventbridge-schema"></a>

In an EventBridge rule, you can use the pre-defined sample events and event patterns to receive coverage status notification. For more information about creating an EventBridge rule, see [Create rule](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule) in the *Amazon EventBridge User Guide*. 

Additionally, you can create a custom event pattern by using the following example notification schema. Make sure to replace the values for your account. To get notified when the coverage status of your Amazon EKS cluster changes from `Healthy` to `Unhealthy`, the `detail-type` should be *GuardDuty Runtime Protection Unhealthy*. To get notified when the coverage status changes from `Unhealthy` to `Healthy`, replace the value of `detail-type` with *GuardDuty Runtime Protection Healthy*.

```
{
  "version": "0",
  "id": "event ID",
  "detail-type": "GuardDuty Runtime Protection Unhealthy",
  "source": "aws.guardduty",
  "account": "AWS account ID",
  "time": "event timestamp (string)",
  "region": "AWS Region",
  "resources": [
       ],
  "detail": {
    "schemaVersion": "1.0",
    "resourceAccountId": "string",
    "currentStatus": "string",
    "previousStatus": "string",
    "resourceDetails": {
        "resourceType": "EKS",
        "eksClusterDetails": { 
            "clusterName": "string",
            "availableNodes": "string",
             "desiredNodes": "string",
             "addonVersion": "string"
         }
    },
    "issue": "string",
    "lastUpdatedAt": "timestamp"
  }
}
```

## Troubleshooting Amazon EKS runtime coverage issues
<a name="eks-runtime-monitoring-coverage-issues-troubleshoot"></a>

If the coverage status for your EKS cluster is `Unhealthy`, you can view the corresponding error either under the **Issue** column in the GuardDuty console, or by using the [CoverageResource](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CoverageResource.html) data type.

When working with inclusion or exclusion tags for monitoring your EKS clusters selectively, it may take some time for the tags to sync. This may impact the coverage status of the associated EKS cluster. You can try removing and adding the corresponding tag (inclusion or exclusion) again. For more information, see [Tagging your Amazon EKS resources](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) in the **Amazon EKS User Guide**.

The structure of a coverage issue is `Issue type:Extra information`. Typically, the issues will have an optional *Extra information* that may include specific client-side exception or description about the issue. Based on *Extra information*, the following tables provide the recommended steps to troubleshoot the coverage issues for your EKS clusters.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-coverage.html)


**Troubleshooting steps for Addon creation/updation error with Addon issue code**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-coverage.html)

# Setting up CPU and memory monitoring
<a name="runtime-monitoring-setting-cpu-mem-monitoring"></a>

After you enable Runtime Monitoring and assess that the coverage status of your cluster is **Healthy**, you can set up and view the insight metrics. 

The following topics can help you evaluate how the deployed agent performs against the CPU and memory limits for the GuardDuty agent.

## Setting up monitoring on Amazon ECS cluster
<a name="ecs-runtime-cpu-memory-monitoring-agent"></a>

The following steps from the *Amazon CloudWatch User Guide* can help you evaluate how the deployed agent performs against the CPU and memory limits for the GuardDuty agent:

1. [Setting up Container Insights on Amazon ECS for cluster- and service-level metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html)

1. [Amazon ECS Container Insights metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html)

## Setting up monitoring on Amazon EKS cluster
<a name="eks-runtime-cpu-memory-monitoring-agent"></a>

After the GuardDuty security agent gets deployed and you assess that the coverage status of your cluster is **Healthy**, you can set up and view the Container insight metrics.

**Evaluate performance of the security agent**  

1. [Setting up Container Insights on Amazon EKS and Kubernetes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) in the *Amazon CloudWatch User Guide*

1. [Amazon EKS and Kubernetes Container Insights metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) in the *Amazon CloudWatch User Guide*

**Manage performance with security agent v1.5.0 and above**  
With security agent [v1.5.0 and above](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-agent-release-history.html#eks-runtime-monitoring-agent-release-history), when the insights indicate that the associated GuardDuty agent is reaching the assigned limits, you can configure specific parameters. For more information, see [Configure EKS add-on parameters](guardduty-configure-security-agent-eks-addon.md).

# Using shared VPC with Runtime Monitoring
<a name="runtime-monitoring-shared-vpc"></a>

GuardDuty Runtime Monitoring supports using shared Amazon Virtual Private Cloud (Amazon VPC) for your AWS accounts that belong to the same organization in AWS Organizations. You can use shared VPC in two ways:
+ **Automated agent configuration (Recommended)** – When GuardDuty automatically manages the security agent, it will also configure the Amazon VPC endpoint policy. This policy is based on your organization's shared VPC settings.

  You must enable automated agent configuration in the shared VPC owner account and all the participating accounts who will share this VPC.
+ **Manually managed agent** – When you manually manage the security agent with shared VPC, you must update the VPC endpoint policy to allow corresponding accounts to access shared VPC. To do this, you can use the example policy shared in the following [How it works](#how-shared-vpc-works-runtime-monitoring-auto) section.

  For manual management scenarios involving participating accounts for shared VPC, the coverage status may not be accurate. To ensure up-to-date protection and coverage status of your resources, GuardDuty recommends enabling automated agent configuration for all the accounts that will use shared VPC.

**Topics**
+ [How it works](#how-shared-vpc-works-runtime-monitoring-auto)
+ [Prerequisites for using shared VPC](#shared-vpc-prerequisite-runtime-monitoring)

## How it works
<a name="how-shared-vpc-works-runtime-monitoring-auto"></a>

The AWS accounts that belong to the same organization as the shared Amazon VPC owner account can also share the same Amazon VPC endpoint. Each of the accounts using the same Amazon VPC endpoint policy is called as the **participant AWS account** of the associated shared Amazon VPC.

The following example shows the default VPC endpoint policy of the shared VPC owner account and the participant account. The `aws:PrincipalOrgID` will show the organization ID associated with the shared VPC resource. The use of this policy is limited to the participant accounts present in the organization of the owner account.

**Example shared VPC endpoint policy**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Action": "*",
            "Resource": "*",
            "Effect": "Allow",
            "Principal": "*"
        },
        {
            "Condition": {
                "StringNotEquals": {
                    "aws:PrincipalOrgID": "o-abcdef0123"
                }
            },
            "Action": "*",
            "Resource": "*",
            "Effect": "Deny",
            "Principal": "*"
        }
    ]
}
```

### With GuardDuty automatic agent configuration
<a name="guarduty-runtime-monitoring-shared-vpc-automatic-agent"></a>

When the owner account of the shared VPC enables Runtime Monitoring and automated agent configuration for any of the resources (Amazon EKS or AWS Fargate (Amazon ECS only)), all the shared VPCs become eligible for automatic installation of the shared Amazon VPC endpoint and the associated security group in the shared VPC owner account. GuardDuty retrieves the organization ID that is associated with the shared Amazon VPC. 

GuardDuty creates an Amazon VPC endpoint when either the shared VPC owner account or the participating account needs it. Examples of needing an Amazon VPC endpoint include enabling GuardDuty, Runtime Monitoring, EKS Runtime Monitoring, or launching a new Amazon ECS-Fargate task. When these accounts enable Runtime Monitoring and automated agent configuration for any resource type, GuardDuty creates an Amazon VPC endpoint and sets the endpoint policy with the same organization ID as that of the shared VPC owner account. GuardDuty adds a `GuardDutyManaged` tag and sets it to `true` for the Amazon VPC endpoint that GuardDuty creates. If the shared Amazon VPC owner account has not enabled Runtime Monitoring or automated agent configuration for any of the resources, GuardDuty will not set the Amazon VPC endpoint policy. For information about configuring Runtime Monitoring and managing the security agent automatically in the shared VPC owner account, see [Enabling GuardDuty Runtime Monitoring](runtime-monitoring-configuration.md).

### Using with manually managed agent
<a name="guardduty-runtime-monitoring-shared-vpc-manual-agent"></a>

When you use shared VPC with manually managed agent, validate that there is no explicit `Deny` endpoint policy that blocks any account that needs to use the shared VPC. This will prevent the security agent from sending telemetry to GuardDuty, resulting in an `Unhealthy` coverage status. For setting up the endpoint policy, see [Example shared VPC endpoint policy](#guardduty-runtime-monitoring-shared-vpc-endpoint-policy-example). 

Runtime coverage may not be accurate in scenarios such as missing permissions to the shared VPC. You can continuously monitor resource coverage by following the steps for your resource type in [Reviewing runtime coverage statistics and troubleshooting issues](runtime-monitoring-assessing-coverage.md). 

To ensure continuous Runtime Monitoring protection of your compute resources, GuardDuty recommends enabling automated agent configuration for the shared VPC owner account and all the participating accounts for your resources.

## Prerequisites for using shared VPC
<a name="shared-vpc-prerequisite-runtime-monitoring"></a>

As a part of an initial setup, perform the following steps in the AWS account that you want to be the owner of the shared VPC:

1. **Creating an organization** – Create an organization by following the steps in [Creating and managing an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html) in the *AWS Organizations User Guide*.

   For information about adding or removing member accounts, see [Managing AWS accounts in your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html).

1. **Creating a shared VPC resource** – You can create a shared VPC resource from the owner account. For more information, see [Share your VPC subnets with other accounts](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) in the *Amazon VPC User Guide*. 

### Prerequisites specific to GuardDuty Runtime Monitoring
<a name="shared-vpc-runtime-monitoring-prereq-gd-setup"></a>

The following list provides the prerequisites that are specific to GuardDuty:
+ The owner account of the shared VPC and the participating account can be from different organizations in GuardDuty. However, they must belong to the same organization in AWS Organizations. This is required for GuardDuty to create an Amazon VPC endpoint and a security group for the shared VPC. For information about how shared VPCs work, see [Share your VPC with other accounts](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) in *Amazon VPC User Guide*.
+ Enable Runtime Monitoring or EKS Runtime Monitoring, and GuardDuty automated agent configuration for any resource in the shared VPC owner account and the participant account. For more information, see [Enabling Runtime Monitoring](runtime-monitoring-configuration.md).

  If you have already completed these configurations, continue with the next step.
+ When working with either an Amazon EKS or an Amazon ECS (AWS Fargate only) task, make sure to choose the shared VPC resource associated with the owner account and select its subnets.

# Using Infrastructure as Code (IaC) with GuardDuty automated security agents
<a name="using-iac-with-gdu-automated-agents-runtime-monitoring"></a>

Use this section only if the following list applies to your use case:
+ You use Infrastructure as Code (IaC) tools, such as AWS Cloud Development Kit (AWS CDK) and Terraform, to manage your AWS resources, and
+ You need to enable GuardDuty automated agent configuration for one or more resource types - Amazon EKS, Amazon EC2, or Amazon ECS-Fargate.

## IaC resource dependency graph overview
<a name="runtime-monitoring-dependency-overview"></a>

When you enable GuardDuty automated agent configuration for a resource type, GuardDuty automatically creates a VPC endpoint and a security group associated with this VPC endpoint, and installs the security agent for this resource type. By default, GuardDuty will delete the VPC endpoint and the associated security group only after you disable Runtime Monitoring. For more information, see [Disabling, uninstalling, and cleaning up resources in Runtime Monitoring](runtime-monitoring-agent-resource-clean-up.md).

When you use an IaC tool, it maintains a dependency graph of resources. At the time of deletion of resources using the IaC tool, it only deletes resources that can be tracked as a part of dependency graph of resources. IaC tools may not know about the resources that are created outside of their specified configuration. For example, you create a VPC with an IaC tool and then add a security group to this VPC by using AWS console or an API operation. In the resource dependency graph, the VPC resource that you create depends on the associated security group. If you delete this VPC resource by using the IaC tool, then you will get an error. The way to get around this error is to delete the associated security group manually or to update the IaC configuration to include this added resource.

## Common issue - Deleting resources in IaC
<a name="runtime-monitoring-iac-delete-failure"></a>

When using GuardDuty automated agent configuration, you may want to delete a resource (Amazon EKS, Amazon EC2, or Amazon ECS-Fargate) that you created by using an IaC tool. However, this resource is dependent on a VPC endpoint that GuardDuty created. This prevents the IaC tool to delete the resource by itself and requires you to disable Runtime Monitoring, that further deletes the VPC endpoint automatically.

For example, when you attempt to delete the VPC endpoint that GuardDuty created on your behalf, you will get an error similar to the following examples.

**Example**  
**Error example when using CDK**  

```
The following resource(s) failed to delete: [mycdkvpcapplicationpublicsubnet1Subnet1SubnetEXAMPLE1, mycdkvpcapplicationprivatesubnet1Subnet2SubnetEXAMPLE2]. 
Resource handler returned message: "The subnet 'subnet-APKAEIVFHP46CEXAMPLE' has dependencies and cannot be deleted. (Service: Ec2, Status Code: 400, Request ID: e071c3c5-7442-4489-838c-0dfc6EXAMPLE)" (RequestToken: 4381cff8-6240-208a-8357-5557b7EXAMPLE, HandlerErrorCode: InvalidRequest)
```

**Example**  
**Error example when using Terraform**  

```
module.vpc.aws_subnet.private[1]: Still destroying... [id=subnet-APKAEIVFHP46CEXAMPLE, 19m50s elapsed]
module.vpc.aws_subnet.private[1]: Still destroying... [id=subnet-APKAEIVFHP46CEXAMPLE, 20m0s elapsed]

Error: deleting EC2 Subnet (subnet-APKAEIBAERJR2EXAMPLE): DependencyViolation: The subnet 'subnet-APKAEIBAERJR2EXAMPLE' has dependencies and cannot be deleted.
       status code: 400, request id: e071c3c5-7442-4489-838c-0dfc6EXAMPLE
```

### Solution - Prevent resource deletion issue
<a name="runtime-monitoring-iac-delete-fail-solution"></a>

This section helps you manage the VPC endpoint and security group independent of GuardDuty.

To gain complete ownership of the resources configured by using the IaC tool, perform the following steps in the listed order:

1. Create a VPC. To allow ingress permission, associate a GuardDuty VPC endpoint with the security group, to this VPC.

1. Enable GuardDuty automated agent configuration for your resource type

After you complete the preceding steps, GuardDuty will not create its own VPC endpoint and will reuse the one that you created by using the IaC tool.

For information about creating your own VPC, see [Create a VPC only](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-only) in the *Amazon VPC Transit Gateways*. For information about creating a VPC endpoint, see the following section for your resource type:
+ For Amazon EC2, see [Prerequisite – Creating Amazon VPC endpoint manually](creating-vpc-endpoint-ec2-agent-manually.md).
+ For Amazon EKS, see [Prerequisite – Creating an Amazon VPC endpoint](eksrunmon-prereq-deploy-security-agent.md).

# Collected runtime event types that GuardDuty uses
<a name="runtime-monitoring-collected-events"></a>

The GuardDuty security agent collects the following events types and sends them to the GuardDuty backend for threat detection and analysis. GuardDuty doesn't make these events accessible to you. If GuardDuty detects a potential threat and generates a [Runtime Monitoring finding types](findings-runtime-monitoring.md), you can view the corresponding finding details.

For information about how GuardDuty uses the collected event types in Runtime Monitoring, see [Opting out of using your data for service improvement](guardduty-opting-out-using-data.md).

## Process events
<a name="eks-runtime-process-events"></a>

Process events represent information associated with the processes running on Amazon EC2 instances and container workloads. The following table includes the field names and descriptions of the process events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Process name | Name of the observed process. | 
| Process Path | Absolute path of the process executable. | 
| Process ID | The ID assigned to the process by the operating system. | 
| Namespace PID | The process ID of the process in a secondary PID namespace other than the host level PID namespace. For processes inside a container, it is the process ID observed inside the container. | 
| Process User ID | The unique ID of the user that executed the process. | 
| Process UUID | The unique ID assigned to the process by GuardDuty. | 
| Process GID | Process ID of the process group. | 
| Process EGID | Effective group ID of the process group. | 
| Process EUID | Effective user ID of the process. | 
| Process User Name | The user name that executed the process. | 
| Process Start Time | The time when the process was created. This field is in the UTC date string format (`2023-03-22T19:37:20.168Z`). | 
| Process Executable SHA-256 | The `SHA256` hash of the process executable. | 
| Process Script Path | Path of the script file that was executed. | 
| Process Environment Variable | The environment variable made available to the process. Only `LD_PRELOAD` and `LD_LIBRARY_PATH` get collected.  | 
| Process Present Working Directory (PWD) | Present working directory of the process. | 
| Parent process | Process details of the parent process. A parent process is a process that created the observed process. | 
|  Command Line Arguments Presently, this field is limited to specific agent versions corresponding to the resource type: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-collected-events.html) For more information, see [GuardDuty security agent release versions](runtime-monitoring-agent-release-history.md).  | Command-line arguments provided at the time of process execution. This field might contain sensitive customer data.  | 

## Container events
<a name="eks-runtime-container-events"></a>

Container events represent information associated with activities of the container workloads. The following table includes the field names and descriptions of the container workload events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Container Name | Name of the container. When available, this field displays the value of the label `io.kubenetes.container.name`.  | 
| Container UID | The unique ID of the container assigned by the container runtime. | 
| Container Runtime | The container runtime (such as `docker` or `containerd`) used to run the container. | 
| Container Image ID | The ID of the container image. | 
| Container Image Name | Name of the container image. | 

## AWS Fargate (Amazon ECS only) task events
<a name="runtime-monitoring-ecs-fargate-events"></a>

Fargate-Amazon ECS task events represent activities associated with Amazon ECS tasks running on Fargate computes. The following table includes the field names and descriptions of the Amazon ECS-Fargate task events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Task Amazon Resource Name (ARN) | The ARN of the task. | 
| Cluster Name | The name of the Amazon ECS cluster. | 
| Family Name | The task definition's family name. The `family` is used as a name for the task definition that is used to launch the task. | 
| Service Name | The name of the Amazon ECS service, if the task was launched as part of a service. | 
| Launch Type | The infrastructure on which your task runs. For Runtime Monitoring with resource type as `ECSCluster`, the launch type could be either `EC2` or `FARGATE`. | 
| CPU | The number of CPU units used by the task as expressed in the task definition. | 

## Kubernetes pod events
<a name="eks-runtime-pod-events"></a>

The following table includes the field names and descriptions of the Kubernetes pod events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Pod ID | The ID of the Kubernetes pod. | 
| Pod name | Name of the Kubernetes pod. | 
| Pod Namespace | Name of the Kubernetes namespace to which the Kubernetes workload belongs. | 
| Kubernetes Cluster Name | Name of the Kubernetes cluster. | 

## Domain Name System (DNS) events
<a name="eks-runtime-dns-events"></a>

The Domain Name System (DNS) events includes details of the DNS queries made by your resource types and corresponding responses. The following table includes the field names and descriptions of the DNS events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Socket Type | Type of socket to indicate communication semantics. For example, `SOCK_RAW`. | 
| Address Family | Represents the communication protocol associated with the address. For example, the address family `AF_INET` is used for IP v4 protocol. | 
| Direction ID | The ID of the connection direction. | 
| Protocol Number | The layer 4 protocol number such as 17 for UDP and 6 for TCP. | 
| DNS Remote Endpoint IP | The remote IP of the connection. | 
| DNS Remote Endpoint Port | The port number of the connection. | 
| DNS Local Endpoint IP | The local IP of the connection. | 
| DNS Local Endpoint Port | The port number of the connection. | 
| DNS Payload | The payload of DNS packets that contains DNS queries and responses. | 

## Open events
<a name="eks-runtime-open-events"></a>

Open events are associated with file access and modification. The following table includes the field names and descriptions of the open events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Filepath | Path of the file that is opened in this event. | 
| Flags | Describes the file access mode, such as read-only, write-only, and read-write. | 

## Load module event
<a name="eks-runtime-load-module-events"></a>

The following table includes the field name and description of the load module event that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Module Name | Name of the module loaded into the kernel. | 

## Mprotect events
<a name="eks-runtime-mprotect-events"></a>

Mprotect events provide information about changes to the memory protection settings of the processes running on the monitored systems. The following table includes the field names and descriptions of the Mprotect events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Address Range | The address range for which the access protections were modified. | 
| Memory Regions | Specifies the Region of a process's address space such as stack and heap. | 
| Flags | Represents options that control the behavior of this event. | 

## Mount events
<a name="eks-runtime-mount-events"></a>

Mount events provide information associated with the mounting and unmounting of file systems on your monitored resource. The following table includes the field names and descriptions of the mount events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Mount Target | The path where the mount source is mounted. | 
| Mount Source | The path on the host that is mounted at the mount target. | 
| Filesystem Type | Represents the type of mounted fileSystem. | 
| Flags | Represents options that control the behavior of this event. | 

## Link events
<a name="eks-runtime-link-events"></a>

Link events provide visibility into the file system link management activities in your monitored resources. The following table includes the field names and descriptions of the link events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Link Path | Path where the hard link gets created. | 
| Target Path | Path of the file at which the hard link points. | 

## Symlink events
<a name="eks-runtime-symlink-events"></a>

Symlink events provide visibility into the file system symbolic link management activities in your monitored resources. The following table includes the field names and descriptions of the symlink events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Link Path | Path where the symbolic link is created. | 
| Target Path | Path of the file at which the symbolic link points. | 

## Dup events
<a name="eks-runtime-dup-events"></a>

Dup events provide visibility into the duplication of file descriptors by processes running on the monitored resources. The following table includes the field names and descriptions of the dup events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Old File Descriptor | A file descriptor that represents an open file object. | 
| New File Descriptor | A new file descriptor that is a duplicate of the old file descriptor. Both the old and new file descriptors represent the same open file object. | 
| Dup Remote Endpoint IP | The remote IP address of the network socket represented by the old file descriptor. Only applicable when the old file descriptor represents a network socket. | 
| Dup Remote Endpoint Port | The remote port of the network socket represented by the old file descriptor. Only applicable when the old file descriptor represents a network socket. | 
| Dup Local Endpoint IP | The local IP address of the network socket represented by the old file descriptor. Only applicable when the old file descriptor represents a network socket. | 
| Dup Local Endpoint Port | The local port of the network socket represented by the old file descriptor. Only applicable when the old file descriptor represents a network socket. | 

## Memory map event
<a name="eks-runtime-mmap-events"></a>

The following table includes the field name and description of the memory map events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Filepath | Path of the file to which the memory is mapped. | 

## Socket events
<a name="eks-runtime-socket-events"></a>

Socket events provide information about the network socket connections used in the activities of the monitored resources. The following table includes the field names and descriptions of the socket events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Address family | Represents the communication protocol associated with the address. For example, the address family `AF_INET` is used for IP version of 4 protocol. | 
| Socket Type | Type of socket to indicate communication semantics. For example, `SOCK_RAW`. | 
| Protocol number | Specifies a particular protocol within the address family. Usually there is a single protocol in address families. For example, the address family `AF_INET` only has the IP protocol. | 

## Connect events
<a name="eks-runtime-connect-events"></a>

Connect events provide visibility into the network connections established by the processes on your monitored resources. The following table includes the field names and descriptions of the connect events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Address family | Represents the communication protocol associated with the address. For example, the address family `AF_INET` is used for IP v4 protocol. | 
| Socket Type | Type of socket to indicate communication semantics. For example, `SOCK_RAW`. | 
| Protocol Number | Specifies a particular protocol within the address family. Usually there is a single protocol in address families. For example, the address family `AF_INET` only has the IP protocol. | 
| Filepath | Path of the socket file if the address family is `AF_UNIX`. | 
| Remote Endpoint IP | The remote IP of the connection. | 
| Remote Endpoint Port | The port number of the connection. | 
| Local Endpoint IP | The local IP of the connection. | 
| Local Endpoint Port | The port number of the connection. | 

## Process VM Readv events
<a name="eks-runtime-processvmreadv-events"></a>

Process VM readv events provide visibility into the read operations performed by the processes on their own virtual memory regions. The following table includes the field names and descriptions of the process VM readv events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Flags | Represents options that control the behavior of this event. | 
| Target PID | Process ID of the process from which memory is being read. | 
| Target Process UUID | The unique ID of the target process. | 
| Target Executable Path | The absolute path of the target process executable file. | 

## Process VM Writev events
<a name="eks-runtime-processvmwritev-events"></a>

Process VM writev events provide visibility into the write operations performed by the processes on their own virtual memory regions. The following table includes the field names and descriptions of the process VM writev events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Flags | Represents options that control the behavior of this event. | 
| Target PID | Process ID of the process to which memory is being written. | 
| Target Process UUID | The unique ID of the target process. | 
| Target Executable Path | The absolute path of the target process executable file. | 

## Process trace (Ptrace) events
<a name="eks-runtime-ptrace-events"></a>

Process trace (Ptrace) system call is a debugging and tracing mechanism that allows one process (tracer) to observe and control the execution of another process (tracee). This provides the tracer with the ability to inspect and modify the target process's memory, registers, and execution flow. 

Ptrace events provide visibility into the use of ptrace system call by processes running on the monitored resources. The following table includes the field names and descriptions of the ptrace events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Target PID | Process ID of the target process. | 
| Target Process UUID | The unique ID of the target process. | 
| Target Executable Path | The absolute path of the target process executable file. | 
| Flags | Represents options that control the behavior of this event. | 

## Bind events
<a name="eks-runtime-bind-events"></a>

Bind events provide visibility into binding of network sockets by processes running on the monitored resources. The following table includes the field names and descriptions of the bind events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Address Family | Represents the communication protocol associated with the address. For example, the address family `AF_INET` is used for IP v4 protocol. | 
| Socket type | Type of socket to indicate communication semantics. For example, `SOCK_RAW`. | 
| Protocol number | The layer 4 protocol number such as 17 for UDP and 6 for TCP. | 
| Local endpoint IP | The local IP of the connection. | 
| Local endpoint port | The port number of the connection. | 

## Listen events
<a name="eks-runtime-listen-events"></a>

Listen events provide visibility into the listening state of network sockets, indicating whether or not a network socket is ready to accept incoming connections. A process running on your monitored resource sets the network socket to a listening state. The following table includes the field names and descriptions of the listen events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Address Family | Represents the communication protocol associated with the address. For example, the address family `AF_INET` is used for IP v4 protocol. | 
| Socket type | Type of socket to indicate communication semantics. For example, `SOCK_RAW`. | 
| Protocol number | The layer 4 protocol number such as 17 for UDP and 6 for TCP. | 
| Local endpoint IP | The local IP of the connection. | 
| Local endpoint port | The port number of the connection. | 

## Rename events
<a name="eks-runtime-rename-events"></a>

Rename events provide information about the renaming of files and directories by processes running on the monitored resources. The following table includes the field names and descriptions of the rename events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Filepath | Path where the file that is renamed. | 
| Target | The new path of the file. | 

## Set user ID (UID) events
<a name="eks-runtime-setuid-events"></a>

Set user ID (UID) events provide visibility into the changes made to the user ID (UID) associated with the running processes on your monitored resources. The following table includes the field names and descriptions of the set UID events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| New EUID | The new effective user ID of the process. | 
| New UID | The new user ID of the process. | 

## Chmod events
<a name="eks-runtime-chmod-events"></a>

Chmod events provide visibility into the changes in the permissions (mode) of files and directories on the monitored resources. The following table includes the field names and descriptions of the chmod events that Runtime Monitoring collects to detect potential threats.


| Field name | Description | 
| --- | --- | 
| Filepath | Path of the file that invokes this event. | 
| Filemode | The updated access permissions for the associated file. | 

# Amazon ECR repository hosting GuardDuty agent
<a name="runtime-monitoring-ecr-repository-gdu-agent"></a>

The following sections list the Amazon Elastic Container Registry (Amazon ECR) repositories where GuardDuty hosts the security agent that gets deployed on your Amazon EKS and Amazon ECS clusters.

The prerequisite to [Prerequisites for container image access](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs) requires you to provide a task execution role that has certain Amazon Elastic Container Registry (Amazon ECR) permissions. To further restrict these permissions, you can add the Amazon ECR repository URI that hosts the GuardDuty agent for Fargate-Amazon ECS resources.

**Topics**
+ [ECR repository for EKS agent versions 1.12.1 - 1.8.1 (eks.build.2)](eks-runtime-agent-ecr-image-uri-v1-8-1-build-2.md)
+ [ECR repository for EKS agent version 1.8.1 (`eks.build.1`)](eks-runtime-agent-ecr-image-uri-v1-8-1-build-1.md)
+ [ECR Repository for GuardDuty agent on AWS Fargate (Amazon ECS only)](ecs-runtime-agent-ecr-image-uri.md)

# ECR repository for EKS agent versions 1.12.1 - 1.8.1 (eks.build.2)
<a name="eks-runtime-agent-ecr-image-uri-v1-8-1-build-2"></a>

When you enable GuardDuty automated configuration for Runtime Monitoring for EKS, GuardDuty will deploy this agent version to your Amazon EKS clusters. For information about enabling automated agent, see [Managing security agent automatically for Amazon EKS resources](managing-gdu-agent-eks-automatically.md).

The following table shows the Amazon ECR repository URIs where the GuardDuty security agent versions `1.12.1.eks.build.2`, `1.11.0.eks.build.2`, `1.10.0.eks.build.2`, `1.9.0.eks.build.2`, and `1.8.0.eks.build.2` for Amazon EKS are hosted.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-agent-ecr-image-uri-v1-8-1-build-2.html)

# ECR repository for EKS agent version 1.8.1 (`eks.build.1`)
<a name="eks-runtime-agent-ecr-image-uri-v1-8-1-build-1"></a>

This section provides the Amazon ECR repository for the Amazon EKS agent version **1.8.1 (v1.8.1-eks-build.1)**. If you're using v1.8.1-eks-build.1, GuardDuty recommends switching to the default agent version which is usually the latest agent version. To do so, identify the latest agent from [Released agent versions for Amazon EKS resources](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history), and then perform the steps in [Updating security agent manually for Amazon EKS resources](eksrunmon-update-security-agent.md).

The following table shows the Amazon ECR repository URIs where GuardDuty security agent version `1.8.1-eks-build.1` for Amazon EKS is hosted.


| **AWS Region** | **Amazon ECR repository URI** | 
| --- | --- | 
| US West (Oregon) | `039403964562.dkr.ecr.us-west-2.amazonaws.com` | 
| Europe (Paris) | `113643092156.dkr.ecr.eu-west-3.amazonaws.com` | 
| Asia Pacific (Mumbai) | `610108029387.dkr.ecr.ap-south-1.amazonaws.com` | 
| Asia Pacific (Hyderabad) | `618745550137.dkr.ecr.ap-south-2.amazonaws.com` | 
| Canada (Central) | `001188825231.dkr.ecr.ca-central-1.amazonaws.com` | 
| Middle East (UAE) | `601769779514.dkr.ecr.me-central-1.amazonaws.com` | 
| Europe (London) | `109118265657.dkr.ecr.eu-west-2.amazonaws.com` | 
| US West (N. California) | `373421517865.dkr.ecr.us-west-1.amazonaws.com` | 
| US East (N. Virginia) | `031903291036.dkr.ecr.us-east-1.amazonaws.com` | 
| US East (Ohio) | `591382732059.dkr.ecr.us-east-2.amazonaws.com` | 
| Europe (Ireland) | `673884943994.dkr.ecr.eu-west-1.amazonaws.com` | 
| South America (São Paulo) | `941219317354.dkr.ecr.sa-east-1.amazonaws.com` | 
| Europe (Stockholm) | `366771026645.dkr.ecr.eu-north-1.amazonaws.com` | 
| Europe (Frankfurt) | `409493279830.dkr.ecr.eu-central-1.amazonaws.com` | 
| Europe (Zurich) | `718440343717.dkr.ecr.eu-central-2.amazonaws.com` | 
| Asia Pacific (Singapore) | `584580519942.dkr.ecr.ap-southeast-1.amazonaws.com` | 
| Asia Pacific (Sydney) | `011662287384.dkr.ecr.ap-southeast-2.amazonaws.com` | 
| Asia Pacific (Jakarta) | `617474730032.dkr.ecr.ap-southeast-3.amazonaws.com` | 
| Asia Pacific (Tokyo) | `781592569369.dkr.ecr.ap-northeast-1.amazonaws.com` | 
| Asia Pacific (Seoul) | `732248494576.dkr.ecr.ap-northeast-2.amazonaws.com` | 
| Asia Pacific (Osaka) | `810724417379.dkr.ecr.ap-northeast-3.amazonaws.com` | 
| Asia Pacific (Hong Kong) | `790429075973.dkr.ecr.ap-east-1.amazonaws.com` | 
| Middle East (Bahrain) | `541829937850.dkr.ecr.me-south-1.amazonaws.com` | 
| Europe (Milan) | `528450769569.dkr.ecr.eu-south-1.amazonaws.com` | 
| Europe (Spain) | `531047660167.dkr.ecr.eu-south-2.amazonaws.com` | 
| Africa (Cape Town) | `379032919888.dkr.ecr.af-south-1.amazonaws.com` | 
| Asia Pacific (Melbourne) | `750462861327.dkr.ecr.ap-southeast-4.amazonaws.com` | 
| Israel (Tel Aviv) | `292660727137.dkr.ecr.il-central-1.amazonaws.com` | 

# ECR Repository for GuardDuty agent on AWS Fargate (Amazon ECS only)
<a name="ecs-runtime-agent-ecr-image-uri"></a>

As a prerequisite to using Runtime Monitoring for Amazon ECS-Fargate, you must [Prerequisites for container image access](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs). The GuardDuty agent sidecar container image is stored in Amazon ECR, with its image layers stored in Amazon S3. For more information, see [How Runtime Monitoring works with Fargate (Amazon ECS only)](how-runtime-monitoring-works-ecs-fargate.md).

The following table shows the Amazon ECR repositories that hosts the GuardDuty agent for AWS Fargate (Amazon ECS only) for each AWS Region.


| **AWS Region** | **Amazon ECR repository URI** | 
| --- | --- | 
| US West (Oregon) | `733349766148.dkr.ecr.us-west-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Paris) | `665651866788.dkr.ecr.eu-west-3.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Mumbai) | `251508486986.dkr.ecr.ap-south-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Hyderabad) | `950823858135.dkr.ecr.ap-south-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Canada (Central) | `354763396469.dkr.ecr.ca-central-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Middle East (UAE) | `000014521398.dkr.ecr.me-central-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (London) | `892757235363.dkr.ecr.eu-west-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| US West (N. California) | `684579721401.dkr.ecr.us-west-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| US East (N. Virginia) | `593207742271.dkr.ecr.us-east-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| US East (Ohio) | `307168627858.dkr.ecr.us-east-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Ireland) | `694911143906.dkr.ecr.eu-west-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| South America (São Paulo) | `758426053663.dkr.ecr.sa-east-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Stockholm) | `591436053604.dkr.ecr.eu-north-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Frankfurt) | `323658145986.dkr.ecr.eu-central-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Zurich) | `529164026651.dkr.ecr.eu-central-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Singapore) | `174946120834.dkr.ecr.ap-southeast-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Sydney) | `005257825471.dkr.ecr.ap-southeast-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Jakarta) | `510637619217.dkr.ecr.ap-southeast-3.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Tokyo) | `533107202818.dkr.ecr.ap-northeast-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Seoul) | `914738172881.dkr.ecr.ap-northeast-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Osaka) | `273192626886.dkr.ecr.ap-northeast-3.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Hong Kong) | `258348409381.dkr.ecr.ap-east-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Middle East (Bahrain) | `536382113932.dkr.ecr.me-south-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Milan) | `266869475730.dkr.ecr.eu-south-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Europe (Spain) | `919611009337.dkr.ecr.eu-south-2.amazonaws.com/aws-guardduty-agent-fargate` | 
| Africa (Cape Town) | `197869348890.dkr.ecr.af-south-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Melbourne) | `251357961535.dkr.ecr.ap-southeast-4.amazonaws.com/aws-guardduty-agent-fargate` | 
| Israel (Tel Aviv) | `870907303882.dkr.ecr.il-central-1.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Malaysia) | `156041399949.dkr.ecr.ap-southeast-5.amazonaws.com/aws-guardduty-agent-fargate` | 
| Asia Pacific (Thailand) | `054037130133.dkr.ecr.ap-southeast-7.amazonaws.com/aws-guardduty-agent-fargate` | 
| Canada West (Calgary) |  `339712888787.dkr.ecr.ca-west-1.amazonaws.com/aws-guardduty-agent-fargate`  | 
| Mexico (Central) | `311141559934.dkr.ecr.mx-central-1.amazonaws.com/aws-guardduty-agent-fargate`  | 
| Asia Pacific (Taipei) | `259886477082.dkr.ecr.ap-east-2.amazonaws.com/aws-guardduty-agent-fargate`  | 

# Two security agents on same underlying host
<a name="two-security-agents-installed-on-ec2-node"></a>

Amazon EC2 instances can support multiple types of workloads. When you configure automated security agent on an Amazon EC2 instance, the same EC2 instance might have another security agent through EKS.

## Overview
<a name="overview-two-security-agents-guardduty"></a>

Consider a scenario where you have enabled Runtime Monitoring. Now, you enable the automated agent for Amazon EKS through GuardDuty. You have also enabled the automated agent for Amazon EC2. It may happen that the same underlying host gets installed with two security agents - one for Amazon EKS and the other for Amazon EC2. This could result in two security agents running inside the same host, collecting runtime events and sending them to GuardDuty, and potentially generating duplicate findings.

## Impact
<a name="impact-two-security-agents-guardduty"></a>
+ When there is more than one security agent running on the same host, your account may experience double the amount of CPU and memory processing needs. For information about the CPU and memory limits for each resource type, see [Prerequisites](runtime-monitoring-prerequisites.md) for that resource.
+ GuardDuty has designed the Runtime Monitoring feature in a way that even if there is an overlap of two security agents collecting runtime events from the same underlying host, your account will only be charged for one stream of runtime events.

## How GuardDuty handles multiple agents
<a name="how-guardduty-handles-multiple-agents"></a>

GuardDuty detects when two security agents are running on the same host and designates only one of them to be the security agent that actively collects runtime events. The second agent will consume minimum system resources so as to prevent any impact to the performance of your applications.

GuardDuty considers the following scenarios:
+ When an EC2 instance falls under the scope of both Amazon EKS and Amazon EC2 security agents, the EKS security agent takes priority. This will apply only when you use the security agent v1.1.0 or above for Amazon EC2. Older agent versions will continue to run and collect runtime events because older agent versions are not affected by prioritization.
+ When both Amazon EKS and Amazon EC2 have GuardDuty managed security agents and your Amazon EC2 instance is also SSM managed, both the security agents will be installed at the host level. Once the agents are installed, GuardDuty decides which security agent will keep running. When both the security agents are running, eventually only one of them will collect runtime events.
+ When the security agents associated with both EC2 and EKS run at the same time, GuardDuty might generate duplicate findings during the overlap period only.

  This can happen when:
  + Security agents for both EC2 and EKS are configured through GuardDuty (automatically), or
  + Your Amazon EKS resource has automated security agent.
+ When the EKS security agent is already running, if you deploy the EC2 security agent manually on the same underlying host and meet all the prerequisites, GuardDuty might not install a second security agent.

# EKS Runtime Monitoring in GuardDuty
<a name="eks-runtime-monitoring-guardduty"></a>

EKS Runtime Monitoring provides runtime threat detection coverage for Amazon Elastic Kubernetes Service (Amazon EKS) nodes and containers within your AWS environment. EKS Runtime Monitoring uses a GuardDuty security agent that adds runtime visibility into individual EKS workloads, for example, file access, process execution, and network connections. The GuardDuty security agent helps GuardDuty identify specific containers within your EKS clusters that are potentially compromised. It can also detect attempts to escalate privileges from an individual container to the underlying EC2 host, and the broader AWS environment.

With the availability of Runtime Monitoring, GuardDuty has consolidated the console experience for EKS Runtime Monitoring into Runtime Monitoring. GuardDuty will not migrate your EKS Runtime Monitoring settings on your behalf automatically. This requires an action at your end. If you want to continue using only EKS Runtime Monitoring, you can use the APIs or AWS CLI to check and update the existing configuration status for EKS Runtime Monitoring. However, GuardDuty recommends [Migrating from EKS Runtime Monitoring to Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md) and using Runtime Monitoring to monitor your Amazon EKS clusters.

**Topics**
+ [Configuring EKS Runtime Monitoring for multiple-account environments (API)](eks-runtime-monitoring-configuration-multiple-accounts.md)
+ [Configuring EKS Runtime Monitoring for a standalone account (API)](eks-runtime-monitoring-configuration-standalone-acc.md)
+ [Migrating from EKS Runtime Monitoring to Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md)

# Configuring EKS Runtime Monitoring for multiple-account environments (API)
<a name="eks-runtime-monitoring-configuration-multiple-accounts"></a>

In a multiple-account environments, only the delegated GuardDuty administrator account can enable or disable EKS Runtime Monitoring for the member accounts, and manage GuardDuty agent management for the EKS clusters belonging to the member accounts in their organization. The GuardDuty member accounts can't modify this configuration from their accounts. The delegated GuardDuty administrator account account manages their member accounts using AWS Organizations. For more information about multi-account environments, see [Managing multiple accounts](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).

## Configuring EKS Runtime Monitoring for delegated GuardDuty administrator account
<a name="eks-protection-configure-delegated-admin"></a>

This section provides steps to configure EKS Runtime Monitoring and manage the GuardDuty security agent for the EKS clusters that belong to the delegated GuardDuty administrator account.

Based on the [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters), you can choose a preferred approach and follow the steps as mentioned in the following table.


|  **Preferred approach to manage GuardDuty security agent**  | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  Run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html) API by using your own regional detector ID and passing the `features` object name as `EKS_RUNTIME_MONITORING` and status as `ENABLED`.  Set the status for `EKS_ADDON_MANAGEMENT` as `ENABLED`. GuardDuty will manage the deployment of and updates to the security agent for all the Amazon EKS clusters in your account. Alternatively, you can use the AWS CLI command by using your own regional detector ID. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API. The following example enables both `EKS_RUNTIME_MONITORING` and `EKS_ADDON_MANAGEMENT`: <pre>aws guardduty update-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]'</pre>  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
| Monitor selective EKS clusters (using inclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
|  Manage the security agent manually  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 

## Auto-enable EKS Runtime Monitoring for all member accounts
<a name="auto-enable-eksrunmon-existing-memberaccounts"></a>

This section includes steps to enable EKS Runtime Monitoring and manage security agent for all member accounts. This includes the delegated GuardDuty administrator account, existing member accounts, and the new accounts that join the organization.

Based on the [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters), you can choose a preferred approach and follow the steps as mentioned in the following table.


|  **Preferred approach to manage GuardDuty security agent**  | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  To selectively enable EKS Runtime Monitoring for your member accounts, run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API operation using your own *detector ID*.  Set the status for `EKS_ADDON_MANAGEMENT` as `ENABLED`. GuardDuty will manage the deployment of and updates to the security agent for all the Amazon EKS clusters in your account. Alternatively, you can use the AWS CLI command by using your own regional detector ID. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API. The following example enables both `EKS_RUNTIME_MONITORING` and `EKS_ADDON_MANAGEMENT`: <pre>aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]'</pre>  You can also pass a list of account IDs separated by a space.  When the code has successfully executed, it returns an empty list of `UnprocessedAccounts`. If there were any problems changing the detector settings for an account, that account ID is listed along with a summary of the issue.  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
| Monitor selective EKS clusters (using inclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
|  Manage the security agent manually  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 

## Configuring EKS Runtime Monitoring for all existing active member accounts
<a name="eks-protection-configure-active-members"></a>

This section includes the steps to enable EKS Runtime Monitoring and manage GuardDuty security agent for existing active member accounts in your organization.

Based on the [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters), you can choose a preferred approach and follow the steps as mentioned in the following table.


|  **Preferred approach to manage GuardDuty security agent**  |  **Steps**  | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  To selectively enable EKS Runtime Monitoring for your member accounts, run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API operation using your own *detector ID*.  Set the status for `EKS_ADDON_MANAGEMENT` as `ENABLED`. GuardDuty will manage the deployment of and updates to the security agent for all the Amazon EKS clusters in your account. Alternatively, you can use the AWS CLI command by using your own regional detector ID. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API. The following example enables both `EKS_RUNTIME_MONITORING` and `EKS_ADDON_MANAGEMENT`: <pre>aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]'</pre>  You can also pass a list of account IDs separated by a space.  When the code has successfully executed, it returns an empty list of `UnprocessedAccounts`. If there were any problems changing the detector settings for an account, that account ID is listed along with a summary of the issue.  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
| Monitor selective EKS clusters (using inclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
|  Manage the security agent manually  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 

## Auto-enable EKS Runtime Monitoring for new members
<a name="eks-protection-configure-auto-enable-new-members"></a>

The delegated GuardDuty administrator account can auto-enable EKS Runtime Monitoring and choose an approach for how to manage the GuardDuty security agent for new accounts that join your organization.

Based on the [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters), you can choose a preferred approach and follow the steps as mentioned in the following table.


|  **Preferred approach to manage GuardDuty security agent**  |  **Steps**  | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  To selectively enable EKS Runtime Monitoring for your new accounts, invoke the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html) API operation using your own *detector ID*. Set the status for `EKS_ADDON_MANAGEMENT` as `ENABLED`. GuardDuty will manage the deployment of and updates to the security agent for all the Amazon EKS clusters in your account. Alternatively, you can use the AWS CLI command by using your own regional detector ID. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API. The following example enables both `EKS_RUNTIME_MONITORING` and `EKS_ADDON_MANAGEMENT` for a single account. You can also pass a list of account IDs separated by a space. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API. <pre>aws guardduty update-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --autoEnable  --features '[{"Name" : "EKS_RUNTIME_MONITORING", "AutoEnable": "NEW", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "AutoEnable": "NEW"}] }]'</pre> When the code has successfully executed, it returns an empty list of `UnprocessedAccounts`. If there were any problems changing the detector settings for an account, that account ID is listed along with a summary of the issue.  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
| Monitor selective EKS clusters (using inclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
|  Manage the security agent manually  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 

## Enable EKS Runtime Monitoring for individual active member accounts
<a name="eks-protection-configure-selectively-member-accounts"></a>

This section includes the steps to configure EKS Runtime Monitoring and manage security agent for individual active member accounts.

Based on the [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters), you can choose a preferred approach and follow the steps as mentioned in the following table.


|  **Preferred approach to manage GuardDuty security agent**  |  **Steps**  | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  To selectively enable EKS Runtime Monitoring for your member accounts, run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API operation using your own *detector ID*.  Set the status for `EKS_ADDON_MANAGEMENT` as `ENABLED`. GuardDuty will manage the deployment of and updates to the security agent for all the Amazon EKS clusters in your account. Alternatively, you can use the AWS CLI command by using your own regional detector ID. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API. The following example enables both `EKS_RUNTIME_MONITORING` and `EKS_ADDON_MANAGEMENT`: <pre>aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]'</pre>  You can also pass a list of account IDs separated by a space.  When the code has successfully executed, it returns an empty list of `UnprocessedAccounts`. If there were any problems changing the detector settings for an account, that account ID is listed along with a summary of the issue.  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
| Monitor selective EKS clusters (using inclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 
|  Manage the security agent manually  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html)  | 

# Configuring EKS Runtime Monitoring for a standalone account (API)
<a name="eks-runtime-monitoring-configuration-standalone-acc"></a>

A standalone account owns the decision to enable or disable a protection plan in their AWS account in a specific AWS Region. 

If your account is associated with a GuardDuty administrator account through AWS Organizations, or by the method of invitation, this section doesn't apply to your account. For more information, see [Configuring EKS Runtime Monitoring for multiple-account environments (API)](eks-runtime-monitoring-configuration-multiple-accounts.md).

After you enable Runtime Monitoring, ensure to install GuardDuty security agent through automated configuration or manual deployment. As a part of completing all the steps listed in the following procedure, make sure to install the security agent.

Based on the [Approaches to manage GuardDuty security agent in Amazon EKS clusters](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters), you can choose a preferred approach and follow the steps as mentioned in the following table.


|  **Preferred approach to manage GuardDuty security agent**  | **Steps** | 
| --- | --- | 
|  Manage security agent through GuardDuty (Monitor all EKS clusters)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html)  | 
| Monitor all EKS clusters but exclude some of them (using exclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html)  | 
| Monitor selective EKS clusters (using inclusion tag) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html)  | 
|  Manage the security agent manually  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html)  | 

# Migrating from EKS Runtime Monitoring to Runtime Monitoring
<a name="migrating-from-eksrunmon-to-runtime-monitoring"></a>

With the launch of GuardDuty Runtime Monitoring, the threat detection coverage has been expanded to Amazon ECS containers and Amazon EC2 instances. EKS Runtime Monitoring experience has now been consolidated into Runtime Monitoring. You can enable Runtime Monitoring and manage individual GuardDuty security agents for each resource type (Amazon EC2 instance, Amazon ECS cluster, and Amazon EKS cluster) for which you want to monitor the runtime behavior.

GuardDuty has consolidated the console experience for EKS Runtime Monitoring into Runtime Monitoring. GuardDuty recommends [Checking EKS Runtime Monitoring configuration status](checking-eks-runtime-monitoring-enable-status.md) and [Migrating from EKS Runtime Monitoring to Runtime Monitoring](#migrating-from-eksrunmon-to-runtime-monitoring).

As a part of migrating to Runtime Monitoring, ensure to [Disable EKS Runtime Monitoring](disabling-eks-runtime-monitoring.md). This is important because if you later choose to disable Runtime Monitoring and you do not disable EKS Runtime Monitoring, you will continue incurring usage cost for EKS Runtime Monitoring.

**To migrate from EKS Runtime Monitoring to Runtime Monitoring**

1. The GuardDuty console supports EKS Runtime Monitoring as a part of Runtime Monitoring. 

   You can start using Runtime Monitoring by [Checking EKS Runtime Monitoring configuration status](checking-eks-runtime-monitoring-enable-status.md) of your organization and accounts.

   Make sure to not disable EKS Runtime Monitoring before enabling Runtime Monitoring. If you disable EKS Runtime Monitoring, the Amazon EKS add-on management will also get disabled. Continue with the following steps in the listed order.

1. Make sure you meet all the [Prerequisites to enabling Runtime Monitoring](runtime-monitoring-prerequisites.md).

1. Enable Runtime Monitoring by replicating the same organization configuration settings for Runtime Monitoring as you have for EKS Runtime Monitoring. For more information, see [Enabling Runtime Monitoring](runtime-monitoring-configuration.md). 
   + If you have a standalone account, you need to enable Runtime Monitoring.

     If your GuardDuty security agent is deployed already, the corresponding settings are replicated automatically and you don't need to configure the settings again.
   + If you have an organization with auto-enablement settings, make sure to replicate the same auto-enablement settings for Runtime Monitoring.
   + If you have an organization with settings configured for existing active member accounts individually, make sure to enable Runtime Monitoring and configure the GuardDuty security agent for these members individually.

1. After you have ensured that the Runtime Monitoring and GuardDuty security agent settings are correct, [disable EKS Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/disabling-eks-runtime-monitoring.html) by using either the API or the AWS CLI command. 

1. (Optional) if you want to clean any resource associated with the GuardDuty security agent, see [Disabling, uninstalling, and cleaning up resources in Runtime Monitoring](runtime-monitoring-agent-resource-clean-up.md).

If you want to continue using EKS Runtime Monitoring without enabling Runtime Monitoring, see [EKS Runtime Monitoring in GuardDuty](eks-runtime-monitoring-guardduty.md). Based on your use case, choose the steps to configure EKS Runtime Monitoring for a standalone account or for multiple member accounts.

# Checking EKS Runtime Monitoring configuration status
<a name="checking-eks-runtime-monitoring-enable-status"></a>

Use the following APIs or AWS CLI commands to check the existing configuration status of EKS Runtime Monitoring. 

**To check existing EKS Runtime Monitoring configuration status in your account**
+ Run [GetDetector](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetDetector.html) to check the configuration status of your own account.
+ Alternatively, you can run the following command by using AWS CLI:

  ```
  aws guardduty get-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --region us-east-1
  ```

  Make sure to replace the detector ID of your AWS account and the current Region. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

**To check existing EKS Runtime Monitoring configuration status for your organization (as a delegated GuardDuty administrator account only)**
+ Run [DescribeOrganizationConfiguration](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DescribeOrganizationConfiguration.html) to check the configuration status of your organization.

  Alternatively, you can run the following command using AWS CLI:

  ```
  aws guardduty describe-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --region us-east-1
  ```

  Make sure to replace the detector ID with the detector ID of your delegated GuardDuty administrator account and the Region with your current Region. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

# Disabling EKS Runtime Monitoring after migrating to Runtime Monitoring
<a name="disabling-eks-runtime-monitoring"></a>

After you have ensured that the existing settings for your account or organization have been replicated to Runtime Monitoring, you can disable EKS Runtime Monitoring.

**To disable EKS Runtime Monitoring**
+ **To disable EKS Runtime Monitoring in your own account**

  Run the [UpdateDetector](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html) API with your own regional *detector-id*.

  Alternatively, you can use the following AWS CLI command. Replace *12abc34d567e8fa901bc2d34e56789f0* with your own regional *detector-id*.

  ```
  aws guardduty update-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "DISABLED"}]'
  ```
+ **To disable EKS Runtime Monitoring for member accounts in your organization**

  Run the [UpdateMemberDetectors](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html) API with the regional *detector-id* of the delegated GuardDuty administrator account of the organization. 

  Alternatively, you can use the following AWS CLI command. Replace *12abc34d567e8fa901bc2d34e56789f0* with the regional *detector-id* of the delegated GuardDuty administrator account of the organization and *111122223333* with the AWS account ID of the member account for which you want to disable this feature.

  ```
  aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "DISABLED"}]'
  ```
+ **To update EKS Runtime Monitoring auto-enable settings for your organization**

  Perform the following step only if you have configured the EKS Runtime Monitoring auto-enablement settings to either new (`NEW`) or all (`ALL`) member accounts in the organization. If you had already configured it as `NONE`, then you can skip this step.
**Note**  
Setting the EKS Runtime Monitoring auto-enable configuration to `NONE` means that EKS Runtime Monitoring will not be enabled automatically for any existing member account or when a new member account joins your organization.

  Run the [UpdateOrganizationConfiguration](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html) API with the regional *detector-id* of the delegated GuardDuty administrator account of the organization. 

  Alternatively, you can use the following AWS CLI command. Replace *12abc34d567e8fa901bc2d34e56789f0* with the regional *detector-id* of the delegated GuardDuty administrator account of the organization. Replace the *EXISTING\$1VALUE* with your current configuration for auto-enabling GuardDuty.

  ```
  aws guardduty update-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --auto-enable-organization-members EXISTING_VALUE --features '[{"Name" : "EKS_RUNTIME_MONITORING", "AutoEnable": "NONE"}]'
  ```

# GuardDuty security agent release versions
<a name="runtime-monitoring-agent-release-history"></a>

GuardDuty releases an updated agent version from time to time. When GuardDuty manages the agent automatically, GuardDuty is designed to update the agent on your behalf. When you manage the agent manually, you are responsible to update the agent version for your resource types – Amazon EC2 instances, Amazon ECS clusters, and Amazon EKS clusters. 

The following sections provide GuardDuty security agent release versions and associated release notes for all the supported resource types.

**Topics**
+ [GuardDuty security agent versions for Amazon EC2 instances](#ec2-gdu-agent-release-history)
+ [GuardDuty security agent versions for AWS Fargate (Amazon ECS only)](#ecs-gdu-agent-release-history)
+ [GuardDuty security agent versions for Amazon EKS resources](#eks-runtime-monitoring-agent-release-history)
+ [Additional resources - next steps](#runtime-monitoring-related-agent-versions-next-steps)

## GuardDuty security agent versions for Amazon EC2 instances
<a name="ec2-gdu-agent-release-history"></a>

The following table shows the release version history for the GuardDuty security agent for Amazon EC2.


| SSM distributor version | Agent version | Release notes | Availability date | 
| --- | --- | --- | --- | 
| v1.9.2 | v1.9.2 |  Added support for Kernel 6.15, 6.16, 6.17, 6.18. Added support for Alma Linux 9, Alma Linux 10 and SUSE Linux Enterprise Server 16. For a list of all verified OS distributions for Amazon EC2 resources, see [Validate architectural requirements](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2).  | Feb 24, 2026 | 
| v1.9.1 | v1.9.1 |  General performance tuning and security feature updates.  | Nov 10, 2025 | 
| v1.9.0 | v1.9.0 |  General performance tuning and enhancements.  | October 23, 2025 | 
| v1.8.0 | v1.8.0 |  General performance tuning and enhancements.  | August 12, 2025 | 
| v1.7.2 | v1.7.1 |  Improved support for local agent install for RPM based Linux distributions.  | July 23, 2025 | 
| v1.7.1 | 1.7.1 |  Added support for Fedora 40 and Fedora 41. For a list of all verified OS distributions for Amazon EC2 resources, see [Validate architectural requirements](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2). General performance tuning and enhancements.  | June 03, 2025 | 
| v1.7.0 | v1.7.0 |  Added support for Oracle Linux versions 8.9 and 9.3, and Rocky Linux version 9.5. For a list of all verified OS distributions for Amazon EC2 resources, see [Validate architectural requirements](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2). Improved container ID resolution. General performance tuning and enhancements.  | April 03, 2025 | 
| v1.6.0 | v1.6.0 |  General performance tuning and enhancements.  | February 6, 2025 | 
| v1.5.0 | v1.5.0 |  Added support for CentOS Stream 9.0, RedHat 9.4, Fedora 34.0, and Ubuntu 24.04. Support for ARM instances for `.../MetadataDNSRebind` findings. General performance tuning and enhancements.  | November 20, 2024 | 
| v1.3.1 | v1.3.1 |  Support for custom DNS resolvers.  | September 12, 2024 | 
| v1.3.0 | v1.3.0 |  General performance tuning and enhancements. Includes support to capture additional security signals for future [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md).  | August 19, 2024 | 
| v1.2.0 | v1.2.0 |  Supports OS distributions Ubuntu 20.04, Ubuntu 22.04, Debian 11, and Debian 12. Supports kernel 6.5 and 6.8. General performance tuning and enhancements.  | June 13, 2024 | 
| v1.1.0 | v1.1.0 |  Supports GuardDuty automated agent configuration in Runtime Monitoring for Amazon EC2 instances. Supports new security signals and findings released with the announcement of general availability of Runtime Monitoring for EC2 instances. General performance tuning and enhancements.  | March 26, 2024 | 
| v1.0.2 | v1.0.2 | Supports the latest Amazon ECS AMIs. | February 2, 2024 | 
| v1.0.1 | v1.0.1 |  Agent versions released prior to v1.0.2 are incompatible with Amazon ECS AMIs launched after January 31, 2024. General performance tuning and enhancements.  | January 23, 2024 | 
| v1.0.0 | v1.0.0 | Initial release of the RPM installation. Agent versions released prior to v1.0.2 are incompatible with Amazon ECS AMIs launched after January 31, 2024. | November 26, 2023 | 

## GuardDuty security agent versions for AWS Fargate (Amazon ECS only)
<a name="ecs-gdu-agent-release-history"></a>

The following table shows the release version history for the GuardDuty security agent for Fargate (Amazon ECS only).


| Agent version | Container image | Release notes | Availability date | 
| --- | --- | --- | --- | 
| v1.9.0 |  **x86\$164 (AMD64)**: `sha256:fd9acaa2326f180f0ed0c5a25d8ff0a2d0498a6e900c34c68d4e973ea7fb26a8` **Graviton (ARM64)**: `sha256:0b04f8c28956684e752677bfd83dbc45afc8a43f7791fa44667b8078ba48a295`  |  General performance tuning and security enhancements.  | October 28, 2025 | 
| v1.8.0 |  **x86\$164 (AMD64)**: `sha256:4425417f39e38b24c1be428bacad1dad53e0645530dcf4422436353bfe358e3a` **Graviton (ARM64)**: `sha256:aff069418fd6825846f8f575c49906a67c8a446d12d9ed0d21ab95bd0d05497b`  |  General performance tuning and enhancements.  | August 12, 2025 | 
| v1.7.0 |  **x86\$164 (AMD64)**: `sha256:bf9197abdf853607e5fa392b4f97ccdd6ca56dd179be3ce8849e552d96582ac8` **Graviton (ARM64)**: `sha256:56c8683c948bcd82c0dbcebf755204365ac7285994693c11717bd45f86e279c2`  |  Improved container ID resolution. General performance tuning and enhancements.  | April 04, 2025 | 
| v1.6.0 |  **x86\$164 (AMD64)**: `sha256:c8dea71d372bc47b2f236f7a091b9a9b06bc8193c1cfe4c9346eb50f89258897` **Graviton (ARM64)**: `sha256:f4032a566b90537646c2a987bef42eca1b498078ccc58a848603f877971a8dbe`  |  General performance tuning and enhancements.  | February 6, 2025 | 
| v1.5.0 |  **x86\$164 (AMD64)**: `sha256:5e6fdc41f9eb748219d0498cd6c1dba6a19d875daec50167a0ac80e5028eac54` **Graviton (ARM64)**: `sha256:d56801ff6864d6014740103b70b1c38431851358d182613bede20fe21090e734`  |  Support for ARM tasks for `.../MetadataDNSRebind` findings. General performance tuning and enhancements.  | November 14, 2024 | 
| v1.4.1 |  **x86\$164 (AMD64)**: `sha256:ef36a11151ec2d3d7db22273bfb954750dee76f0ac7bec37a7ba7e74c3de1c78` **Graviton (ARM64)**: `sha256:a8844544a59d6b4cba98f8e528b513ac2d97432f208e3ad497cc16b331aa9faa`  |  Container image hardening. General performance tuning and enhancements.  | October 24, 2024 | 
| v1.3.1 |  **x86\$164 (AMD64)**: `sha256:a6e2307d796e2875907bc4c1c69622c906f3192ddc42ef27b99e0a8f0979f3e0` **Graviton (ARM64)**: `sha256:ad1b6539d806edb504f17e6bcfb8b4026c5e822300afc31c0d23c6a08f9b99e9`  |  Support for custom DNS resolvers.  | September 11, 2024 | 
| v1.3.0 |  **x86\$164 (AMD64)**: `sha256:f1ad3fb2dc55a1110c60eecf4453b9f9c02f29acb261df39814e7d29296bf831` **Graviton (ARM64)**: `sha256:ff81a755d46681e409f55a95beedae9ebbcf5336e1c0b1e6348af7c6518bdbb1`  |  General performance tuning and enhancements. Includes support to capture additional security signals for future GuardDuty [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md).  | August 9, 2024 | 
| v1.2.0 |  **x86\$164 (AMD64)**: `sha256:1dbad20ac2dc66d52d00bb28dde4281fe0d3c5f261b1649b247c2369d9e26b93` **Graviton (ARM64)**: `sha256:91930f8446f5f95b93b8ccb18773992affa401eb3f42da89d68077a56bafa6cd`  |  General performance tuning and enhancements.  | May 31, 2024 | 
| v1.1.0 |  **x86\$164 (AMD64)**: `sha256:83ce3cf2ef85a349ed1797a8cf30a008ac5d8c9f673f2835823957e9dcf71657` **Graviton (ARM64)**: `sha256:0d4b61648d7bdeab8ab8d94684f805498927c7d437d318204dcccfe8c9383dc7`  |  Supports new security signals and findings. General performance tuning and enhancements.  | May 01, 2024 | 
| v1.0.1 |  **x86\$164 (AMD64)**: `sha256:9f8cd438fb66f62d09bfc641286439f7ed5177988a314a6021ef4ff880642e68` **Graviton (ARM64)**: `sha256:82c66bb615bd0d1e96db77b1f1fb51dc03220caa593b1962249571bf7147d1b7`  |  General performance tuning and enhancements.  | January 26, 2024 | 
| v1.0.0 |  **x86\$164 (AMD64)**: `sha256:359b8b014e5076c625daa1056090e522631587a7afa3b2e055edda6bd1141017` **Graviton (ARM64)**: `sha256:b9438690fa8a86067180a11658bec0f4f838ae3fbd225d04b9306250648b3984`  | Initial release of GuardDuty security agent for AWS Fargate (Amazon ECS only). | November 26, 2023 | 

## GuardDuty security agent versions for Amazon EKS resources
<a name="eks-runtime-monitoring-agent-release-history"></a>

GuardDuty releases an updated agent version from time to time. When GuardDuty manages the agent automatically, it is designed to manage the agent updates on your behalf. When you manage the agent manually, you are responsible to update the agent version for your Amazon EKS clusters. 

Before updating the agent to a specific version, add the image registry for GuardDuty to the `allowed-container-registries` in your admission controller. For more information, see [Amazon ECR repository hosting GuardDuty agent](runtime-monitoring-ecr-repository-gdu-agent.md).

The following table shows the release version history of [Amazon EKS add-on GuardDuty agent](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#add-ons-guard-duty).


| Agent version | Container image | Release notes | Availability date | End of standard support[1](#eks-security-agent-life-support-end) | 
| --- | --- | --- | --- | --- | 
| v1.12.1 |  **x86\$164 (AMD64)**: `sha256:f29a597745e5acff48809bebac7d8091bbc38229453dd26710c549b817362491` **Graviton (ARM64)**: `sha256:089cebdc7e891177e107a099c9a4e362d9d74b5362cd374b448a16078040f6c6`  |  General performance tuning and security feature updates.  | Nov 17, 2025 | – | 
| v1.11.0 |  **x86\$164 (AMD64)**: `sha256:7c398fd50dee5fe493c361aa7fe191e094ddfa000c65b449a9ed6a5cd53610e7` **Graviton (ARM64)**: `sha256:98a547b47d4770f45e75eb9730c807d9265722ca2f391e0aa5cb19e487ab455f`  |  Added support for Fedora 40 and Fedora 41 OS distributions. For more information, see [Validating architectural requirements](prereq-runtime-monitoring-eks-support.md#eksrunmon-supported-platform-concepts) (for EKS). General performance tuning and security enhancements.  | August 29, 2025 | – | 
| v1.10.0 |  **x86\$164 (AMD64)**: `sha256:6dcbe5b055e1ef0af903071ede0b08f755ad5b7e9774a67df5399efdaa1f3d7d` **Graviton (ARM64)**: `sha256:f05368822689610a4bab543abf93d3e070b1b559e62a2e67d82dfa9837600f72`  |  Improved container ID resolution. General performance tuning and enhancements.  | April 04, 2025 | – | 
| v1.9.0 |  **x86\$164 (AMD64)**: `sha256:51c5789ef6570f9bec879ac48a8f4769718cbc31e45430032569917e219af63f` **Graviton (ARM64)**: `sha256:9c2f74e7ea0827b7e422ae4c91fffc6c2bc41a1cdb96c7191d05259d337154e1`  |  General performance tuning and enhancements.  | March 02, 2025 | – | 
| v1.8.1 |  **x86\$164 (AMD64)**: `sha256:f2ce8cf89dbe17e3388cecb35053544dadf21af7770545f8d4b50384076aff47` **Graviton (ARM64)**: `sha256:30f586e4b694e704bcafadfa9081ab0aeff3cfbcde39743a0f1e24f77d79627f`  |  Added support for CentOS Stream 9.0, RedHat 9.4, Fedora 34.0, and Ubuntu 24.04. Support for ARM instances for `.../MetadataDNSRebind` finding. General performance tuning and enhancements.  | November 23, 2024 | – | 
| v1.7.1 |  **x86\$164 (AMD64)**: `sha256:b8b86b5d0872c8b67fecf64ec3d172666360545435a1752447d510951a7fd749` **Graviton (ARM64)**: `sha256:40ac4cfc354fd430ba7897ca1632e9a500ed13eeb0c315c5bcad38680e76b6e9`  |  General performance tuning and enhancements. Includes support to capture additional security signals for future [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md). Support for custom DNS resolvers.  | September 13, 2024 | – | 
| v1.7.0 |  **x86\$164 (AMD64)**: `sha256:f3a2a8806e6c2a7fd63a91cccf6f7dffcd7e68554a423d610cea8c7e8f2185ec` **Graviton (ARM64)**: `sha256:b1a6db35a072c0de3c695e5e909a03e6c4e1fdbe47ecfaeb2784435cf67ebe0a`  |  General performance tuning and enhancements. Includes support to capture additional security signals for future [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md).  | August 17, 2024 | – | 
| v1.6.1 |  **x86\$164 (AMD64)**: `sha256:30650708a6601f6d6b9046f54b30f5fd65af296b1e40b8c24426b9bdb07c3ab1` **Graviton (ARM64)**: `sha256:5f637c42ffb306b20f776d9d83e1e0b4be40ce245be44afcf43a8902b4d71019`  |  General performance tuning and enhancements.  | May 14, 2024 | – | 
| v1.6.0 |  **x86\$164 (AMD64)**: `sha256:7dabcbee30d8b053676752fbc19e89f77272d9a6a53cc93731f5872180ef9010` **Graviton (ARM64)**: `sha256:9710f53afccdf4f22b265a1a6fc27f1469403af1f7d5d08c4869a7269cdd2650`  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-agent-release-history.html)  | April 29, 2024 | – | 
| v1.5.0 |  **x86\$164 (AMD64)**: `sha256:e09a4e70af4058a212f172cc8eb3fc23ad9bed547ed609faa2bb82cf7cc5532d` **Graviton (ARM64)**: `sha256:afc9a3f8f17ae12499d76069efcf1b46271a5a4b2b3f6ba5de54637b8f55d5c6`  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-agent-release-history.html)  | March 07, 2024 | – | 
| v1.4.1 |  **x86\$164 (AMD64)**: `sha256:66d491927763742660faa87cc2c39bb97b7873039157ae8b90bc999cb73d0b9c` **Graviton (ARM64)**: `sha256:537a330b2dd82357024fb6daeb8761034b7defd43b10dffe0792c9e6d0778b40`  | General performance tuning and enhancements.  | January 16, 2024 | – | 
| v1.4.0 |  **x86\$164 (AMD64)**: `sha256:848ce13d9430bad554ac23d4699551505326ada2a88e1a721fe9f86b56b52c0f` **Graviton (ARM64)**: `sha256:0c650aeafeeb5f2bcb8b989ac849bedc1fae1a4de1cf6306ffdd9c6aebe67f8e`  |  Manifest mount point support better data collection AppArmor configuration in manifest Collect command line argument General performance tuning and enhancements  | December 21, 2023 | – | 
| v1.3.1 |  **x86\$164 (AMD64)**: `sha256:55578fcb7b73097ade5c8404390ef16cf76a7b568490abaae01ac75992b3ea29` **Graviton (ARM64)**: `sha256:e3ce8d66ac2121f8d476eb58f8bc50ab51336647615eb7cf514c21421cb818fd`  | Important security patches and updates.  | October 23, 2023 | – | 
|  v1.3.0  | **x86\$164 (AMD64)**: `sha256:6dace2337dfbb7609811be89fb4b23ae0b865f1027ad78fbe69530bfbd46c694` **Graviton (ARM64)**: `sha256:4928a7c6ef40e77c8ec95841323bb9a110db31f12c0ee7ab965e08b43efd01bb` | Supports Ubuntu platform Supports Kubernetes version 1.28 General performance enhancements and stability improvement.  | October 05, 2023 | – | 
| v1.2.0 | **x86\$164 (AMD64)**: `sha256:d610413d662ec042057f05d6942496d7f2c08e9f5a077ea307ffdb5d3f11bcc3` **Graviton (ARM64)**: `sha256:174d7ab28b2f95e5309da80d95b88ad26f602dfe72c2b351a0ef9297a1412bfa` | In addition to AMD64-based instances, v1.2.0 now also supports ARM64-based instances. Added and verified support for Bottlerocket Supports Kubernetes version 1.27 General performance enhancements and stability improvements. | June 16, 2023 | – | 
| v1.1.0 | `sha256:b19ba3a3c1a508d153263ae2fda891a7928b5ca9b3a5692db6c101829303281c` | In addition to [Kubernetes versions supported by GuardDuty security agent](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version), this agent release also supports Kubernetes version 1.26. General performance enhancements and stability improvements. | May 2, 2023 | May 14, 2024 | 
| v1.0.0 | `sha256:e38bdd2b1323e89113f1a31bd4bc8e5a8098525dd98e6981a28b9906b1e4411e` | Initial release of Amazon EKS add-on agent. | March 30, 2023 | May 14, 2024 | 

**1** For information about updating your current agent version that is approaching to an end of standard support, see [Updating security agent manually for Amazon EKS resources](eksrunmon-update-security-agent.md).

## Additional resources - next steps
<a name="runtime-monitoring-related-agent-versions-next-steps"></a>

For more information on the next steps, see the following topics:
+ [Prerequisites to enabling Runtime Monitoring](runtime-monitoring-prerequisites.md) - With new agent versions, there might be an update to the prerequisites section. Verify and validate that your resources meet the latest prerequisites.
+ [Managing GuardDuty security agents](runtime-monitoring-managing-agents.md) - When you manage the agent manually, then you're responsible for managing the updates to the agent version running on your resources. Based on your resource type (Amazon EKS or Amazon EC2-Amazon ECS), perform the steps to update the security agent. Also make sure to validate your [VPC endpoint configuration](https://docs.aws.amazon.com/guardduty/latest/ug/validate-vpc-endpoint-config-runtime-monitoring.html). 
+ [Reviewing runtime coverage statistics and troubleshooting issues](runtime-monitoring-assessing-coverage.md) - After you have updated the security agent, you can assess the runtime coverage your resource. If there is any coverage issue, then use the associated troubleshooting steps.

# Disabling, uninstalling, and cleaning up resources in Runtime Monitoring
<a name="runtime-monitoring-agent-resource-clean-up"></a>

This section applies to your AWS account if you choose to disable Runtime Monitoring, or only GuardDuty automated agent configuration for a resource type.

**Disabling GuardDuty automated agent configuration**  
GuardDuty doesn't remove the security agent that is deployed on your resource. However, GuardDuty will stop managing the updates to the security agent.  
GuardDuty continues to receive the runtime events from your resource type. To prevent an impact on your usage statistics, make sure to remove the GuardDuty security agent from your resource.   
Whether or not an AWS account uses a shared VPC endpoint, GuardDuty doesn't delete the VPC endpoint. If required, you will need to delete the VPC endpoint manually.

**Disabling Runtime Monitoring **and** EKS Runtime Monitoring**  
This section applies to you in the following scenarios:  
+ You never enabled EKS Runtime Monitoring separately and now you disabled Runtime Monitoring.
+ You are disabling both Runtime Monitoring and EKS Runtime Monitoring. If you're unsure about the configuration status of EKS Runtime Monitoring, see [Checking EKS Runtime Monitoring configuration status](checking-eks-runtime-monitoring-enable-status.md).
**Disabling Runtime Monitoring without disabling EKS Runtime Monitoring**  
In this scenario, at some point in time, you enabled EKS Runtime Monitoring, and later, also enabled Runtime Monitoring without disabling EKS Runtime Monitoring.  
Now, when you disable Runtime Monitoring, you will also need to disable EKS Runtime Monitoring; otherwise, you will continue incurring usage cost for EKS Runtime Monitoring.
If the previously listed scenarios apply to you, then GuardDuty will take the following actions in your account:  
+ GuardDuty deletes the VPC endpoint that has the `GuardDutyManaged`:`true` tag. This is the VPC that GuardDuty had created to manage the automated security agent.
+ GuardDuty deletes the security group that was tagged as `GuardDutyManaged`:`true`.
+ For a shared VPC that has been used by at least one participant account, GuardDuty neither deletes the VPC endpoint nor the security group associated with the shared VPC resource.
+ For an Amazon EKS resource, GuardDuty deletes the security agent. This is independent of whether it managed manually or through GuardDuty.

  For an Amazon ECS resource, because an ECS task is immutable, GuardDuty can't uninstall the security agent from that resource. This is independent of how you manage the security agent – manually or automatically through GuardDuty. After you disable Runtime Monitoring, GuardDuty will not attach a sidecar container when a new ECS task starts running. For information about working with Fargate-ECS tasks, see [How Runtime Monitoring works with Fargate (Amazon ECS only)](how-runtime-monitoring-works-ecs-fargate.md).

  For an Amazon EC2 resource, GuardDuty uninstalls the security agent from all the Systems Manager (SSM) managed Amazon EC2 instances only when it meets the following conditions:
  + Your resource is **not** tagged with `GuardDutyManaged`:`false` exclusion tag.
  + GuardDuty must have permissions to access the tags in instance metadata. For this EC2 resource, the **Access to tags in instance metadata** is set to **Allow**.

**When you stop managing the security agent manually**  
Regardless of which approach you use to deploy and manage the GuardDuty security agent, to stop monitoring the runtime events in your resource, you must remove the GuardDuty security agent. When you want to stop monitoring the runtime events from a resource type in an account, you may also delete the Amazon VPC endpoint.

# Uninstalling security agent manually for Amazon EC2 resources
<a name="uninstalling-gdu-ec2-agent-runtime-monitoring"></a>

This section provides methods to uninstall the GuardDuty security agent from your Amazon EC2 resources. When you manage the security agent manually, you're responsible to remove the agent from the resources. GuardDuty will not take any action on the resources that you manage.

If you created an Amazon VPC endpoint manually, then after you uninstall the security agent on all the monitored resource types in your account, you can choose to delete the VPC endpoint. This is a separate step. For more information, see [To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint).

Based on how you installed the security agent in your resource, choose one of the following methods to uninstall it.

**Topics**
+ [Method 1 - By using the Run command](#remove-gdu-ec2-agent-run-command)
+ [Method 2 - By using Linux Package Managers](#remove-gdu-ec2-agent-rpm-script)

## Method 1 - By using the Run command
<a name="remove-gdu-ec2-agent-run-command"></a>

When you installed the security agent with [Method 1 - Using AWS Systems Manager](installing-gdu-security-agent-ec2-manually.md#install-gdu-by-using-sys-runtime-monitoring), perform the following steps to uninstall the agent: 

**To uninstall the GuardDuty security agent**

1. You can uninstall the GuardDuty security agent by following the steps as specified in [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) in the *AWS Systems Manager User Guide*. Use the Uninstall action in the parameters to uninstall the GuardDuty security agent.

   In the **Targets** section, make sure that the impact is only on those Amazon EC2 instances from which you want to uninstall the security agent. 

   Use the following GuardDuty document and distributor:
   + Document name: `AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin`
   + Distributor: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin`

1. After providing all the details, when you choose **Run**, the security agent that it deployed on the targeted Amazon EC2 instances is removed.

   To remove the Amazon VPC endpoint configuration, you must disable both Runtime Monitoring and Amazon EKS Runtime Monitoring.

1. If you also want to delete the VPC endpoint that is associated with this security agent, then see [To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint).

## Method 2 - By using Linux Package Managers
<a name="remove-gdu-ec2-agent-rpm-script"></a>

When you installed the security agent with [Method 2 - Using Linux Package Managers](installing-gdu-security-agent-ec2-manually.md#install-gdu-by-rpm-scripts-runtime-monitoring), perform the following steps to uninstall the agent:

**To uninstall the GuardDuty security agent**

1. Connect to the your instance. For steps on how to do this, see [Connect to your Linux instance using an SSH client](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html) in the *Amazon EC2 User Guide*.

1. 

**Command to uninstall**

   The following command will uninstall the GuardDuty security agent from the Amazon EC2 instance to which you connect:
   + For RPM:

     ```
     sudo rpm -e amazon-guardduty-agent
     ```
   + For Debian:

     ```
     sudo dpkg --purge amazon-guardduty-agent
     ```

   After you run the command, you can also check the logs associated with the command.

1. If you also want to delete the VPC endpoint that is associated with this security agent, then see [To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint).

# Cleaning up security agent resources
<a name="clean-up-guardduty-agent-resources-process"></a>

This section explains how you can clean up the AWS resources associated with the security agent. As listed in [Disabling, uninstalling, and resource cleanup](runtime-monitoring-agent-resource-clean-up.md), GuardDuty will not delete or remove all the security agent resources. The following section provides instructions on how you can delete the security agent resources.

**To delete Amazon VPC endpoint**  
When you manage the security agent manually, you may have created an Amazon VPC endpoint manually. After uninstalling the security agent for all the monitored resources in your account, you can choose to delete this VPC endpoint.  
The following list provides scenarios when using a shared VPC compared to not using a shared VPC.  
+ Without a shared VPC – When you no longer want to monitor a resource in an account, consider deleting the Amazon VPC endpoint.
+ With a shared VPC – When a shared VPC owner account deletes the shared VPC resource that was still being used, the Runtime Monitoring (and when applicable, EKS Runtime Monitoring) coverage status for the resources in your shared VPC owner account and the participating account might become unhealthy. For information about coverage status, see [Reviewing runtime coverage statistics and troubleshooting issues](runtime-monitoring-assessing-coverage.md).
For deleting the VPC endpoint, see [Delete an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/delete-interface-endpoint.html) in the *AWS PrivateLink Guide*.

**To delete the security group**  
+ Without a shared VPC – When you no longer want to monitor a resource type in an account, consider deleting the security group associated with the Amazon VPC.
+ With a shared VPC – When the shared VPC owner account deletes the security group, any participant account that is currently using the security group associated with the shared VPC, the Runtime Monitoring coverage status for the resources in your shared VPC owner account and the participating account might become unhealthy. For more information, see [Reviewing runtime coverage statistics and troubleshooting issues](runtime-monitoring-assessing-coverage.md).
For information about steps, see [Delete an Amazon EC2 security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deleting-security-group.html) in the *Amazon EC2 User Guide*.

**To remove GuardDuty security agent from an EKS cluster**  
To remove the security agent from your EKS cluster that you no longer want to monitor, see [Removing an Amazon EKS add-on from a cluster](https://docs.aws.amazon.com/eks/latest/userguide/removing-an-add-on.html) in the *Amazon EKS User Guide*.  
Removing the EKS add-on agent doesn't remove the `amazon-guardduty` namespace from the EKS cluster. To delete the `amazon-guardduty` namespace, see [Deleting a namespace](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).

**To delete the `amazon-guardduty` namespace (EKS cluster)**   
Disabling Automated agent configuration doesn't automatically remove the `amazon-guardduty` namespace from your EKS cluster. To delete the `amazon-guardduty` namespace, see [Deleting a namespace](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).