導入
アカウントが10個、100個と増えたとき、1つ1つに個別ログインして設定するのは非現実的です。AWS Organizations は、複数アカウントを1つの「組織」としてまとめ、階層的に管理するための土台です。まずはこの骨組みの作り方を押さえましょう。
説明
AWS Organizations は、複数のAWSアカウントを1つの組織単位でまとめて管理するサービスです。組織には次の要素があります。
| 要素 | 役割 |
|---|---|
| 管理アカウント（Management Account） | 組織を作った元アカウント。請求の集約元・SCPの適用元になる特権アカウント |
| メンバーアカウント | 組織に招待・作成された配下のアカウント。実際のワークロードはここで動かす |
| OU（Organizational Unit / 組織単位） | アカウントをグループ化するフォルダ。ネスト（入れ子）できる |
| ルート（Root） | 組織階層の最上位。全OU・全アカウントの親 |
OUはファイルシステムのフォルダのように考えると理解しやすい構造です。似た性質のアカウント（本番／開発／セキュリティ など）を同じOUにまとめ、OU単位でSCPやポリシーを一括適用します。設計のコツは「組織構造（部署）ではなく、統治のルール（ガードレール）が同じかどうか」でOUを分けることです。部署でOUを切ると、部署再編のたびにアカウント移動が発生してしまいます。
代表的なOU設計パターンとして、AWSは次のような分類を推奨しています。
| OU例 | 収容するアカウント | 適用したいガードレールの傾向 |
|---|---|---|
| Security OU | ログ集約・監査アカウント | 誰も削除・改変できないよう強く制限 |
| Infrastructure OU | 共有ネットワーク・DNSアカウント | ネットワーク変更を限られた人だけに |
| Workloads > Production OU | 本番ワークロードのアカウント | 本番リージョン限定・危険操作を禁止 |
| Workloads > Sandbox/Dev OU | 開発・検証アカウント | 比較的自由。コスト超過だけ厳しく監視 |
flowchart TD
ROOT["Root"] --> SEC["Security OU"]
ROOT --> INFRA["Infrastructure OU"]
ROOT --> WL["Workloads OU"]
WL --> PROD["Production OU"]
WL --> DEV["Sandbox/Dev OU"]
SEC --> A1["ログ集約アカウント"]
PROD --> A2["本番アカウントA"]
PROD --> A3["本番アカウントB"]
DEV --> A4["開発アカウント"]
管理アカウント自体には、原則としてワークロードを置きません。乗っ取られたときの被害が組織全体に及ぶため、「管理アカウントは何もしない、ただ束ねるだけ」がベストプラクティスです。
具体例
ある企業が、最初は組織図どおりに「営業部OU」「開発部OU」「マーケOU」とOUを切りました。一見わかりやすいですが、半年後に問題が起きます。
組織再編で「開発部」が「プロダクト部」に統合されました。すると、OUの付け替え・アカウント移動が発生し、それに紐づくSCPの見直しまで芋づる式に必要に。しかも各部のアカウントは、本番も開発も混在していて、同じOUに「絶対に止められない本番」と「自由に壊してよい検証」が同居——当てたいガードレールがバラバラで、SCPが書けません。
正しい切り方は「同じガードレールを当てたい単位」です。
- 本番ワークロード → Production OU（本番リージョン限定・危険操作Deny）
- 開発・検証 → Sandbox OU（自由だがコスト超過は監視）
- ログ・監査 → Security OU（誰も削除・改変できない）
これなら部署が再編されても、アカウントの「性質」は変わらないのでOU構成は安定します。SAPで「OUをどう切るか」と問われたら、組織図の部署名ではなく、SCPを当てたい単位が答えです。
読んでみよう
SAPでは「OUをどう切るか」を問う問題が頻出します。判断基準は常に「同じガードレール（SCP）を当てたい単位かどうか」であり、組織図上の部署名や事業部名で切ってはいけません。次のレッスンで、そのOUに当てる「ガードレール」そのものであるSCPを学びます。