本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 多個 AWS 帳戶和區域的修補解決方案設計
您可以擴展自動化修補解決方案，以支援跨越多個 AWS 帳戶和多個 AWS 區域的伺服器。延伸解決方案包括透過共用服務 AWS 帳戶中的 AWS CloudFormation StackSets 在每個帳戶中設定修補程式自動化解決方案，以及設定共用服務帳戶跨帳戶的資源資料同步。
## 自動化程序
下圖說明此案例的架構。此架構包含 CloudFormation StackSets 和 AWS 共用服務帳戶。
工作流程類似於上一節所述的程序，但涉及下列額外步驟，其中步驟編號符合圖表中的標註：
1. 在共用服務帳戶中， CloudFormation 堆疊集用於設定 S3 儲存貯體，以便透過 Systems Manager 庫存進行資源資料同步。
1. CloudFormation 堆疊集會使用 `automate-patch` Lambda 函數建立堆疊、設定修補程式基準，並在應用程式帳戶上設定 Systems Manager 庫存資源資料同步，以同步共用服務帳戶中的資源。
1. 應用程式帳戶中的資源資訊會與共用服務帳戶中的資源資訊同步。
1. 使用同步資源資訊的 Amazon Athena 資料集，快速產生修補程式合規報告。
## 架構考量和限制
### 每個帳戶的維護時段配額
上一節中說明和描述的架構會為每個修補程式群組建立維護時段。不過，每個 AWS 帳戶的維護時段數量配額為 50 （假設您尚未請求提高服務配額）。如果您預期單一 AWS 帳戶中的修補程式群組數量會超過 50 個群組，則此架構不會擴展以符合您的需求。
如果增加服務配額不足以滿足您的需求，有兩種管理此挑戰的選項：使用預先定義的維護時段和使用 CloudWatch Events。以下是每種方法的優點和缺點。
**選項 1。使用預先定義的維護時段**
+ 定義具有各種時段的維護時段清單 （例如，每個帳戶 15 到 20 個維護時段）。
+ 應用程式團隊會從預先定義的清單中選擇適合他們的維護時段，並相應地標記執行個體。
+ 更新自動修補解決方案，將修補程式群組對應至選取的維護時段，而不是建立新的維護時段。
優點：
+ 簡化管理。
缺點：
+ 定義自訂維護時段的靈活性較低。
+ 當多個修補程式群組共用維護時段和修補程式任務時，取消特定修補程式群組的特定修補程式任務需要額外的手動工作。
**選項 2。使用 CloudWatch Events 觸發修補程式任務，而不是使用維護時段**
+ 使用 CloudWatch Events 根據排程和修補程式群組觸發修補程式任務，而不是建立維護時段。
+ 在此案例中，每個修補程式群組都與 CloudWatch Events 事件相關聯，而不是與維護時段相關聯。
+ 更新自動修補解決方案以建立事件，而非維護時段。
優點：
+ 可擴展的設計。
+ 提供定義自訂維護時段的彈性。
缺點：
+ 維護時段提供 CloudWatch Events 無法使用的其他功能 （例如持續時間和截止時間）。
### 其他考量
+ 本節中描述的自動修補解決方案不支援關閉的 EC2 執行個體。
+ 此程序支援公有子網路中的 EC2 執行個體。若要修補私有子網路中的執行個體，您必須部署[本機修補程式儲存庫，例如 Windows Server Update Services (WSUS)](https://aws.amazon.com/blogs/mt/how-to-patch-windows-ec2-instances-in-private-subnets-using-aws-systems-manager/)。
+ 您必須調整執行 Lambda 函數的頻率，以便根據所需的排程更新修補程式群組和維護時段。