AWS Organizationsの基礎と組織構造の設計

AWSを本番環境で利用する組織では、単一アカウントでの運用に限界を感じることが多くなります。開発環境と本番環境の分離、プロジェクトごとの予算管理、セキュリティ境界の確立など、複数アカウントへの移行は避けられない課題です。本記事では、AWS Organizationsの基礎知識から組織構造の設計パターン、一括請求のメリットまでを体系的に解説します。

AWS Organizationsとは

AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。組織を作成し、アカウントを階層構造で整理することで、ガバナンス、セキュリティ、請求の管理を効率化します。

AWS Organizationsの主要機能

AWS Organizationsは以下の機能を提供します。

mindmap
  root((AWS Organizations))
    アカウント管理
      新規アカウント作成
      既存アカウントの招待
      アカウントの削除・離脱
    組織構造
      組織単位（OU）の作成
      階層構造の管理
      アカウントの移動
    ポリシー管理
      サービスコントロールポリシー（SCP）
      タグポリシー
      バックアップポリシー
      AIサービスオプトアウトポリシー
    一括請求
      コスト集約
      ボリュームディスカウント
      Reserved Instance共有

機能カテゴリ	説明
アカウント管理	新規アカウントの作成、既存アカウントの招待と離脱の管理
組織構造	組織単位（OU）による階層的なアカウント整理
ポリシー管理	SCPによるアカウント権限の制限、タグポリシーによる命名規則の強制
一括請求	すべてのアカウントの請求を統合し、コストの可視化と最適化を実現

Organizations を使用する理由

単一のAWSアカウントですべてのワークロードを運用する場合、以下の課題が発生します。

flowchart TB
    subgraph "単一アカウントの課題"
        direction TB
        P1[セキュリティ境界の欠如]
        P2[コスト配分の困難]
        P3[IAM権限の複雑化]
        P4[監査対応の煩雑さ]
        P5[障害影響範囲の拡大]
    end
    
    subgraph "Organizations による解決"
        direction TB
        S1[アカウント分離による<br/>セキュリティ強化]
        S2[アカウント単位での<br/>コスト管理]
        S3[アカウントごとの<br/>シンプルなIAM設計]
        S4[ログ・監査の<br/>一元管理]
        S5[障害の<br/>影響範囲を限定]
    end
    
    P1 --> S1
    P2 --> S2
    P3 --> S3
    P4 --> S4
    P5 --> S5

AWS Organizationsを活用したマルチアカウント戦略により、これらの課題を解決できます。

アカウントの種類と役割

AWS Organizationsでは、アカウントは「管理アカウント」と「メンバーアカウント」の2種類に分類されます。それぞれの役割と特徴を理解することが、適切な組織設計の第一歩です。

管理アカウント（Management Account）

管理アカウントは、組織を作成したアカウントであり、組織全体の管理権限を持つ特別なアカウントです。

flowchart TB
    MA[管理アカウント<br/>Management Account]
    
    subgraph "管理アカウントの責務"
        R1[組織の作成・削除]
        R2[アカウントの招待・作成]
        R3[OU構造の管理]
        R4[ポリシーの適用]
        R5[一括請求の管理]
    end
    
    MA --> R1
    MA --> R2
    MA --> R3
    MA --> R4
    MA --> R5

管理アカウントの特徴は以下の通りです。

特徴	説明
組織の唯一のオーナー	組織内に管理アカウントは1つのみ存在
SCPの適用対象外	管理アカウント自体にはSCPが適用されない
請求情報へのアクセス	すべてのメンバーアカウントの請求情報を参照可能
組織全体の設定変更	組織の機能有効化、ポリシータイプの有効化を実行可能

管理アカウントのベストプラクティス

管理アカウントは組織全体に影響を及ぼす重要なアカウントです。以下のベストプラクティスに従うことを推奨します。

ワークロードを配置しない（管理目的のみに使用）
ルートユーザーに強力なMFAを設定
アクセス権限を最小限のユーザーに制限
CloudTrailで全操作を記録

メンバーアカウント（Member Account）

メンバーアカウントは、組織に所属するアカウントで、実際のワークロードを実行するために使用されます。

flowchart TB
    subgraph "組織構造"
        MA[管理アカウント]
        
        subgraph "メンバーアカウント"
            M1[本番アカウント]
            M2[開発アカウント]
            M3[セキュリティアカウント]
            M4[ログアカウント]
        end
    end
    
    MA --> M1
    MA --> M2
    MA --> M3
    MA --> M4

メンバーアカウントの特徴は以下の通りです。

特徴	説明
OU所属	1つの組織単位（OU）に所属（ルートOUを含む）
SCP適用	所属するOUと自身に適用されたSCPの制約を受ける
独立したリソース	他のアカウントとリソースは分離される
請求の統合	請求は管理アカウントに集約される

管理アカウントとメンバーアカウントの比較

両者の違いを以下の表にまとめます。

比較項目	管理アカウント	メンバーアカウント
組織内の数	1つのみ	複数作成可能
SCP適用	適用されない	適用される
組織の管理操作	可能	不可（委任された場合のみ一部可能）
ワークロード配置	非推奨	推奨
組織からの離脱	組織の削除が必要	離脱可能
請求責任	すべてのアカウントの請求を負担	請求は管理アカウントに集約

組織単位（OU）の概念と設計

組織単位（Organizational Unit、OU）は、アカウントをグループ化するためのコンテナです。OUを使用することで、アカウントを論理的に整理し、ポリシーを効率的に適用できます。

OUの基本概念

OUは階層構造を形成できます。組織を作成すると、自動的に「ルート」が作成され、すべてのOUとアカウントはこのルートの下に配置されます。

flowchart TB
    ROOT[Root<br/>ルート]
    
    subgraph "OU階層"
        OU1[Security OU]
        OU2[Infrastructure OU]
        OU3[Workloads OU]
        
        subgraph "Workloads配下"
            OU3A[Production OU]
            OU3B[Development OU]
        end
    end
    
    ROOT --> OU1
    ROOT --> OU2
    ROOT --> OU3
    OU3 --> OU3A
    OU3 --> OU3B
    
    A1[セキュリティアカウント]
    A2[ログアカウント]
    A3[ネットワークアカウント]
    A4[本番アカウント A]
    A5[本番アカウント B]
    A6[開発アカウント]
    
    OU1 --> A1
    OU1 --> A2
    OU2 --> A3
    OU3A --> A4
    OU3A --> A5
    OU3B --> A6

OUの特徴を以下にまとめます。

特徴	説明
階層構造	OUの中にOUをネストできる（最大5階層）
ポリシー継承	親OUのポリシーは子OUとアカウントに継承される
単一所属	アカウントは同時に1つのOUにのみ所属できる
柔軟な移動	アカウントはOU間で移動可能

OU設計の基本原則

効果的なOU設計には、以下の原則を考慮します。

1. セキュリティ要件に基づく分類

セキュリティ要件が異なるアカウントは、別のOUに配置します。これにより、適切なSCPを適用できます。

2. ポリシー適用の効率性

同じポリシーを適用するアカウントは、同じOUにグループ化します。個別にポリシーを適用する手間を省けます。

3. 運用チームの境界に沿った設計

運用チームが異なる場合は、チームの責任範囲に合わせてOUを分けることで、管理が明確になります。

4. 過度な階層化を避ける

階層が深すぎると管理が複雑になります。必要最小限の階層に留めることを推奨します。

推奨OU構造パターン

AWSが推奨するOU構造パターンを紹介します。

flowchart TB
    ROOT[Root]
    
    subgraph "基盤OU"
        SEC[Security OU<br/>セキュリティ監視・監査]
        INFRA[Infrastructure OU<br/>共有ネットワーク・DNS]
    end
    
    subgraph "ワークロードOU"
        SANDBOX[Sandbox OU<br/>実験・学習用]
        WORKLOAD[Workloads OU<br/>ビジネスワークロード]
    end
    
    subgraph "ポリシーステージングOU"
        POLICY[Policy Staging OU<br/>ポリシーテスト用]
    end
    
    subgraph "例外OU"
        SUSPEND[Suspended OU<br/>一時停止アカウント]
        EXCEPT[Exceptions OU<br/>特別な要件のアカウント]
    end
    
    ROOT --> SEC
    ROOT --> INFRA
    ROOT --> SANDBOX
    ROOT --> WORKLOAD
    ROOT --> POLICY
    ROOT --> SUSPEND
    ROOT --> EXCEPT
    
    subgraph "Workloads配下"
        PROD[Production OU]
        DEV[Development OU]
        TEST[Test OU]
    end
    
    WORKLOAD --> PROD
    WORKLOAD --> DEV
    WORKLOAD --> TEST

各OUの役割を説明します。

OU名	役割	配置するアカウント例
Security OU	セキュリティツールとログの一元管理	ログアーカイブ、セキュリティツール、監査
Infrastructure OU	組織全体で共有するインフラ	ネットワーク、共有サービス、バックアップ
Sandbox OU	学習・実験用の隔離環境	開発者の個人検証用アカウント
Workloads OU	ビジネスアプリケーション	本番、開発、テスト環境
Policy Staging OU	新しいSCPのテスト	ポリシーテスト専用アカウント
Suspended OU	一時的に停止したアカウント	利用停止中のプロジェクトアカウント
Exceptions OU	標準SCPから除外が必要なアカウント	特殊要件のあるアカウント

OU設計のアンチパターン

避けるべきOU設計のパターンを紹介します。

アンチパターン1: チーム名でのOU作成

flowchart TB
    ROOT[Root]
    TEAM1[チームA OU]
    TEAM2[チームB OU]
    TEAM3[チームC OU]
    
    ROOT --> TEAM1
    ROOT --> TEAM2
    ROOT --> TEAM3

チーム名でOUを作成すると、組織変更のたびにOU構造を変更する必要が生じます。機能やセキュリティ要件に基づいた設計が望ましいです。

アンチパターン2: 過度に深い階層

5階層を超える深いネストは、ポリシーの継承が複雑になり、管理が困難になります。3階層程度に抑えることを推奨します。

アンチパターン3: 単一アカウント用のOU

1つのアカウントだけを含むOUを多数作成すると、OUの意味が薄れます。ただし、将来の拡張を見越した場合は許容されます。

一括請求（Consolidated Billing）

AWS Organizationsの重要な機能の1つが、一括請求（Consolidated Billing）です。すべてのメンバーアカウントの料金を管理アカウントで一括管理できます。

一括請求の仕組み

一括請求を有効にすると、すべてのメンバーアカウントの使用料金が管理アカウントに集約されます。

flowchart TB
    subgraph "組織"
        MA[管理アカウント<br/>請求をまとめて支払い]
        M1[メンバーアカウント1<br/>使用料: $500]
        M2[メンバーアカウント2<br/>使用料: $300]
        M3[メンバーアカウント3<br/>使用料: $200]
    end
    
    M1 --> |請求データ| MA
    M2 --> |請求データ| MA
    M3 --> |請求データ| MA
    
    MA --> |合計 $1,000| BILL[AWS請求書]

一括請求のメリット

一括請求には以下のメリットがあります。

1. ボリュームディスカウントの適用

組織全体の使用量を合算することで、より高いボリュームディスカウントが適用されます。

flowchart LR
    subgraph "個別請求の場合"
        A1[アカウント1<br/>S3: 50TB<br/>単価: $0.023]
        A2[アカウント2<br/>S3: 30TB<br/>単価: $0.023]
        A3[アカウント3<br/>S3: 20TB<br/>単価: $0.023]
    end
    
    subgraph "一括請求の場合"
        TOTAL[合計: 100TB]
        TIER1[最初の50TB<br/>$0.023/GB]
        TIER2[次の50TB<br/>$0.022/GB]
    end
    
    A1 --> TOTAL
    A2 --> TOTAL
    A3 --> TOTAL
    TOTAL --> TIER1
    TOTAL --> TIER2

S3の例では、使用量が増えると段階的に単価が下がります。組織全体で合算されるため、より安い料金帯が適用されやすくなります。

2. Reserved InstancesとSavings Plansの共有

あるアカウントで購入したReserved InstancesやSavings Plansを、組織内の他のアカウントと共有できます。

flowchart TB
    subgraph "RI共有の例"
        A1[アカウント1<br/>RI購入: m5.large x 5]
        A2[アカウント2<br/>m5.large x 3 稼働]
        A3[アカウント3<br/>m5.large x 2 稼働]
    end
    
    A1 --> |RI 3台分適用| A2
    A1 --> |RI 2台分適用| A3

この機能により、RIの稼働率を最大化し、コストを最適化できます。

3. 請求管理の簡素化

複数のAWSアカウントを運用していても、請求書は1つに集約されます。経理処理が簡素化され、管理コストを削減できます。

4. コスト配分の可視化

コスト配分タグを使用することで、組織全体のコストをプロジェクト、部門、環境などの軸で可視化できます。

一括請求の設定と注意点

一括請求は、AWS Organizationsの「すべての機能」または「一括請求機能」のいずれかを有効にすると利用できます。

設定項目	すべての機能	一括請求機能のみ
一括請求	利用可能	利用可能
SCP	利用可能	利用不可
その他のポリシー	利用可能	利用不可
推奨	はい	特殊な要件がある場合のみ

注意点

管理アカウントは、すべてのメンバーアカウントの請求情報にアクセスできます
メンバーアカウントは、自身の請求情報のみ参照可能（デフォルト設定）
RI/Savings Plansの共有は無効化することも可能（アカウント単位）
組織からアカウントが離脱すると、そのアカウントの請求は分離されます

コスト配分タグの活用

コスト配分タグを使用することで、組織全体のコストを詳細に分析できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
  "ResourceType": "AWS::EC2::Instance",
  "Tags": [
    {
      "Key": "Project",
      "Value": "WebApp"
    },
    {
      "Key": "Environment",
      "Value": "Production"
    },
    {
      "Key": "CostCenter",
      "Value": "IT-001"
    }
  ]
}

推奨するコスト配分タグの例を以下に示します。

タグキー	説明	値の例
Project	プロジェクト名	WebApp, DataPlatform
Environment	環境	Production, Development, Test
CostCenter	コストセンター	IT-001, SALES-002
Owner	責任者	team-a, john.doe
Application	アプリケーション名	API-Server, Database

タグポリシーを使用することで、これらのタグの命名規則を組織全体で強制できます。

Organizationsの機能セット

AWS Organizationsには2つの機能セットがあります。

すべての機能（All Features）

推奨される機能セットで、以下の機能を利用できます。

一括請求
サービスコントロールポリシー（SCP）
タグポリシー
バックアップポリシー
AIサービスオプトアウトポリシー
AWSサービスとの統合（IAM Identity Center、CloudTrail、Config等）

一括請求機能のみ（Consolidated Billing Only）

請求の統合のみを目的とする場合に使用します。SCPなどのガバナンス機能は利用できません。

flowchart TB
    subgraph "すべての機能"
        ALL_BILL[一括請求]
        ALL_SCP[SCP]
        ALL_TAG[タグポリシー]
        ALL_BACKUP[バックアップポリシー]
        ALL_INT[サービス統合]
    end
    
    subgraph "一括請求機能のみ"
        CB_BILL[一括請求]
        CB_NO[その他の機能なし]
    end

ほとんどの組織では「すべての機能」を選択することを推奨します。後から機能セットを変更することも可能ですが、すべてのメンバーアカウントの承認が必要になります。

Organizationsの作成と基本操作

AWS Organizationsを作成し、基本的な操作を行う手順を解説します。

組織の作成

AWSマネジメントコンソールにサインイン
AWS Organizationsサービスに移動
「組織を作成」をクリック
機能セット（すべての機能を推奨）を選択
作成を確認

組織を作成したアカウントが自動的に管理アカウントになります。

メンバーアカウントの追加

メンバーアカウントを追加するには、2つの方法があります。

方法1: 新規アカウントの作成

sequenceDiagram
    participant Admin as 管理者
    participant Org as Organizations
    participant NewAcc as 新規アカウント
    
    Admin->>Org: CreateAccount API
    Org->>NewAcc: アカウント作成
    Org->>NewAcc: 組織に自動参加
    Org-->>Admin: 作成完了通知

新規作成されたアカウントは、自動的に組織のルートに配置されます。

方法2: 既存アカウントの招待

sequenceDiagram
    participant Admin as 管理者
    participant Org as Organizations
    participant Existing as 既存アカウント
    
    Admin->>Org: InviteAccountToOrganization
    Org->>Existing: 招待メール送信
    Existing->>Org: 招待を承諾
    Org-->>Admin: 参加完了通知

既存アカウントを招待する場合、そのアカウントの所有者が招待を承諾する必要があります。

OUの作成とアカウントの配置

OUを作成し、アカウントを配置する手順は以下の通りです。

Organizations コンソールで「組織を整理」を選択
「新しい組織単位」をクリック
OU名を入力して作成
アカウントを選択し、「移動」で作成したOUに配置

AWS CLIでの操作例

AWS CLIを使用した基本的な操作例を示します。

組織情報の取得

1

aws organizations describe-organization

OUの一覧表示

1
2


aws organizations list-organizational-units-for-parent \
  --parent-id r-xxxx

新規アカウントの作成

1
2
3


aws organizations create-account \
  --email new-account@example.com \
  --account-name "New Member Account"

アカウントのOU間移動

1
2
3
4


aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id ou-xxxx-xxxxxxxx \
  --destination-parent-id ou-yyyy-yyyyyyyy

組織設計のベストプラクティス

効果的な組織設計のためのベストプラクティスをまとめます。

管理アカウントの保護

管理アカウントは組織全体に影響を与えるため、厳重に保護する必要があります。

対策	説明
ワークロードを配置しない	管理目的のみに使用
ルートユーザーの保護	強力なMFA、アクセスキーの削除
アクセス制限	必要最小限のユーザーのみにアクセス権を付与
CloudTrail有効化	すべての操作を記録
アラート設定	重要な操作の通知を設定

段階的な移行計画

既存の単一アカウント環境からマルチアカウントへ移行する場合は、段階的に進めることを推奨します。

flowchart LR
    S1[Phase 1<br/>組織作成<br/>OU設計] --> S2[Phase 2<br/>セキュリティ<br/>アカウント分離]
    S2 --> S3[Phase 3<br/>ワークロード<br/>移行]
    S3 --> S4[Phase 4<br/>ポリシー<br/>適用]
    S4 --> S5[Phase 5<br/>最適化<br/>自動化]

アカウント命名規則

一貫した命名規則を採用することで、管理が容易になります。

[組織名]-[環境]-[目的]-[リージョン略称]

例:
acme-prod-webapp-apne1    # 本番環境のWebアプリ（東京）
acme-dev-shared-apne1     # 開発環境の共有サービス
acme-security-log-apne1   # セキュリティログ収集

定期的なレビュー

組織構造は、ビジネス要件の変化に合わせて定期的にレビューすることが重要です。

四半期ごとのOU構造レビュー
不要なアカウントの特定と削除
SCPの有効性確認
コスト配分の最適化

まとめ

AWS Organizationsは、マルチアカウント環境を効率的に管理するための基盤となるサービスです。本記事で解説した内容を振り返ります。

AWS Organizationsは複数アカウントの一元管理、ポリシー適用、一括請求を提供
管理アカウントは組織全体を管理する特別なアカウントで、厳重な保護が必要
**組織単位（OU）**を使用してアカウントを論理的にグループ化し、ポリシーを効率的に適用
一括請求により、ボリュームディスカウントとRI/Savings Plansの共有が可能
セキュリティ要件とポリシー適用に基づいたOU設計が重要

次の記事では、AWS Organizationsのサービスコントロールポリシー（SCP）を使用して、アカウント全体のセキュリティガードレールを設計する方法を解説します。

AWS Organizationsとは#

AWS Organizationsの主要機能#

Organizations を使用する理由#

アカウントの種類と役割#

管理アカウント（Management Account）#

メンバーアカウント（Member Account）#

管理アカウントとメンバーアカウントの比較#

組織単位（OU）の概念と設計#

OUの基本概念#

OU設計の基本原則#

推奨OU構造パターン#

OU設計のアンチパターン#

一括請求（Consolidated Billing）#

一括請求の仕組み#

一括請求のメリット#

一括請求の設定と注意点#

コスト配分タグの活用#

Organizationsの機能セット#

すべての機能（All Features）#

一括請求機能のみ（Consolidated Billing Only）#

Organizationsの作成と基本操作#

組織の作成#

メンバーアカウントの追加#

OUの作成とアカウントの配置#

AWS CLIでの操作例#

組織設計のベストプラクティス#

管理アカウントの保護#

段階的な移行計画#

アカウント命名規則#

定期的なレビュー#

まとめ#

参考リンク#