针对多个 AWS 账户和地区的修补解决方案设计 - AWS 规范性指导
自动化流程架构注意事项和限制

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

针对多个 AWS 账户和地区的修补解决方案设计

您可以扩展自动修补解决方案，以支持跨多个 AWS 账户和多个 AWS 区域的服务器。扩展解决方案包括通过共享服务帐户在每个 AWS 帐户中设置补丁自动化解决方案，并使用共享服务帐户 AWS CloudFormation StackSets 在账户之间配置资源数据同步。

自动化流程

下图阐明了该场景的架构。此架构 AWS CloudFormation StackSets 包括 AWS 共享服务帐户。

Reference architecture and workflow for patching mutable EC2 instances that span multiple AWS accounts and AWS Regions

该工作流与上一节中描述的过程类似，但涉及以下其他步骤，其中步骤编号与图表中的标注相匹配：

  1. 在共享服务账户中， AWS CloudFormation 堆栈集用于配置 S3 存储桶，以便通过 Systems Manager 清单同步资源数据。

  2. CloudFormation 堆栈集使用 automate-patch Lambda 函数创建堆栈，设置补丁基准，并在应用程序账户上设置 Systems Manager Inventory 资源数据同步，以同步共享服务账户中的资源。

  3. 应用程序账户中的资源信息与共享服务账户中的资源信息同步。

  4. QuickSight 使用 Amazon Athena 数据集生成补丁合规性报告，获取同步的资源信息。

架构注意事项和限制

每个账户的维护窗口

上一节中说明和描述的架构为每个补丁组创建了一个维护窗口。但是，每个 AWS 账户的维护窗口数量配额为 50（假设您尚未申请增加服务限额）。如果您预计单个 AWS 账户中的补丁组数量超过 50 个，则此架构无法扩展以满足您的需求。

如果增加服务配额不足以满足您的需求，则有两种方法可以应对此挑战：使用预定义的维护时段和使用 CloudWatch 事件。以下是每种方法的优势和劣势。

选项 1。使用预定义的维护窗口

  • 定义具有不同时间窗的维护窗口列表（例如，每个账户 15 到 20 个维护窗口）。

  • 应用程序团队从预定义列表中选择适合自己的维护窗口，并相应地标记实例。

  • 更新自动修补解决方案，将补丁组映射到选定的维护窗口，而不是创建新的维护窗口。

优点：

  • 简化的管理。

缺点：

  • 定义自定义维护窗口的灵活性较低。

  • 当多个补丁组共享维护窗口和补丁任务时，取消特定补丁组的特定补丁任务需要额外的手动操作。

选项 2。使用 CloudWatch 事件触发补丁任务，而不是使用维护窗口

  • 与其创建维护窗口，不 CloudWatch 如使用事件根据时间表和补丁组触发补丁任务。

  • 在这种情况下，每个补丁组都与 CloudWatch 事件事件相关联，而不是与维护时段关联。

  • 更新自动修补解决方案以创建事件而不是维护窗口。

优点：

  • 可扩展设计。

  • 为定义自定义维护窗口提供灵活性。

缺点：

  • 维护时段提供了事件不提供的其他功能（例如持续时间和截止时间）。 CloudWatch

其他考虑因素

  • 本节中描述的自动修补解决方案不支持已关闭的 EC2实例。

  • 此过程支持公有子网中的 EC2 实例。要修补私有子网中的实例，必须部署本地补丁存储库，例如 Windows Server Update Services (WSUS)。

  • 您必须调整运行 Lambda 函数的频率，以便根据所需的计划更新补丁组和维护窗口。