導入
アカウントが増えてくると、「どのアカウントも誤って高額なリソースを使えないようにしたい」「本番アカウントでは特定の操作を絶対に禁止したい」という組織全体のガードレールが必要になります。
説明
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全体の天井、Permission Boundaryは個々のユーザー/ロールの天井、IAMポリシーは実際に与える権限」という3層構造を覚えておくと、ガバナンス系の問題を素早く解けます。実効権限は常にこれらの**共通部分（AND）**になる、という点も出題されやすいポイントです。