導入
アカウントが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["開発アカウント"]
管理アカウント自体には、原則としてワークロードを置きません。乗っ取られたときの被害が組織全体に及ぶため、「管理アカウントは何もしない、ただ束ねるだけ」がベストプラクティスです。
読んでみよう
SAPでは「OUをどう切るか」を問う問題が頻出します。判断基準は常に「同じガードレール（SCP）を当てたい単位かどうか」であり、組織図上の部署名や事業部名で切ってはいけません。次のレッスンで、そのOUに当てる「ガードレール」そのものであるSCPを学びます。