多個 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 庫存資源資料同步，以同步共用服務帳戶中的資源。

  3. 應用程式帳戶中的資源資訊會與共用服務帳戶中的資源資訊同步。

  4. QuickSight 會使用同步資源資訊的 Amazon Athena 資料集來產生修補程式合規報告。

架構考量和限制

每個帳戶的維護時段配額

上一節中說明和描述的架構會為每個修補程式群組建立維護時段。不過，每個 AWS 帳戶的維護時段數量配額為 50 （假設您尚未請求提高服務配額）。如果您預期單一 AWS 帳戶中的修補程式群組數量會超過 50 個群組，則此架構不會擴展以符合您的需求。

如果增加服務配額不足以滿足您的需求，有兩種管理此挑戰的選項：使用預先定義的維護時段和使用 CloudWatch Events。以下是每種方法的優點和缺點。

選項 1。使用預先定義的維護時段

  • 定義具有各種時段的維護時段清單 （例如，每個帳戶 15 到 20 個維護時段）。

  • 應用程式團隊會從預先定義的清單中選擇適合他們的維護時段，並相應地標記執行個體。

  • 更新自動修補解決方案，將修補程式群組對應至選取的維護時段，而不是建立新的維護時段。

專業人員：

  • 簡化管理。

Cons：

  • 定義自訂維護時段的靈活性較低。

  • 當多個修補程式群組共用維護時段和修補程式任務時，取消特定修補程式群組的特定修補程式任務需要額外的手動工作。

選項 2。使用 CloudWatch Events 觸發修補程式任務，而不是使用維護時段

  • 使用 CloudWatch Events 根據排程和修補程式群組觸發修補程式任務，而不是建立維護時段。

  • 在此案例中，每個修補程式群組都與 CloudWatch Events 事件相關聯，而不是與維護時段相關聯。

  • 更新自動修補解決方案以建立事件，而非維護時段。

專業人員：

  • 可擴展的設計。

  • 提供定義自訂維護時段的彈性。

Cons：

  • 維護時段提供 CloudWatch Events 無法使用的其他功能 （例如持續時間和截止時間）。

其他考量

  • 本節中描述的自動修補解決方案不支援關閉的 EC2 執行個體。

  • 此程序支援公有子網路中的 EC2 執行個體。若要修補私有子網路中的執行個體，您必須部署本機修補程式儲存庫，例如 Windows Server Update Services (WSUS)。

  • 您必須調整執行 Lambda 函數的頻率，以便根據所需的排程更新修補程式群組和維護時段。