ある大規模な製造業の多国籍企業は、AWS Organizations 配下に 400 個の AWS アカウントを保有しています。現在、すべてのアカウントは OU 階層なしにルート直下に配置されています。クラウドガバナンス強化のため、以下の OU 構造と要件を実装することが決定されました。 【OU 設計】 ・Security OU（Security-Tooling アカウント、Log-Archive アカウント） ・Infrastructure OU（Networking アカウント、Shared-Services アカウント） ・Workloads OU（Production OU、NonProduction OU） ・Sandbox OU（開発者向け実験アカウント） 【要件】 1. Workloads OU 配下の全アカウントを ap-northeast-1（プライマリ）と us-east-1（DR: Disaster Recovery）のみに制限する。IAM・CloudFront・Route 53・S3 コントロールプレーン等のグローバルサービスはリージョン制限から除外する。 2. EC2・RDS・Lambda リソースへの CostCenter タグおよび Environment タグの付与を義務付ける。ただし現在タグ移行期間中のため、タグ未付与によるリソース作成のブロックは不可。非準拠リソースはレポートでの可視化のみ行う。 3. Security-Tooling アカウントのセキュリティチームが、各メンバーアカウントに個別にロールを引き受けることなく GuardDuty および AWS Config を組織全体で一元管理できるようにする。 4. Workloads OU 配下のアカウントによる AWS Organizations からの脱退と CloudTrail 証跡の削除を禁止する。ただし Security OU のアカウントは監査目的で CloudTrail を管理できる権限を維持する必要がある。 5. Sandbox OU には上記のいかなる制限も適用しない。 ソリューションアーキテクトが推奨すべき 2 つのアクションはどれですか？
リージョン制限 SCP を Workloads OU レベルに適用することで、Security OU の監査権限と「Sandbox OU には制限を適用しない」要件5を同時に満たしながらワークロードを保護できます。CloudTrail 保護も Workloads OU に限定することで Security OU への影響を回避できます。 選択肢Bはタグポリシーの強制モードがリソース作成をブロックするため「可視化のみ」の要件に違反します。 選択肢Cはルート一括適用で Sandbox OU にもリージョン制限が波及し、Security OU も CloudTrail 削除禁止の影響を受けるため不適切です。