導入
アカウントが増えてくると、「どのアカウントも誤って高額なリソースを使えないようにしたい」「本番アカウントでは特定の操作を絶対に禁止したい」という組織全体のガードレールが必要になります。
説明
AWS Organizations は、複数のAWSアカウントを1つの組織としてまとめて管理するサービスです。アカウントをOU（組織単位）ごとにグルーピングし、一括請求（Consolidated Billing）や後述のSCPを適用できます。
flowchart TD
ORG["管理アカウント（Organizations）"] --> OU1["OU: 本番"]
ORG --> OU2["OU: 開発"]
OU1 --> A1["本番アカウント1"]
OU1 --> A2["本番アカウント2"]
OU2 --> A3["開発アカウント1"]
SCP（サービスコントロールポリシー） は、OUやアカウント単位で「許可できる権限の上限」を定めるポリシーです。ここが最重要ポイントです。
- SCPはIAMポリシーのように「権限を与える」ものではなく、「この範囲を超えて許可することはできない」という天井（枠）を定める
- SCPで禁止された操作は、そのアカウント内でどんなにIAMポリシーがAllowしていても実行できない
- 例：「本番OU配下のアカウントでは、EC2の特定リージョン以外での起動を一律禁止する」
flowchart LR
SCP["SCP（許可の上限）"] --> IAM["IAMポリシー（実際の権限）"]
IAM --> EFF["実効権限 = SCPの範囲 ∩ IAMの許可"]
その他、SAAで押さえておくべきガバナンス関連のサービスは次の通りです。
| サービス | 役割 |
|---|---|
| Permission Boundary | IAMユーザー/ロール単位で「委任できる権限の上限」を設定（権限昇格の防止） |
| IAM Access Analyzer | 意図せず外部に公開されているリソース（S3バケット、IAMロールなど）を検出 |
具体例
SCPが「天井」であることの意味を、具体的な衝突で見てみましょう。
ある企業が「全社で東京・大阪リージョン以外は使わない」と決め、本番OUにSCPで「東京・大阪以外のリージョンでのリソース作成を拒否」を設定しました。
ここで、本番アカウントの管理者が、うっかり AdministratorAccess（全権限）を持つIAMユーザーで、バージニアリージョンにEC2を立てようとします。IAM的にはAdministratorAccessなのでAllowされているはずです。ところが——作成は失敗します。
なぜなら実効権限は「SCPの範囲 ∩ IAMの許可」の共通部分だから。IAMがどれだけ広く許可しても、SCPという天井を超えることはできません。バージニアはSCPで塞がれているので、管理者権限でも不可能です。
この3層を整理すると：
- SCP … アカウント／OU全体の天井（組織のガードレール）
- Permission Boundary … 個々のユーザー／ロールの天井（権限昇格の防止）
- IAMポリシー … 実際に与える権限
実効権限は常にこれらの共通部分（AND）。「IAMでAllowなのになぜ実行できない？」という設問は、たいてい上位のSCPかBoundaryが天井になっているのが答えです。
読んでみよう
「SCPはアカウント/OU全体の天井、Permission Boundaryは個々のユーザー/ロールの天井、IAMポリシーは実際に与える権限」という3層構造を覚えておくと、ガバナンス系の問題を素早く解けます。実効権限は常にこれらの共通部分（AND）になる、という点も出題されやすいポイントです。