導入
SAP最大の特徴は、「1つのアカウントの中の設計」から「複数アカウントをまたいだ設計」へ視点が上がることです。なぜ組織はアカウントを分けるのか。その動機を先につかむと、第2章以降の統治の話が腑に落ちます。
説明
小さなシステムなら1つのAWSアカウントで十分ですが、組織が大きくなると 複数のアカウントに分割 するのが定石です。分ける理由は主に次の4つです。
| 分ける理由 | 具体例 |
|---|---|
| 分離（Blast Radius の限定） | 本番と開発を別アカウントにし、事故の影響範囲を閉じ込める |
| セキュリティ境界 | アカウント単位で権限・データを隔離する |
| 課金の分離 | 事業部・プロジェクトごとにコストを可視化・按分する |
| 制限の緩和 | サービスクォータはアカウント単位。分ければ枠が増える |
こうして増えたアカウントを、バラバラに放置すると統制が効きません。そこで AWS Organizations で全アカウントを1つの組織にまとめ、OU（組織単位） でグループ化し、SCP（サービスコントロールポリシー） で「そもそも何を許すか」の上限を一括でかけます。
flowchart TD
ROOT["管理アカウント<br/>（AWS Organizations）"] --> OU1["OU: 本番"]
ROOT --> OU2["OU: 開発"]
ROOT --> OU3["OU: セキュリティ"]
OU1 --> A1["本番アカウントA"]
OU1 --> A2["本番アカウントB"]
OU2 --> A3["開発アカウント"]
OU3 --> A4["ログ集約アカウント"]
具体例
社員500人・複数事業部のIT企業が、最初は「全部1つのAWSアカウント」で始めて破綻していく様子を追うと、分割の動機が腹落ちします。
- 事故が全社に波及した（分離） … 開発チームの実験用スクリプトが暴走し、同じアカウントにいた本番リソースまで巻き添えに。→ 本番と開発を別アカウントに分け、事故の影響範囲（Blast Radius）を閉じ込める。
- どの事業部がいくら使ったか分からない（課金） … 1アカウントに全部載っていて費用が按分できない。→ 事業部ごとにアカウントを分け、Organizationsの一括請求で部門別に可視化。
- サービス上限に頻繁に到達（制限緩和） … クォータはアカウント単位。1つに集中させると枠が足りない。→ 分ければアカウントごとに枠が増える。
- セキュリティ境界が曖昧（隔離） … 機密データと一般データが同居。→ アカウント単位で権限とデータを隔離。
こうして増えたアカウントを放置すると今度は統制が効かないので、Organizationsで束ね、OUでグループ化し、SCPで許可の上限をかける。「大きな組織はアカウントを分け、分けたら束ねて統治する」——この往復がSAPの入り口です。
読んでみよう
「1アカウント1システム」から「たくさんのアカウントを組織として束ねる」へ ―― この発想の転換がSAPの入り口です。第2章では、この Organizations・OU・SCP・Control Tower を使った マルチアカウント統治 を本格的に学びます。ここでは「大きな組織はアカウントを分ける。分けたら束ねて統治する」という骨格だけ押さえてください。