はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した AWS Organizations / SCP 関連の知識をまとめました。
SCP の適用範囲（特にルートユーザーへの適用）や Tag Policy との使い分けは、試験で頻繁に問われるポイントです。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
SCP（Service Control Policy）の特徴
- Organizations 内のメンバーアカウントの最大権限を制御
- メンバーアカウントのルートユーザーにも適用される（IAM ポリシーとの最大の違い）
- 管理アカウント（マスターアカウント）には影響しない
- サービスリンクロールには影響しない
- 権限を付与するのではなく、権限の上限を設定（ガードレール）
SCP の適用範囲
| 対象 | SCP の影響 |
|---|---|
| メンバーアカウントの IAM ユーザー | ✅ |
| メンバーアカウントの IAM ロール | ✅ |
| メンバーアカウントのルートユーザー | ✅ |
| 管理アカウント（マスター） | ❌ |
| サービスリンクロール | ❌ |
「SCP はルートユーザーにも適用される」という点が IAM ポリシーとの最大の違いであり、試験の頻出ポイントです。
Tag Policy
- タグキー / 値の標準化を強制（ガバナンス / 監査）
- 実際の API 呼び出しはブロックしない（SCP と併用してブロック）
AWS Organizations の機能
- 複数 AWS アカウントの一元管理
- OU（Organizational Unit）による階層管理
- SCP、Tag Policy、Backup Policy、AI Services Opt-out Policy
- 統合請求
AWS Alternate Contacts
- AWS アカウントごとに3つの連絡先を指定可能: Billing / Security / Operations
- ルートメールとは別にカテゴリ別の通知先を指定
- Organizations 経由で一括管理可能
マルチアカウントベストプラクティス
- ルートメール: 集中管理メールボックスにエイリアス（個人メール禁止）
- Alternate Contacts: チーム配布リスト（個人メール禁止）
- IAM ポリシーより SCP でガードレール
- CloudFormation StackSets で統一構成をデプロイ
試験で問われる設計パターン
SCP 系
Organizations 内のアカウントで CloudTrail 変更を禁止 → SCP
シナリオ: 開発者がルートユーザーアクセスを持っている Organizations 内のアカウントで、CloudTrail の設定変更を禁止したいです。どの方法が最も効果的でしょうか？
正解: SCP で CloudTrail 変更を禁止
- 開発者がルートユーザーを使える → IAM ポリシーでは不十分（ルートが変更可能）
- SCP はルートユーザーにも適用される
EC2 タグ強制 + 削除防止 → SCP + Tag Policy
シナリオ: すべての EC2 インスタンスに dataClassification タグを強制し、値を confidential または public に制限したいです。タグの削除も防止したいです。（2つ選択）
正解:
- Tag Policy:
dataClassificationキーを強制、値を制限 - SCP:
ec2:RunInstancesをタグなしで拒否 +ec2:DeleteTagsを拒否
- Tag Policy = タグの標準化・監査
- SCP = 実際の API 呼び出しをブロック（プロアクティブ）
- Lambda / Config / SSM はリアクティブ（予防ではない）
SCP の適用範囲を問う問題
シナリオ: SCP について正しい記述を3つ選んでください。
正解:
- SCP で許可されていない / Deny されたアクションは IAM で許可されていても実行不可
- SCP はメンバーアカウントの全ユーザー・ロール（ルートユーザー含む）に影響
- SCP はサービスリンクロールには影響しない
- 管理アカウントには影響しない
- サービスリンクロールを制限すると AWS サービスの正常動作を妨害する可能性がある
マルチアカウント管理系
複数アカウント・リージョンに同じテンプレートをデプロイ → CloudFormation StackSets
シナリオ: Organizations 内の複数アカウント・複数リージョンに同じインフラ構成をデプロイしたいです。最も効率的な方法はどれでしょうか？
正解: AWS CloudFormation StackSets
- Template（定義）→ Stack（単一デプロイ）→ StackSet（マルチデプロイ）
- RAM はリソース共有（テンプレートデプロイではない）
オンプレ AD + マルチアカウント SSO → IAM Identity Center + AWS Managed AD
シナリオ: オンプレミスの Active Directory と連携して、Organizations 内の複数アカウントに SSO でアクセスしたいです。どの構成が最適でしょうか？
正解: IAM Identity Center + AWS Directory Service for Microsoft AD + 双方向信頼関係
- AWS Managed AD は信頼関係をサポート
- AD Connector はプロキシのみ（信頼関係不可）
- IAM Identity Center + Permission Sets でマルチアカウント管理
AWS 通知の適切なルーティング → ルートメールエイリアス + Alternate Contacts
シナリオ: 複数の AWS アカウントで、セキュリティ通知はセキュリティチームに、請求通知は経理チームに適切にルーティングしたいです。
正解: ルートメールをエイリアス → 集中管理メールボックス + Alternate Contacts にチーム配布リスト
- ルートメールに個人メールを使うのは単一障害点
- Alternate Contacts = Billing / Security / Operations 別に通知先を指定
複数アカウントの EC2 間プライベート通信（最安）→ RAM でサブネット共有
シナリオ: 複数の AWS アカウントに所属する EC2 同士を、最もコストを抑えてプライベートに通信させたいです。
正解: 1つの VPC のサブネットを AWS RAM で共有
- RAM は追加料金なし
- Transit Gateway はコストが高い
おわりに
Organizations / SCP は「ガードレール」として機能するサービスであり、特に「SCP はルートユーザーにも適用される」「管理アカウントには影響しない」「Tag Policy だけでは API をブロックできない」の3点を押さえておけば、試験の問題に対応できます。
間違いや補足があればぜひコメントで教えてください。