Prerequisites for Amazon EC2 instance support - Amazon GuardDuty
Make EC2 instances SSM managedValidating architectural requirementsValidating your organization service control policyWhen using automated agent configurationCPU and memory limitNext step

Prerequisites for Amazon EC2 instance support

This section includes the prerequisites for monitoring runtime behavior of your Amazon EC2 instances. After these prerequisites are met, see Enabling GuardDuty Runtime Monitoring.

Make EC2 instances SSM managed

The Amazon EC2 instances for which you want GuardDuty to monitor runtime events must be AWS Systems Manager (SSM) managed. This is regardless of whether you use GuardDuty to manage the security agent automatically, or manage it manually. However, when you manage the agent manually by using the manual Method 2 - Using Linux Package Managers, there is no need for your EC2 instances to be SSM managed.

To manage your Amazon EC2 instances with AWS Systems Manager, see Setting up Systems Manager for Amazon EC2 instances in the AWS Systems Manager User Guide.

Note for Fedora-based EC2 instances

AWS Systems Manager doesn't support the Fedora OS distribution. After enabling Runtime Monitoring, use the manual method (Method 2 - Using Linux Package Managers) to install the security agent in Fedora-based EC2 instances.

For information about supported platforms, see Supported package platforms and architectures in the AWS Systems Manager User Guide.

Validating architectural requirements

The architecture of your OS distribution might impact how the GuardDuty security agent will behave. You must meet the following requirements before using Runtime Monitoring for Amazon EC2 instances:

  • The following table shows the OS distribution that has been verified to support the GuardDuty security agent for Amazon EC2 instances.

    OS distribution1 Kernel version2 Kernel support CPU architecture
    x64 (AMD64) Graviton (ARM64)

    AL2 and AL2023

    Ubuntu 20.04 and Ubuntu 22.04

    Debian 11 and Debian 12

    5.43, 5.103, 5.15, 6.1, 6.5, 6.8

    eBPF, Tracepoints, Kprobe

    Supported

    Supported

    Ubuntu 24.04

    		 6.8

    RedHat 9.4

    5.14

    Fedora4 34.0

    5.11, 5.17

    CentOS Stream 9

    5.14

    1. Support for various operating systems - GuardDuty has verified the support for using Runtime Monitoring on the operating systems that are listed in the preceding table. While using a different operating system, you might get all the expected security value that GuardDuty has verified to provide on the listed OS distributions.

    2. 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.

    3. 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.

    4. Fedora is not a supported platform for automated agent configuration. You can deploy the GuardDuty security agent on Fedora by using Method 2 - Using Linux Package Managers.

  • Additional requirements - Only if you have Amazon ECS/Amazon EC2

    For Amazon ECS/Amazon EC2, we recommend that you use the latest Amazon ECS-optimized AMIs (dated September 29, 2023 or later), or use Amazon ECS agent version v1.77.0.

Viewing and updating RLIMIT_MEMLOCK values

When your system's RLIMIT_MEMLOCK limit is set too low, GuardDuty security agent may not perform as designed. GuardDuty recommends that both hard and soft limits must be at least 32 MB. If you don't update the limits, GuardDuty will be unable to monitor the runtime events for your resource. When RLIMIT_MEMLOCK is above the minimum stated limits, it becomes optional for you to update these limits.

You can modify the default RLIMIT_MEMLOCK value either before or after installing the GuardDuty security agent.

To view RLIMIT_MEMLOCK values

  1. Run ps aux | grep guardduty. This will output the process ID (pid).

  2. Copy the process ID (pid) from the output of the previous command.

  3. 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.

  2. Open the /etc/systemd/system.conf file and uncomment the line that has #DefaultLimitMEMLOCK=.

  3. 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.

  4. Run sudo reboot.

Validating your organization service control policy

If you have set up a service control policy (SCP) to manage permissions in your organization, validate that permissions boundary is not restricting guardduty:SendSecurityTelemetry. It is required for GuardDuty to support Runtime Monitoring across different resource types.

If you are a member account, connect with the associated delegated administrator. For information about managing SCPs for your organization, see Service control policies (SCPs).

When using automated agent configuration

To Use automated agent configuration (recommended), 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/ 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.

    • For the exclusion tags to work, update the instance configuration so that the instance identity document is available in instance metadata service (IMDS). Procedure to do this step is already a part of Enabling Runtime Monitoring for your account.

CPU and memory limit for GuardDuty agent

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.

Memory of the Amazon EC2 instance

Maximum memory for GuardDuty agent

Less than 8 GB

128 MB

Less than 32 GB

256 MB

More than or equal to 32 GB

1 GB

Next step

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