本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon EC2 实例支持的先决条件
<a name="prereq-runtime-monitoring-ec2-support"></a>

本节包含监控 Amazon EC2 实例的运行时行为的先决条件。满足这些先决条件后，请参阅[启用 GuardDuty 运行时监控](runtime-monitoring-configuration.md)。

**Topics**
+ [将 EC2 实例设为由 SSM 托管（仅限自动代理配置）](#ssm-managed-prereq-ec2)
+ [验证架构要求](#validating-architecture-req-ec2)
+ [在多账户环境中验证组织服务控制策略](#validate-organization-scp-ec2)
+ [使用自动代理配置时](#runtime-ec2-prereq-automated-agent)
+ [GuardDuty 代理的 CPU 和内存限制](#ec2-cpu-memory-limits-gdu-agent)
+ [后续步骤](#next-step-after-prereq-ec2)

## 将 EC2 实例设为由 SSM 托管（仅限自动代理配置）
<a name="ssm-managed-prereq-ec2"></a>

GuardDuty 使用 AWS Systems Manager (SSM) 在您的实例上自动部署、安装和管理安全代理。如果您计划手动安装和管理 GuardDuty 代理，则不需要 SSM。

要使用 Systems Manager 管理 Amazon EC2 实例，请参阅《AWS Systems Manager 用户指南》**中的[为 Amazon EC2 实例设置 Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)。

## 验证架构要求
<a name="validating-architecture-req-ec2"></a>

操作系统分发的架构可能会影响 GuardDuty 安全代理的行为。在为 Amazon EC2 实例使用运行时监控之前，您必须满足以下要求：
+ 内核支持包括 `eBPF`、`Tracepoints` 和 `Kprobe`。对于 CPU 架构，运行时监控支持 AMD64 (`x64`) 和 ARM64 （Graviton2 及更高版本）。[1](#runtime-monitoring-ec2-graviton-2-support)

  下表显示了经验证可支持 Amazon EC2 实例 GuardDuty安全代理的操作系统分配。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

  1. <a name="runtime-monitoring-ec2-graviton-2-support"></a>Amazon EC2 资源运行时监控不支持第一代 Graviton 实例，例如 A1 实例类型。

  1. <a name="runtime-monitoring-ec2-os-support"></a>对各种操作系统的支持- GuardDuty 已验证运行时监控支持上表中列出的操作发行版。虽然 GuardDuty 安全代理可以在上表中未列出的操作系统上运行，但该 GuardDuty 团队无法保证预期的安全值。

  1. <a name="runtime-monitoring-ec2-kernel-version-required-flag"></a>对于任何内核版本，都必须将 `CONFIG_DEBUG_INFO_BTF` 标志设置为 `y`（含义为 *true*）。这是必需的，这样 GuardDuty 安全代理才能按预期运行。

  1. <a name="runtime-monitoring-ec2-kernel-5-10"></a>对于内核版本 5.10 及更早版本， GuardDuty 安全代理使用 RAM (`RLIMIT_MEMLOCK`) 中的锁定内存来按预期运行。如果您的系统`RLIMIT_MEMLOCK`值设置得太低， GuardDuty 建议将硬限制和软限制都设置为至少 32 MB。有关验证和修改默认 `RLIMIT_MEMLOCK` 值的信息，请参阅[查看和更新 `RLIMIT_MEMLOCK` 值](#runtime-monitoring-ec2-modify-rlimit-memlock)。

  1. <a name="runtime-monitoring-ec2-ubuntu-noble-agent-version"></a>对于 Ubuntu 24.04，内核版本 6.13 和 6.14 仅支持 EC2 代理版本 1.9.2 及更高版本。
+ 其他要求-仅当您拥有 Amazon ECS/Amazon EC2 时

  对于亚马逊 ECS/Amazon EC2，我们建议您使用最新的亚马逊 ECS 优化版 AMIs （日期为 2023 年 9 月 29 日或之后），或者使用亚马逊 ECS 代理版本 1.77.0。

### 查看和更新 `RLIMIT_MEMLOCK` 值
<a name="runtime-monitoring-ec2-modify-rlimit-memlock"></a>

当您的系统`RLIMIT_MEMLOCK`限制设置得太低时， GuardDuty 安全代理可能无法按设计运行。 GuardDuty 建议硬限制和软限制都必须至少为 32 MB。如果您不更新限制， GuardDuty 将无法监控资源的运行时事件。当 `RLIMIT_MEMLOCK` 超过规定的最低限额时，您可以选择更新这些限制。

您可以在安装 GuardDuty 安全客户端之前或之后修改默认`RLIMIT_MEMLOCK`值。

**查看 `RLIMIT_MEMLOCK` 值**

1. 运行 `ps aux | grep guardduty`。这将输出进程 ID (`pid`)。

1. 从上一条命令的输出中复制进程 ID (`pid`)。

1. 将 `pid` 替换为从上一步中复制的进程 ID，然后运行 `grep "Max locked memory" /proc/pid/limits`。

   这将显示运行 GuardDuty 安全代理时的最大锁定内存。

**更新 `RLIMIT_MEMLOCK` 值**

1. 如果 `/etc/systemd/system.conf.d/NUMBER-limits.conf` 文件存在，则从该文件中注释掉 `DefaultLimitMEMLOCK` 行。此文件将默认 `RLIMIT_MEMLOCK` 设置为高优先级，这会覆盖您在 `/etc/systemd/system.conf` 文件中的设置。

1. 打开 `/etc/systemd/system.conf` 文件并取消注释包含 `#DefaultLimitMEMLOCK=` 的行。

1. 更新默认值，将 `RLIMIT_MEMLOCK` 硬限制和软限制设置为至少 32 MB。更新后的策略应如下所示：`DefaultLimitMEMLOCK=32M:32M`。格式为 `soft-limit:hard-limit`。

1. 运行 `sudo reboot`。

## 在多账户环境中验证组织服务控制策略
<a name="validate-organization-scp-ec2"></a>

如果您设置了服务控制策略（SCP）来管理组织中的权限，请验证权限边界允许 `guardduty:SendSecurityTelemetry` 操作。它是支持跨不同资源类型的运行时监控所必需的。 GuardDuty 

如果您是成员账户，则连接到关联的委派管理员。有关为您的组织 SCPs 进行管理的信息，请参阅[服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。

## 使用自动代理配置时
<a name="runtime-ec2-prereq-automated-agent"></a>

为[使用自动代理配置（推荐）](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2)此，您 AWS 账户 必须满足以下先决条件：
+ 在自动代理配置中使用包含标签时， GuardDuty 要为新实例创建 SSM 关联，请确保新实例由 SSM 管理并显示在控制台的 **Fleet Manager** 下。[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
+ 将排除标签与自动代理配置结合使用时
  + 在为您的账户配置 GuardDuty 自动代理之前，请添加`GuardDutyManaged`:`false`标签。

    务必要在启动 Amazon EC2 实例之前添加排除标签。为 Amazon EC2 启用自动代理配置后，任何启动时没有排除标签的 EC2 实例都将受到 GuardDuty 自动代理配置的保护。
  + 为您的实例启用**允许在元数据中添加标签**设置。此设置是必需的，因为 GuardDuty 需要从实例元数据服务 (IMDS) 读取排除标签，以确定是否应将该实例排除在代理安装之外。有关更多信息，请参阅《Amazon EC2 用户指南》**中的[启用对实例元数据中标签的访问权限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS)。

## GuardDuty 代理的 CPU 和内存限制
<a name="ec2-cpu-memory-limits-gdu-agent"></a>

**CPU 限制**  
与 Amazon EC2 实例关联 GuardDuty 的安全代理的最大 CPU 限制为 vCPU 内核总数的 10%。例如，假设您的 EC2 实例有 4 个 vCPU 核心，则在 400% 的总可用容量中，安全代理最多可以使用 40%。

**内存限制**  
从与您的 Amazon EC2 实例关联的内存中， GuardDuty 安全代理可以使用的内存有限。  
具体内存限制详见下表。      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)

## 后续步骤
<a name="next-step-after-prereq-ec2"></a>

下一步是配置运行时监控并管理安全代理（自动或手动）。