ある大手金融機関は、AWS Organizations を使用して 80 以上の AWS アカウントを管理しています。現在、各事業部門が独立した OU（組織単位）に属しており、共有サービス OU には中央ネットワークアカウント、セキュリティアカウント、ログアーカイブアカウントが含まれています。 同社は以下の要件を満たす必要があります。 ① すべてのアカウントで AWS Config ルールを一元管理し、準拠していないリソースを自動修復する。 ② 各 OU レベルで異なるセキュリティポリシーを適用する（例：本番 OU では特定のリージョンのみ使用可能）。 ③ 中央セキュリティチームのみが SCP を変更できるように制御する。 ④ 新しいアカウントが Organizations に追加された際に、自動的にセキュリティ設定が適用される。 最小限の運用オーバーヘッドでこれらの要件を満たすアーキテクチャとして最も適切なものはどれですか？
正解： A. AWS Control Tower を使用してランディングゾーンを構築する。Customizations for Control Tower（CfCT）を使用して SCP とアカウントファクトリーのカスタマイズを管理し、AWS Config の集約設定は中央セキュリティアカウントで AWS Config 集約器を設定する。Account Factory for Terraform を使用して新規アカウントのプロビジョニングを自動化する。 AWS Control Tower は多数のアカウントのガバナンスを一元管理するためのマネージドサービスで、ランディングゾーンの自動構築、ガードレール（SCP とConfig ルール）の適用、新規アカウントの自動プロビジョニングを提供します。CfCT を使用することでカスタム SCP や Config ルールを IaC（Infrastructure as Code: コードによるインフラ管理手法）として管理でき、Delegated Administrator パターンにより中央セキュリティチームへの権限委任も実現できます。運用オーバーヘッドが最小限で要件をすべて満たします。 選択肢Aは、AWS Control Tower とCfCT の組み合わせにより、Config一元管理・OU別SCP・権限委任・新規アカウント自動設定のすべての要件を最小限の運用オーバーヘッドで実現できます。 選択肢Bは、Lambda/EventBridgeによるカスタム実装は技術的に可能ですが、カスタムコードの開発・保守コストが高く運用オーバーヘッドが増大するため、最小限の運用負荷という要件を満たしません。 選択肢Cは、IAM Permission BoundaryはIAMエンティティの権限スコープを制限するものであり、AWS Organizations APIのSCP変更権限を特定チームのみに限定する要件③を直接満たすことができません。 選択肢Dは、CloudFormation StackSetsによるConfig/SCPリソースの展開は手動オペレーションが多く、新規アカウント追加時の自動セキュリティ設定（要件④）への対応が不完全で、Control Towerと比較して運用オーバーヘッドが大幅に増加します。