ある多国籍エンタープライズ企業がAWS Organizationsを使用しており、Root配下にProduction OU、Development OU、Sandbox OU、Security OUの4つのOUを持っています。コンプライアンスチームは以下のSCPによる統制を最小のSCP数で実装するよう求めています： (1) Production OUとDevelopment OUのすべてのアカウントで、us-east-1・eu-west-1・ap-northeast-1以外のリージョンへのリソース作成を全サービスで禁止する。 (2) Security OUのアカウントはセキュリティ調査のために任意のリージョンを利用可能にする。 (3) Sandbox OUでは開発者が任意のリージョンを使用できるが、コスト管理のためEC2とRDSの起動のみ上記3リージョンに限定する。 (4) 全組織でAWSアカウントのルートユーザーによるAPIアクション全般をDenyする。 (5) 緊急対応用のBreakGlassRoleは要件(1)(3)の制約から除外する。 上記要件を正しく、かつ最も少ないSCP数で実装する方法はどれですか？
正解： 3つのSCPを作成する。 ①全サービスのリージョン制限Deny SCP（aws:RequestedRegionのStringNotEquals条件、BreakGlassRoleをaws:PrincipalARNで除外）を1つ作成し、Production OUとDevelopment OUの両方に同一ポリシーとしてアタッチする。 ②EC2とRDSのみのリージョン制限Deny SCP（BreakGlassRole除外条件付き）を作成しSandbox OUにアタッチする。 ③ルートユーザーの全APIアクションをDenyするSCPを作成しRoot組織にアタッチする。Security OUには追加SCPをアタッチしない。 選択肢Aは、SCPの複数OU同時アタッチを活用して最小SCP数（3つ）で全要件を実装できます。Production OUとDevelopment OUに同一SCPをアタッチし、Security OUはSCPなし（制限なし）、Sandbox OUはEC2/RDS限定の制限SCPを適用することで、すべての要件を過不足なく満たします。 選択肢Bが誤りである根本的理由はSCPの継承原則にあります。親OUのDeny SCPは子OUのAllow SCPでは上書きできません。Sandbox OUへのFullAWSAccess追加やSecurity OUへのAllow SCPは無効で、Root DenyはSecurity OU・Sandbox OUにも引き続き適用されます。 選択肢CのRoot SCPでaws:PrincipalOrgPaths条件を使う方式では、AWSサービスがサービスプリンシパル（例：ec2.amazonaws.com、lambda.amazonaws.com）として直接APIコールを実行する場合にPrincipalOrgPaths条件が評価されないため、リージョン制限が適用されないセキュリティギャップが生じます。さらに、条件値にOU IDをハードコードする必要があり、OU再作成時のID変更でポリシーが無効化されるリスクもあります。 選択肢Dは同一内容のSCPをOUごとに重複作成しており非効率で、同一SCPを複数OUにアタッチすれば1つに削減できます。