AWS Organizations Service Control Policy（SCP）は、組織内のアカウントが使用できる最大権限の境界線を設定するガバナンス機能です。SCPはガードレールとして機能し、IAMポリシーで許可された権限であっても、SCPで拒否された操作は実行不可能になります。

SCPの核心は「Denyが最優先」の原則です。どんなに強力なIAM権限があっても、SCPで明示的に拒否された操作は一切実行できません。この特性により、組織レベルでの確実なセキュリティ制御を実現できます。

Service Control Policyに関連した資格試験で重要なトピックを解説します。

SCPによる制限実装においてAllow文のみのポリシーが効果を発揮しない理由を理解することが重要です。AWS OrganizationsはデフォルトでフルAWSアクセスSCPを適用しており、このデフォルトSCPを削除することが制限実現の鍵となります。

SCPによる制限を実装する際のよくある誤解を具体的なポリシー例で確認しましょう。開発者OUに以下のカスタムSCPを適用したとします：

しかし、この状況ではフルAWSアクセスSCPも同時に適用されています：

実際の動作：フルAWSアクセスSCPが"Action": "*"ですべてのサービスを許可しているため、カスタムSCPのAllow文は効果を持ちません。S3、Lambda、その他すべてのAWSサービスが引き続き利用可能です。

この誤解が生じる理由は、「Allow文を追加すれば制限できる」という直感的な理解にあります。実際には、フルAWSアクセスSCPが存在する限り、すべてのサービスが利用可能な状態が続きます。

実装結果：フルAWSアクセスSCPが削除されたため、明示的に許可されたサービスのみ（EC2、RDS、ECS）が使用可能になります。S3、Lambda、その他のAWSサービスは自動的に拒否されます。

重要な技術的ポイントは、SCPによる効果的な制限は「明示的な拒否」ではなく「デフォルトSCPの削除と明示的な許可」の組み合わせで実現することです。この仕組みの理解が、AWS Organizationsの適切な運用につながります。

組織の複雑な要件に対応するため、要件別にSCPを設計し、適切なOUレベルに適用する階層戦略が重要です。同じ要件は上位レベル、異なる要件は個別OUレベルで管理します。

この図では、3つの異なるレベルでのSCP適用戦略を示しています。組織ルートレベルでは、全アカウントに適用すべき共通要件（IAMユーザー作成禁止）をSCPで制御します。

Production OUレベルでは、本番環境特有の厳格な要件（ルートユーザー操作禁止）を適用します。本番環境では人的ミスによる重大な影響を避けるため、最も制限的なポリシーを設定します。

Development OUレベルでは、開発効率と制御のバランスを取る要件（特定インスタンスタイプ・リージョン制限）を適用します。開発者の生産性を維持しながら、コスト制御とセキュリティ要件を満たします。

この階層アプローチにより、新しいアカウントの自動継承、一貫したポリシー適用、管理オーバーヘッドの最小化を同時に実現できます。各OUに新しいアカウントが追加されても、適切なSCPが自動的に適用されます。

ここまで学んだ3つの核心パターンを、実践的な問題で確認しましょう。各問題は実際の企業シナリオに基づいており、SCPの適用能力を評価します。

Service Control Policy（SCP）は、最大権限の境界線設定により組織レベルでの確実なガバナンスを実現します。3つの核心パターンを理解することで、複雑な企業要件にも対応できます。

これらのパターンを組み合わせることで、規制要件への対応、セキュリティインシデント防止、運用効率向上を同時に実現できます。特に金融、ヘルスケア、政府系など高度なガバナンス要件を持つ業界において、SCPは組織レベルでの確実な制御メカニズムを提供します。