導入
「開発者にIAM権限は自由に与えたいが、リージョンは東京だけに限定したい」「誰にも組織全体のCloudTrailは止めさせたくない」―― こうした組織全体の絶対ルールを、IAMポリシーとは別のレイヤーでかけるのがSCPです。
説明
SCP（Service Control Policy） は、AWS Organizations の OU やアカウントに対してかける、権限の上限（Permission Boundary） を定めるポリシーです。SAAで学んだIAMポリシーとの一番の違いは次の点です。
| 比較 | IAMポリシー | SCP |
|---|---|---|
| 適用対象 | IAMユーザー・ロール | OU・アカウント全体 |
| 効果 | 権限を「付与」できる | 権限を「付与」しない。上限を絞るだけ |
| Allow単体の意味 | それだけで許可される | Allowを書いても、他で許可されなければ何も起きない |
| 管理アカウントへの影響 | 通常どおり | 管理アカウントには効かない |
ここが最重要ポイントです。SCPはそれ単体では何も許可しません。「IAMポリシーで許可され、かつSCPでも許可されている」操作だけが実行できます。つまりSCPは「これ以上は絶対に許さない」という天井（ガードレール）であり、IAMポリシーは「実際に何ができるか」という実際の許可です。両方のANDを取った範囲だけが実行可能になります。
flowchart LR
I["IAMポリシーの許可範囲"] --> AND{"AND<br/>（両方が許可して初めて実行可）"}
S["SCPの許可範囲<br/>（組織のガードレール）"] --> AND
AND --> R["実際に実行できる操作"]
よく使われるガードレールの例です。
| ガードレールの目的 | SCPで書く内容 |
|---|---|
| 使ってよいリージョンを限定 | 指定リージョン以外の操作を Deny（条件キー aws:RequestedRegion） |
| CloudTrail・GuardDutyの停止を禁止 | ログ・検知系サービスの無効化アクションを Deny |
| root ユーザーの操作を禁止 | 条件キー aws:PrincipalType で root を Deny |
| 高額サービスの利用を禁止（Sandbox OU） | 特定サービスへの Deny（例: SageMaker 大型インスタンス禁止） |
| Organizations からの離脱を禁止 | organizations:LeaveOrganization を Deny |
評価の考え方は次の順です。SCPで明示的に Deny された操作は、IAMでどれだけ許可しても絶対に実行できません。逆にSCPが Allow していても、IAM側で許可がなければ実行できません。
具体例
「本番OU配下では東京リージョン以外にリソースを作らせない」という要件を、2つの方法で比べます。
方法A：各アカウントのIAMで頑張る … 本番アカウントが20個あるとして、それぞれのIAMポリシーに「東京以外をDeny」を書いて回る。新しいアカウントが増えるたびに追記が必要で、1つでも書き忘れれば穴になる。運用負荷が高く、抜けやすい。
方法B：SCPでOUに一括 … 本番OUに「aws:RequestedRegion が東京以外ならDeny」というSCPを1つ当てる。配下の全アカウントに即座に効き、新規アカウントもOUに入れれば自動で天井がかかる。管理者権限を持つ人でさえ東京以外には作れない。
ここで重要なのが評価の仕組み。ある開発者のIAMが「全リージョンでEC2作成OK」でも、SCPが東京以外をDenyしていれば実行できません（実効権限＝IAM ∩ SCP、明示的Denyが最優先）。SAPでは「組織全体の絶対ルールを、運用負荷を抑えてかけたい」と来たら、各アカウントにIAMを配るのではなくSCPでOU単位に天井をかける方が正解になりがちです。
読んでみよう
SAPでは「開発者が誤って本番リージョン以外にリソースを作れないようにしたい」「特定OU配下では高額なインスタンスタイプを使わせたくない」といった問題で、SCPのDenyで組織全体の天井を作る選択肢が正解になりがちです。「IAMポリシーだけで頑張って各アカウントに配る」より、「SCPでOU単位に一括で天井をかける」方が運用負荷が低い、という比較で選ばれることを意識してください。