1つの AWS アカウントで始めたシステムが育ち、チームが増え、本番と開発が同居し、誰が何に触れるのか分からなくなる。請求は1枚で、どのプロジェクトがいくら使っているか分からない。開発の誤操作が本番のデータに届く。ここまで来ると、IAM のポリシーをいくら丁寧に書いても整理がつきません。境界が足りないからです。この記事は、AWS アカウントそのものを「境界」として使い、AWS Organizations と SCP で組織のガードレールを引く設計を、IAM とは何かとトレードオフの考え方の上に置きます。
この記事の結論
- AWS アカウントは、権限・請求・障害（クォータと誤操作）の境界です。1アカウントの中で IAM だけで分けようとすると、境界が足りずに整理がつきません。
- 分ける単位の基本は「環境（本番／非本番）× ワークロード」。それに、ログ・セキュリティ・ネットワークのような共有の役割を持つアカウントを足します。
- AWS Organizations でアカウントを束ね、OU（組織単位）で分類し、SCP で「このアカウント群では、誰であってもこれはできない」というガードレールを引きます。
- SCP は権限を与えません。上限を決めるだけで、実際の権限は各アカウントの IAM で与えます。この非対称を理解していないと、「SCP を付けたのに何もできるようにならない」で詰まります。
- 新しく組織の環境を作るなら Control Tower から始め、ランディングゾーン（アカウントの雛形・ログの集約・ガードレール）を AWS の推奨の形で用意します。
1アカウントで足りなくなる理由: 境界が足りない
AWS アカウントは、単なる「ログインの単位」ではありません。3つの境界を兼ねています。
| 境界 | 何が分かれるか | 1アカウントで起きる問題 |
|---|---|---|
| 権限の境界 | IAM の評価はアカウントの中で閉じる。別アカウントのリソースは、明示的に許可しない限り触れない | 開発者の権限が本番のリソースに届く。ポリシーの Resource で絞り続けるのは限界がある |
| 請求の境界 | 利用料はアカウントごとに集計される | どのプロジェクト・環境がいくら使っているかが、タグ頼みになる |
| 障害の境界 | サービスのクォータ（上限）はアカウント単位。誤操作の影響範囲もアカウントの中 | 開発の負荷試験が本番のクォータを食う。誤って全削除したとき、本番も巻き込む |
IAM で分けようとすると、「本番のリソースには触れないが、開発のリソースには触れる」を Resource の ARN と Condition で書き続けることになり、リソースが増えるたびにポリシーが伸びます。アカウントを分ければ、境界はポリシーではなく構造で担保されます。これが、マルチアカウントが「複雑になる」のではなく「単純になる」理由です。
THREE BOUNDARIESアカウントは境界
ログインの単位に見えて、3つの境界を兼ねている
アカウントが兼ねる境界:
- 権限の境界（IAM の評価が閉じる）
- 請求の境界（利用料の集計）
- 障害の境界（クォータと誤操作の影響範囲）
境界はポリシーではなく、構造で担保する
分ける単位: 環境 × ワークロード ＋ 共有の役割
GUARDRAILSアカウントを境界にする
束ねて、分類して、ガードレールを引く
-
管理
管理アカウント — Organizations の根。請求をまとめる
ワークロードを置かず、日常の作業もしない
-
共有
ログ集約・セキュリティ・ネットワークのアカウント
全アカウントから CloudTrail・Config を集める
-
OU
本番と非本番の OU に、ワークロードのアカウントを置く
同じ統制を適用したい単位で切る
-
SCP
OU ごとに「誰であってもできないこと」を Deny で書く
リージョンの限定・CloudTrail の無効化禁止・ルートの禁止
AWS のホワイトペーパー「AWS 環境を複数のアカウントで整理する」は、分け方の基本を示しています。
アカウントの分け方の基本
- 管理アカウント — Organizations の根。請求をまとめる。ここにはワークロードを置かず、日常の作業もしない
- 共有の役割のアカウント — ログの集約（CloudTrail・Config のログを全アカウントから集める）、セキュリティ（GuardDuty・Security Hub の管理）、ネットワーク（Transit Gateway・Direct Connect の共有）
- ワークロードのアカウント — 「本番」と「非本番（開発・検証）」に分け、その中でワークロード（サービス）ごとに分ける
- サンドボックス — 個人が自由に試す場所。本番のネットワークとつながず、予算の上限で自動停止する
分ける粒度は、「独立して権限・請求・障害を切りたい単位」で決めます。小さい組織なら「本番」「非本番」「ログ」「セキュリティ」の4つから始め、ワークロードが増えたら本番と非本番の中を分けていきます。最初から細かく分けると、アカウントの数が管理の負担になります。これもトレードオフで、「境界の明確さ」と「管理するアカウントの数」の天秤です。
HOW FINE TO SPLIT分ける粒度の天秤
細かく分けるほど境界は明確になり、管理の手間が増える
境界の明確さ
- 権限が構造で分かれる
- 請求がアカウントごとに出る
- 誤操作が隣に広がらない
管理するアカウントの数
- アカウントごとの初期設定
- ログと権限の配線
- 把握しておく範囲
支点は「独立して権限・請求・障害を切りたい単位」
CHECK 1ここまでの確認
1つのアカウントで本番と開発が同居しているとき、足りないものはどれ?
答えと解説
答え: 2. 境界（権限・請求・障害）
アカウントは権限・請求・障害の境界を兼ねています。IAM だけで分けようとするとポリシーが伸び続け、境界は構造ではなくポリシー頼みになります。
Organizations と OU: 束ねて、分類する
AWS Organizationsは、複数のアカウントを1つの組織として束ねるサービスです。管理アカウントが根になり、その下にOU（Organizational Unit）というフォルダを作り、アカウントを分類します。
OU の切り方は、「同じ統制を適用したい単位」で決めます。環境（本番／非本番）で切るのが基本で、SCP は OU に付けるからです。
Root
├── Security OU … ログ集約、セキュリティ管理
├── Infrastructure OU … ネットワーク共有
├── Workloads OU
│ ├── Prod OU … 本番のワークロード
│ └── NonProd OU … 開発・検証
└── Sandbox OU … 個人の検証
OU は入れ子にでき、上位の OU に付けた SCP は下位のアカウントすべてに効きます。「Root に付けた SCP は全アカウントに効く」ので、Root にはごく基本のものだけを置きます。
Organizations には、請求の一括管理（全アカウントの利用料をまとめて払い、ボリュームディスカウントを共有する）と、サービスの信頼されたアクセス（CloudTrail や Config を組織全体で有効にする）の機能もあります。
SCP は「上限」であって「権限」ではない
SCP（Service Control Policy）は、Organizations の機能で、OU やアカウントに付けるポリシーです。形は IAM のポリシーと同じ JSON ですが、役割が違います。
| 項目 | IAM ポリシー | SCP |
|---|---|---|
| 何を決めるか | 誰が何をしてよいか（権限を与える） | このアカウントでできることの上限（権限を与えない） |
| 付ける先 | ユーザー・グループ・ロール | OU・アカウント |
| 誰に効くか | 付けた相手だけ | そのアカウントの全員（ルートユーザーも含む） |
| 管理アカウントに効くか | 効く | 効かない |
SCP は権限を与えません。SCP で Allow を書いても、その操作ができるようになるわけではなく、「その操作は上限の範囲内」という意味しかありません。実際にできるかどうかは、各アカウントの IAM で Allow があるかで決まります。IAM とは何かの評価の順番に、SCP は「さらに上から絞る層」として重なります。
SCP VS IAM上限か、権限か
SCP は上限を決め、IAM が権限を与える
IAM ポリシー
誰が何をしてよいか（権限を与える）
- 付ける先はユーザー・グループ・ロール
- 付けた相手だけに効く
- 管理アカウントにも効く
SCP
このアカウントでできることの上限（権限を与えない）
- 付ける先は OU・アカウント
- そのアカウントの全員に効く（ルートユーザーも）
- 管理アカウントには効かない
- 「やってはいけないこと」を Deny で書くのに向く
だから SCP は、「やってはいけないこと」を Deny で書くのに向いています。
- 使ってよいリージョンを限定する（東京と大阪以外を
Deny） - CloudTrail のログを無効化できないようにする
- ルートユーザーの操作を禁止する
- 本番 OU では、特定の破壊的操作（組織からの離脱、暗号鍵の削除）を禁止する
これらは「誰であっても」効くので、IAM で誤って強い権限を付けてしまっても、組織の境界を越えません。これがガードレールです。道路の縁の柵のように、越えられない線を引き、線の内側では自由に走らせます。
CHECK 2ここまでの確認
SCP で「s3:*」を Allow した。そのアカウントの IAM ユーザーは S3 を操作できる?
答えと解説
答え: 2. IAM で Allow が無ければできない（SCP は上限を決めるだけ）
SCP は権限を与えません。上限を決めるだけで、実際にできるかどうかは各アカウントの IAM で Allow があるかで決まります。
Control Tower とランディングゾーン
ここまでの構造（Organizations・OU・共有の役割のアカウント・ログの集約・SCP）を、AWS の推奨の形で最初にまとめて用意したものをランディングゾーンと呼びます。AWS Control Towerは、このランディングゾーンを自動で作り、新しいアカウントを雛形（Account Factory）から発行し、ガードレール（SCP と Config ルール）を OU 単位で有効にするサービスです。
Control Tower を使う判断は、トレードオフで言えば「マネージドと自由度」の天秤です。
- 使う理由: 設計の抜け（ログの集約を忘れる、SCP の書き間違い）が減る。新しいアカウントの発行が型になる。
- 捨てるもの: Control Tower が管理する OU と SCP の構造に、ある程度従う必要がある。既存の Organizations に後から入れるときは移行の手順が要る。
- 見直す条件: Control Tower の型に合わない統制が必要になったとき（そのときも、Control Tower の上に追加の SCP を重ねる形で対応できることが多い）。
新しく組織の環境を作るなら、執筆者は Control Tower から始めることを勧めます。自分で組む知識は要りますが、それは「Control Tower が何を作っているかを読める」ために要るのであって、「自分でゼロから組む」ためではありません。
CHECK 3ここまでの確認
新しく組織の AWS 環境を作るとき、この記事の執筆者が勧めた始め方はどれ?
答えと解説
答え: 2. Control Tower でランディングゾーンを用意し、必要に応じて手を入れる
Control Tower は Organizations・ログ集約・ガードレールを AWS の推奨の形でまとめて用意します。管理アカウントにはワークロードを置きません。
まとめ
AWS アカウントは権限・請求・障害の境界で、1アカウントの中で IAM だけで分けようとすると境界が足りません。環境 × ワークロードに共有の役割のアカウントを足して分け、Organizations で束ね、OU で分類し、SCP で「誰であってもできないこと」のガードレールを引きます。SCP は上限であって権限ではなく、権限は各アカウントの IAM で与えます。新しく作るなら Control Tower でランディングゾーンを用意します。分けたあとに「各アカウントで何を見るか」は、監視設計を組織の単位に広げて考えます。
参照ソース
- AWS Organizations とは（AWS Organizations ユーザーガイド） — 管理アカウント・OU・一括請求・信頼されたアクセスの根拠。2026年9月時点の記載
- サービスコントロールポリシー（SCP）（AWS Organizations ユーザーガイド） — SCP が権限を与えず上限を決めること、管理アカウントには効かないこと、OU に付けると配下の全アカウントに効くことの根拠
- AWS 環境を複数のアカウントで整理する（AWS ホワイトペーパー） — アカウントを分ける単位（環境・ワークロード・共有の役割）と OU の推奨構造の一次情報
- AWS Control Tower とは（AWS Control Tower ユーザーガイド） — ランディングゾーン・Account Factory・ガードレールの定義の根拠
- ポリシーの評価論理（AWS IAM ユーザーガイド） — SCP が IAM の評価にどう重なるかの根拠
