目次
1. 結論
AWS SCP (Service Control Policies) は、「組織全体のガードレール（絶対ルール）」です。AWS Organizations内の特定のアカウントやグループに対して、「このアカウントでは、たとえ管理者（Administrator）であっても、この操作だけは絶対にさせない」という最強の禁止令を出すことができます。
2. SAAで出やすいポイント
- 最大権限の制限: SCPは権限を「与える」ものではなく、使える「最大枠」を「制限する」もの。
- 最強の拒否 (Deny): SCPで拒否（Deny）された操作は、IAMポリシーでいくら許可（Allow）されていても実行できない。
- ルートユーザーにも適用: IAMポリシーとは異なり、各アカウントの「ルートユーザー」の操作も制限できるのが大きな特徴。
- 一括管理: 組織単位（OU）ごとに設定でき、新しいアカウントを作った際にも自動でルールが適用される。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「特定のアカウントで特定のサービスを禁止」 | SCP | アカウント単位の強い制限 |
| 「管理者やルートユーザーの権限も制限したい」 | SCP | IAMでは制限できない範囲をカバー |
| 「組織全体にセキュリティガードレールを適用」 | SCP | Organizationsレベルでの統制 |
4. ひっかけポイント
- 権限の付与: SCPで「Allow *」となっていても、それだけでは何もできない。実際に操作するには、アカウント内のIAMポリシーで個別に許可が必要。
- マスター（管理）アカウントへの制限: SCPは、Organizationsの「マスターアカウント」自身には適用されない（メンバーアカウントにのみ有効）。
- リソースベースポリシーとの関係: S3バケットポリシーなどで許可されていても、SCPで拒否されていればアクセスできない。
5. 覚え方
- 「親が出す『これだけはダメ！』という家訓」。
- 子供（メンバーアカウント）が自分の部屋（アカウント内）で何をしようと自由だが、家訓（SCP）で禁止されたことだけは、たとえ子供が「やっていい」と言い張っても絶対に許されないイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| AWS Organizations | SCPを使用するための前提となるマルチアカウント管理サービス。 |
| IAM Policy | 個別のユーザーやロールに具体的な権限を与えるために併用する。 |
| Permissions Boundary | IAMユーザー/ロールに対して、さらに細かく「権限の境界」を設ける機能（SCPと似ているが、対象が異なる）。 |
7. Obsidian管理メモ
- 復習ポイント: 「たとえAdministrator権限があっても拒否したい」という要件があれば、100% SCPが正解。
- 関連ノート: AWS Organizationsによるガバナンス
8. HTMLファイル名
aws-scp-service-control-policy-guide.html
