AWS OrganizationsとOU設計

1. AWS Organizationsの基本構造

AWS Organizationsは、複数のAWSアカウントを1つの組織として中央管理するサービスです。組織には1つのルートがあり、その配下へOUをネストし、メンバーアカウントをルート直下またはOUへ配置できます。

組織
└─ ルート
   ├─ メンバーアカウント
   ├─ OU
   │  ├─ メンバーアカウント
   │  └─ メンバーアカウント
   └─ OU
      └─ OU
         └─ メンバーアカウント

アカウントを単に一覧化するのではなく、同じ管理要件を持つアカウントを階層としてまとめることがOrganizations設計の中心です。

2. 管理アカウントとメンバーアカウント

管理アカウントは組織全体を管理する特権アカウントです。管理アカウントでのみ必要な管理処理へ利用し、通常のアプリケーションワークロードはメンバーアカウントへ配置するのが基本です。

組織
├─ 管理アカウント
│  └─ 組織管理に必要な処理
│
└─ メンバーアカウント（役割の例）
   ├─ 本番アカウント
   ├─ 開発アカウント
   ├─ セキュリティアカウント
   ├─ ネットワークアカウント
   └─ サンドボックスアカウント

メンバーアカウントは組織へ所属する管理アカウント以外のAWSアカウントです。実際のワークロードやセキュリティ、インフラストラクチャなどの役割をメンバーアカウントへ分離します。

3. ルートとOUはアカウントをグループ化する

ルートは組織階層の最上位コンテナです。管理アカウントそのものではありません。

組織単位（OU）は、共通する管理要件を持つメンバーアカウントを論理的にグループ化するコンテナです。OU自体がAWSリソースを所有するアカウントではありません。

4. OUはネストできる

OUの下へさらにOUを作成できます。例えばワークロード全体に共通する管理要件と、本番固有の管理要件を階層で表現できます。

ルート
└─ ワークロードOU
   ├─ 本番OU
   │  ├─ 決済本番アカウント
   │  └─ 注文本番アカウント
   └─ SDLC OU
      ├─ 開発アカウント
      └─ テストアカウント

現在 AWS Organizationsでは、OUはルート配下で最大5階層までネストできます。ただし上限まで使うことが目的ではありません。

5. OUは機能・役割 / 共通制御で設計する

OU設計の基準は「同じ部門か」ではなく、同じ機能・役割や共通する制御要件を持つかです。

例えば、次のようなグループ化が候補になります。

この名前を暗記するのではなく、アカウント群に必要な制御プロファイルからグループ化を導きます。

6. 会社の組織図をそのままOUにしない

部門やレポートラインは、組織変更や名称変更で変わりやすい要素です。OUを人事上の組織図へ強く結び付けると、組織変更のたびにクラウドガバナンス構造まで再編することになります。

頻繁に変わるもの
部門 / チーム / レポートライン

比較的安定するもの
セキュリティ機能 / インフラストラクチャ / 本番 / SDLC / サンドボックス

長く維持される機能・役割や制御要件を階層の基準にします。

7. 必要以上に深い階層を作らない

5階層まで作成できても、各レベルに異なる制御境界がなければ深くする意味はありません。

階層レベル
↓
そのレベルで共通する制御範囲がある？
↓
はい → レベルを設ける候補
いいえ → 不要な階層を増やさない

部門 → リージョン → オフィス → チームのような見た目を再現するのではなく、意味のある制御境界だけを階層へ表現します。

8. アカウントごとにOUを作らない

OUはアカウント名を整理するフォルダーではありません。同じ制御要件を持つアカウントなら、同じOUへグループ化することで共通制御の範囲を表現できます。

非効率な例
決済OU → 決済アカウント
注文OU   → 注文アカウント
在庫OU → 在庫アカウント

共通制御が同じ場合
本番OU
├─ 決済アカウント
├─ 注文アカウント
└─ 在庫アカウント

アカウント数ではなく、異なる制御境界が必要かどうかでOUを分けます。

9. アカウントはルート / OU間を移動できる

メンバーアカウントはルートからOU、OUから別OU、OUからルートへ移動できます。

重要なのは、アカウントの階層上の位置が変わると、そのアカウントを範囲に含むOrganizationsポリシーも変わり得ることです。

移動前
ルート
└─ SDLC OU
   └─ アカウント A

移動
↓

移動後
ルート
└─ 本番OU
   └─ アカウント A

親チェーンが変化
↓
組織全体の制御の範囲も変わり得る

アカウントを移動するときは、移動先のOUとその上位階層のチェーンが持つ制御範囲を確認します。

10. アカウント構造の判断例

次のアカウントを整理するとします。

セキュリティツール群
ログアーカイブ
ネットワーク
共有サービス
決済 本番
注文本番
決済開発
注文テスト
開発者サンドボックス

1つの設計例は次です。

ルート
├─ セキュリティOU
│  ├─ セキュリティツール群
│  └─ ログアーカイブ
├─ インフラストラクチャOU
│  ├─ ネットワーク
│  └─ 共有サービス
├─ ワークロードOU
│  ├─ 本番OU
│  │  ├─ 決済 本番
│  │  └─ 注文本番
│  └─ SDLC OU
│     ├─ 決済開発
│     └─ 注文テスト
└─ サンドボックスOU
   └─ 開発者サンドボックス

このツリー自体を暗記するのではなく、どのアカウント群が同じ機能・役割、ライフサイクル、制御要件を持つかから構造を決めます。

11. 障害モード

管理アカウントへ通常ワークロードを配置する

組織全体を管理する特権アカウントへアプリケーションリスクを持ち込まず、通常ワークロードはメンバーアカウントへ配置します。

全アカウントをルート直下へ並べる

アカウント数が増えると共通制御単位のグループ化が見えにくくなります。共通要件があるアカウントはOUでグループ化します。

会社の組織図をそのまま階層にする

レポートラインではなく、安定した機能・役割 / 制御要件を基準にします。

利用可能な5階層をすべて使う

各レベルに意味のある制御境界がある場合だけ階層を深くします。

アカウントごとに専用OUを作る

OUの目的は共通制御を持つアカウントをグループ化することです。アカウント数そのものをグループ化基準にしません。

12. 混同ポイント

13. SAP-C02判断フロー

メンバーアカウント
      │
      ▼
各アカウントの機能・役割 / ライフサイクルは？
      │
      ▼
共通する制御要件は？
      │
 ┌────┴────┐
 │         │
同じ異なる
 │         │
 ▼         ▼
同じOU   別OUを評価
      │
      ▼
上位でも共通制御がある？
      │
      ▼
必要ならネストされたOU
      │
      ▼
各階層レベルに意味がある？
      │
      ▼
アカウント構造確定

「何個OUを作るか」ではなく、「どのアカウント群へ同じ制御範囲を与えるか」から設計します。

14. まとめ

組織
└─ ルート
   └─ OU
      └─ メンバーアカウント

管理アカウントは組織全体を管理する特権アカウントで、通常ワークロードはメンバーアカウントへ配置します。

OUは、アカウント数や部門名ではなく、機能・役割、ライフサイクル、共通制御要件でグループ化します。

現在 AWS OrganizationsではOUをルート配下へ最大5階層までネストできますが、意味のある制御境界以上に深くする必要はありません。

最も重要なのは、アカウントをどこへ置けば共通する管理要件を安定して表現できるかを判断することです。

15. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) 試験ガイド — ドメイン 1 / タスク 1.4
• AWS Organizations — 組織の管理
• AWS Organizations — 管理アカウントのベストプラクティス
• AWS Organizations — 組織単位（OU）の管理
• AWS Organizations — OUのベストプラクティス
• AWS Organizations — クォータ