翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 複数の AWS アカウントとリージョンのパッチソリューション設計
<a name="design-multi-account-region"></a>

自動パッチ適用ソリューションを拡張して、複数の AWS アカウントと複数の AWS リージョンにまたがるサーバーをサポートできます。拡張ソリューションでは、共有サービス AWS アカウントの AWS CloudFormation StackSets を通じて各アカウントのパッチ自動化ソリューションを設定し、共有サービスアカウントを持つアカウント間でリソースデータ同期を設定します。

## 自動化プロセス
<a name="multi-account-auto-process"></a>

次の図は、このシナリオのアーキテクチャーを示しています。このアーキテクチャには、 CloudFormation StackSets と共有 AWS サービスアカウントが含まれます。

 ![Reference architecture and workflow for patching mutable EC2 instances that span multiple AWS accounts and AWS Regions](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patch-management-hybrid-cloud/images/patching-process-multi-account-region.png) 

ワークフローは前のセクションで説明したプロセスと似ていますが、以下の追加ステップが含まれます。ステップ番号は図のコールアウトと一致します。

1. 共有サービスアカウントでは、 CloudFormation スタックセットを使用して、Systems Manager Inventory を介したリソースデータの同期用に S3 バケットを設定します。

1. CloudFormation スタックセットは、`automate-patch` Lambda 関数を使用してスタックを作成し、パッチベースラインを設定し、アプリケーションアカウントの Systems Manager インベントリリソースデータ同期を設定して、共有サービスアカウントのリソースを同期します。

1. アプリケーションアカウントのリソース情報は、共有サービスアカウントのリソース情報と同期されます。

1. Quick は、同期されたリソース情報の Amazon Athena データセットを使用して、パッチコンプライアンスレポートを生成します。

## アーキテクチャ上の考慮と制約事項
<a name="multi-account-considerations"></a>

### アカウントごとのメンテナンスウィンドウのクォータ
<a name="quota"></a>

前のセクションで説明したアーキテクチャでは、パッチグループごとにメンテナンスウィンドウが作成されます。ただし、 AWS アカウントごとのメンテナンス・ウィンドウ数のクォータは 50 です (サービス・クォータの増加をリクエストしていないことを前提とします)。パッチグループの数が 1 つの AWS アカウントで 50 を超えると予想される場合、このアーキテクチャは要件を満たすようにスケーリングされません。

サービスクォータの増加だけでは十分でない場合、この課題を管理するための 2 つのオプションがある：事前定義されたメンテナンスウィンドウを使用することと、CloudWatch Eventsを使用することです。それぞれのアプローチの長所と短所は以下の通りです。

**オプション 1. 定義済みのメンテナンスウィンドウを使用します**
+ さまざまなタイムウィンドウでメンテナンスウィンドウのリストを定義します (たとえば、アカウントごとに 15 ～ 20 のメンテナンスウィンドウ)。
+ アプリケーションチームは事前に定義されたリストから自分に合ったメンテナンスウィンドウを選択し、それに応じてインスタンスにタグを付けます。
+ 新しいメンテナンスウィンドウを作成する代わりに、自動パッチソリューションを更新して、選択したメンテナンスウィンドウにパッチグループをマッピングします。

メリット：
+ 簡略化された管理

デメリット：
+ カスタムのメンテナンスウィンドウを定義する柔軟性が低いです。
+ 複数のパッチグループがメンテナンスウィンドウとパッチタスクを共有している場合、特定のパッチグループの特定のパッチタスクをキャンセルすると、追加の手動作業が必要になります。

**オプション 2. メンテナンスウィンドウを使用する代わりに CloudWatch Events を使用してパッチタスクをトリガーします**
+ メンテナンスウィンドウを作成する代わりに、CloudWatch Events を使用してスケジュールとパッチグループに基づいてパッチタスクをトリガーします。
+ このシナリオでは、各パッチグループはメンテナンスウィンドウではなく CloudWatch Events イベントに関連付けられます。
+ 自動パッチ適用ソリューションを更新して、メンテナンスウィンドウではなくイベントを作成します。

メリット：
+ スケーラブルなデザイン。
+ カスタムメンテナンスウィンドウを柔軟に定義できます。

デメリット：
+ メンテナンスウィンドウには、CloudWatch Events では利用できない追加機能 (期間や締め切り時間など) が用意されています。

### その他の考慮事項
<a name="other"></a>
+ このセクションで説明する自動パッチソリューションは、シャットダウンされた 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 関数の実行頻度を調整する必要があります。