ある大手金融機関は AWS Organizations を使用して 40 個の AWS アカウントを管理しています。組織の OU（Organizational Unit：組織単位）構造は Root > Security OU（集中セキュリティ管理用）、Root > Workloads OU > Production OU（本番環境）、Root > Workloads OU > Development OU（開発環境）、Root > Sandbox OU（実験・学習用）となっています。セキュリティチームは以下の要件を実装する必要があります：(1) すべてのメンバーアカウントの AWS API アクティビティログを Security OU 内の集中管理 S3 バケットへ自動的に集約する、(2) Production OU 内のアカウントは ap-northeast-1（東京）と us-east-1（バージニア北部）のみ使用可能とし、それ以外のリージョンへの API コールを拒否する、(3) Sandbox OU のアカウントでは IAM ユーザーの新規作成を組織ポリシーレベルで禁止する、(4) Security OU 内の監査アカウントからすべてのメンバーアカウントの AWS Config 評価結果を集中管理する。運用オーバーヘッドを最小化しながらすべての要件を満たすソリューションはどれですか？
Organizations 証跡は全メンバーアカウントの API ログを自動収集するため個別設定が不要です。aws:RequestedRegion 条件付き SCP によるリージョン制限は OU 配下のアカウントへ自動継承されます。iam:CreateUser を拒否する SCP は組織ポリシーレベルで IAM ユーザー作成を予防的に禁止します。Config 組織集約設定はメンバーアカウントの個別承認なしに全データを集約できます。 選択肢BのCloudTrail個別設定は、各アカウントに個別の CloudTrail 証跡を設定しクロスリージョンレプリケーションで集約するなど手作業が多く、運用負荷が大幅に増大します。 選択肢CのControl Tower導入は、Permission Boundary はアカウント管理者が変更・削除できるため、組織ポリシーレベルでの強制的な禁止を確実には満たせません。 選択肢DのConfig自動修復ルール方式は、Production OU の各アカウントに個別 SCP を作成するため運用負荷が増大し、Sandbox OU の Config 自動修復は IAM ユーザー作成後の事後削除であり組織ポリシーレベルでの予防的禁止を満たしません。