「SCPで本番リージョンを東京だけに絞ったのに、それってIAMでもできるよね？何が違うの？」——AWS Organizations を触り始めると、必ずここで一度つまずきます。私もSAP（Solutions Architect Professional）の学習で、SCPとIAMの線引きを自分の言葉で説明できず、「じゃあ管理者なら回避できるのか？」と自問したところで完全に手が止まりました。本記事は、私がその場で詰まった「許可（IAM）と、禁止の天井（SCP）は別物」という1点を、二度と取り違えないように「中の人が自分で外せるか」という1本の軸で整理します。
1. 結論：IAMは「個人の許可証」、SCPは「誰も破れない天井」
細かい挙動に入る前に、最上位の対比を先に置きます。これさえ握っておけば、設問でも実務でも判断がブレません。
- IAM＝個人の許可証。「誰が、何をしてよいか」を与える。許可の実体はこちら。
- SCP＝国の憲法・法律＝禁止の天井（上限）。「ここから先は誰もやってはいけない」という枠を決めるだけ。許可は一切与えない。
私が一番腹落ちした例えは「国の統治」でした。SCPは国の憲法で、国民全員（管理者もルートも）に一律でかかる天井。IAMはその下で配られる個人の許可証。両方がOKになって初めて操作が通る、という二段構えです。
| 観点 | IAM | SCP |
|---|---|---|
| 役割 | 許可を与える（個人の許可証） | 禁止の枠を決める（破れない天井） |
| 対象 | ユーザー／ロール単位 | OU／アカウント単位（上から一律） |
| 単体でできること | これだけで操作が通る | 許可はしない（枠を狭めるだけ） |
| 管理者・ルート | 自分で書き換えて回避できる | 管理者・ルートも破れない |
| 中の人が外せるか | 外せる（だからガードにならない） | 外せない（だからガードレールになる） |
2. 「二重ゲート」を取り違えない（SCP許可 かつ IAM許可）
正直に書きます。私が最初に詰まったのが、ここの因果でした。「SCPでS3を許可の枠に入れた。でもIAMにS3の許可が無い開発者は、S3を使えるか？」という問いに、一瞬「SCPで枠に入れたんだから使える？」と迷ったのです。
答えは「使えない」。SCPは枠（天井）を決めるだけで、許可そのものは与えないからです。操作が成功する条件は、必ず両方を満たすこと。
操作成功 ＝ SCPで禁止されていない（天井の内側） かつ IAMで許可されている（許可証がある）
どちらか一方でも欠けたら通りません。だから「SCPで許可した」という言い方自体がそもそも誤解で、SCPは「ここまではやってもいい上限」を示すだけ。実際に手を動かす許可はIAM側にしか無い。この二段構えを「二重ゲート」と呼びます。
3. SCPの威力は「逆向き」に出る ― 管理者もルートも縛れる
SCPの本当の価値は、許可の側ではなく禁止の側に出ます。SCPで禁止した操作は、たとえIAMでAdministratorAccess（フル権限）を持っていても、ルートユーザーであっても実行できません。これがIAMには絶対に出せない性質です。
学習中、「本番OUで東京以外のリージョンを禁止したい。SCPとIAM、どっちでやる？しかも管理者にも回避させたくない」という設問にぶつかったとき、私は結論（SCP）は当てられたものの、「なぜSCPでなければダメか」を言い切れませんでした。決定的な理由はこれです。
IAMは「中の人」が自分で書き換えて回避できる。SCPは上から全員にかかる天井で、中の人には外せない。
IAMで「東京以外禁止」を設定しても、Administrator権限を持つ開発者は自分のIAMポリシーを書き換えてその制限を外せてしまいます。これではガードになりません。一方SCPは組織の上位（管理アカウント）からかかる枠なので、メンバーアカウントの中にいる人間は——たとえ管理者でも——自分では絶対に外せない。だから「ガードレール（強制の枠）は必ずSCPで敷く」が鉄則になります。実務で言えば、リージョン制限・CloudTrailの停止禁止・ルートユーザー操作の禁止といった「絶対に破られては困る」ものは、IAMではなくSCPで縛るのが定石です。
4. 最頻出の罠：SCPは「管理アカウント」には効かない
ここがSAPでも実務でも一番引っかかるポイントで、私も学習中に「えっ、そこは例外なの？」と声が出ました。SCPは、Organizationsの管理アカウント（政府でいう本部・首都）には効きません。
つまり、全員を縛れるはずのSCPにも唯一の聖域があり、それが管理アカウントです。ここから2つの重要な結論が出ます。
- 管理アカウントでは本番ワークロードを動かしてはいけない。SCPという最強のガードレールが効かない場所なので、ここに本番を置くと「天井の無い部屋」で運用することになります。
- 管理アカウントが乗っ取られると、組織全体が落ちる（blast radius が最大）。聖域＝最も守るべき場所だからこそ、統治専用に隔離し、日常運用を持ち込まない。
この「管理アカウントに本番を置かない」という鉄則のそもそもの理由（=blast radiusを小さくする設計思想）は、アカウントをなぜ分けるのかという一段手前の話とセットで理解すると、二度と忘れません。そちらは記事を分けて解説しています（記事末尾にリンク）。
5. 実務とSAP試験での使い分け早見
「設問や要件に何が出たら、IAMとSCPのどちらを思い浮かべるか」を一覧にしておきます。私が学習で蓄積した足切りワードです。
| 状況・要件のキーワード | 使う仕組み | 決め手 |
|---|---|---|
| 個人・ロールに権限を与えたい | IAM | 許可の実体はIAMにしかない |
| 組織全体に「絶対やらせない」枠を敷く | SCP | 中の人が外せない天井だから |
| 管理者・ルートにも回避させたくない | SCP | IAMは自分で書き換え回避できる |
| 特定リージョン以外を禁止（ガードレール） | SCP | 強制の枠＝ガードレールはSCP |
| 「許可」が文中で問われている | IAM | SCPは許可を与えない（枠だけ） |
| 管理アカウントに制限をかけたい | （SCPでは不可） | 管理アカウントは聖域＝本番を置かない |
6. 私がつまずいたポイント（実体験）
整理しておいて言うのも何ですが、私はSCPとIAMを最初から綺麗に切り分けられたわけではありません。つまずきは2つでした。
- 「SCPで許可した」と口走った：SCPは枠を狭めるだけで許可は与えない。「二重ゲート（SCP許可かつIAM許可）」のうち、許可の実体はIAM側だけという非対称を最初は取り違えていました。
- 「なぜSCPでないとダメか」を言えなかった：結論（SCP）は当てられても、根拠が「中の人が自分で外せるか」だと言語化できなかった。ここを一言で言い切れるかが、本番での得点差になります。
まとめ
IAMは「許可証」、SCPは「破れない天井」。操作が通るのは両方OKのときだけ（二重ゲート）。SCPは管理者・ルートすら縛れるが、唯一管理アカウントには効かない——だからそこに本番を置かない。「許可か、禁止の天井か」「中の人が外せるか」の2問を順に当てれば、SCPとIAMで迷いません。
このSCP／IAMの整理は、私がAWS SAP合格を目指して続けている学習記録の一部です。挑戦の全体像と他のテーマは、以下のまとめページからどうぞ。