「環境を分けたいだけなら、1つのアカウントの中でVPCやIAMで区切れば十分じゃないの？なんでアカウントごと分けるの？」——AWS Organizations を学び始めて、最初に私が腹落ちしなかったのがこれでした。SAP（Solutions Architect Professional）の学習で「開発者に本番を触らせない、一番確実な手段は？」と問われたとき、IAMの細かいポリシーを考え始めてしまった。正解は驚くほど単純で、アカウントごと分けるでした。本記事は、私がその場で遠回りした「なぜ分けるのか」を、blast radius（事故の被害範囲）という1本の軸で、二度と迷わないように整理します。
1. 全体地図：Organizationsは「国の統治」で理解する
細かいサービス名に入る前に、全体像を1枚の地図にします。私はこの「国の統治」の例えで一気に視界が晴れました。
- 1アカウント＝1つの街（これまで触ってきた、いつものAWSの世界）
- AWS Organizations＝中央政府（複数の街をまとめて統治する仕組み）
- 管理アカウント＝政府本部・首都（統治の中枢。特別扱いされる）
- OU（Organizational Unit）＝州・県（街をまとめてルールをかける箱）
- メンバーアカウント＝普通の街（本番・開発・経理などの実体）
この地図を持っておくと、後で出てくるSCPやガードレールの話が「どの階層にかかるルールか」として素直に乗ってきます。
2. なぜ分けるのか：アカウント境界は「最強かつ単純な権限分離」
私が遠回りしたのは、「分離＝IAMで細かく権限を絞ること」だと思い込んでいたからです。でも、開発者に本番を絶対に触らせたいない場面で一番確実なのは、IAMの作り込みではありません。
本番を別アカウントに分ける。そうすれば、そもそもその街に入れない。
IAMで「これは禁止、あれは許可」と積み上げる方式は、設定が複雑になるほど穴が生まれます。一方、アカウントを分けてしまえば、境界をまたぐこと自体が既定で不可能。別の街には、許可証以前に「そもそも入口が無い」状態になります。これが「アカウント境界＝最強かつ単純な権限分離」の意味で、確認問題で私が最終的に出した答えも「別アカウントに分ける。そもそも入れなくでき、管理も容易だから」でした。複雑なルールで守るより、物理的に部屋を分けるほうが強い、という発想の転換です。
3. 本当の根拠は「blast radius を小さくする」
権限分離は分かりやすい入口ですが、マルチアカウントの本当の根拠はもう一段深いところにあります。それがblast radius（事故の被害範囲）です。SAPで繰り返し出てくるキーワードなので、ここは言葉ごと覚える価値があります。
blast radius とは、「何か事故が起きたとき、被害がどこまで及ぶか」の範囲のことです。設定ミス、認証情報の漏洩、誤操作、攻撃——これらは0にはできません。だったら、起きたときに被害を1つの街の中に閉じ込める。すべてを1アカウントに詰め込んでいると、1つの事故が全環境を巻き込みます。アカウントを分けておけば、本番で事故っても開発や経理は無傷、という具合に被害半径を物理的に小さくできる。これが「なぜ分けるのか」の最終的な答えです。
4. OUの分け方と、踏みやすい設計
では実際にどう分けるか。確認問題で「3つの街（本番・開発・経理）をどうOUで分ける？」と問われたとき、私はこう答えました。
- 本番OU／開発OU／経理OUのように、性質ごとにOU（州）で束ねる。OUは「まとめてルール（後述のSCP）をかける箱」なので、性質が同じ街を同じ箱に入れると統治が一気に楽になる。
- 本番ワークロードを管理アカウントで動かさない。理由は次章。これは「やりがちだが踏んではいけない」設計の罠です。
OU単位でルールをかけられるのが効くポイントで、街が10個20個に増えても「箱」に対して一括で方針を効かせられます。逆に、OU設計を雑にすると後からルールが効かせづらくなる——ここは最初に効いてくる設計判断です。
5. 最重要の鉄則：管理アカウント（首都）に本番を置かない
ここがこの記事で一番伝えたい罠です。管理アカウント（政府本部・首都）は特別扱いされていて、組織全体にかける禁止ルール（SCP）すら効きません。私はここで「えっ、最強の本部なのに、ルールの聖域なの？」と声が出ました。
だからこそ、2つの鉄則が導かれます。
- 管理アカウントは統治専用に隔離する。ガードレールが効かない＝天井の無い部屋なので、ここで本番を動かすのは最も危険。
- 管理アカウントが乗っ取られると国全体が落ちる。聖域＝最も blast radius が大きい場所。だからこそ日常運用を一切持ち込まず、極小の操作だけに留める。
「最強の本部だから何でもやらせる」ではなく「最強で聖域だからこそ、何も置かない」。この逆説が腹落ちすると、マルチアカウント設計の勘所がぐっと掴めます。なお「SCPが管理アカウントに効かない」という挙動そのものの詳細（SCPとIAMはどう違うのか）は、記事を分けて解説しています（記事末尾にリンク）。
6. SAP試験での足切り早見
「要件に何が出たら、どう判断するか」を一覧にしておきます。私が学習で蓄積した足切りワードです。
| 状況・要件のキーワード | 判断 | 決め手 |
|---|---|---|
| 開発者に本番を絶対に触らせない | 本番を別アカウントに分離 | そもそも入れない＝最強かつ単純 |
| 事故の被害範囲を限定したい | マルチアカウント | blast radius を小さくする |
| 性質ごとに一括ルールをかけたい | OUで束ねる | OUは「ルールをかける箱」 |
| 本番をどこで動かす？ | メンバーアカウント（管理アカウント不可） | 管理アカウントはSCPの聖域 |
| 組織全体への強制ルール | SCP（管理アカウント以外に効く） | 中の人が外せない天井 |
7. 私がつまずいたポイント（実体験）
整理しておいて言うのも何ですが、私はマルチアカウントの意義を最初から掴めていたわけではありません。つまずきは2つでした。
- 「分離＝IAMで細かく絞る」と思い込んでいた：一番確実な分離は、IAMの作り込みではなくアカウントごと分けて入口を消すこと。発想の階層が1つ上だと気づくのに時間がかかりました。
- 管理アカウントを「最強の作業場所」だと誤解していた：実際は逆で、SCPが効かない聖域＝最も守る場所＝何も置かない。「最強だから空にする」という逆説が最初は飲み込めませんでした。
まとめ
アカウントを分ける理由は「blast radius を小さくする」の一語に尽きる。分離は最強かつ単純な権限分離（そもそも入れない）であり、性質ごとにOUで束ねてルールをかける。そして管理アカウントは聖域だからこそ本番を置かない。「被害をどこまでに閉じ込めるか」で考えれば、マルチアカウント設計で迷いません。
このマルチアカウントの整理は、私がAWS SAP合格を目指して続けている学習記録の一部です。挑戦の全体像と他のテーマは、以下のまとめページからどうぞ。