AWS Control Towerでランディングゾーンを構築し、Account Factoryでアカウントをプロビジョニングし、ガードレールでガバナンスを確立できるようになりました。しかし、実際のエンタープライズ環境では「どのようにアカウントを分割すべきか」「OU構造はどう設計すべきか」という戦略的な意思決定が求められます。本記事では、AWSが推奨するマルチアカウント戦略とランディングゾーン設計のベストプラクティスを体系的に解説します。

マルチアカウント戦略が必要な理由

単一のAWSアカウントですべてのワークロードを運用することは技術的には可能ですが、組織の規模が拡大するにつれて多くの課題が顕在化します。マルチアカウント戦略は、これらの課題に対するAWSが推奨する解決策です。

単一アカウント運用の限界

規模の小さい組織やスタートアップでは、単一アカウントでの運用から始めることが一般的です。しかし、成長に伴い以下の問題が発生します。

flowchart TB
    subgraph "単一アカウントの課題"
        direction TB
        C1[セキュリティ境界の欠如<br/>開発者が本番環境に誤ってアクセス]
        C2[コスト配分の不透明さ<br/>プロジェクト別の費用が把握困難]
        C3[サービスクォータの共有<br/>1つのワークロードが上限を占有]
        C4[IAM権限の複雑化<br/>最小権限の維持が困難]
        C5[障害影響範囲の拡大<br/>1つの設定ミスが全体に波及]
        C6[コンプライアンス要件への対応<br/>PCI DSSなどの環境分離が困難]
    end
課題 具体例 ビジネスへの影響
セキュリティ境界の欠如 開発者が本番RDSに誤接続 データ漏洩、サービス停止
コスト配分の不透明さ EC2費用がどのプロジェクトか不明 予算管理の失敗、責任の不明確化
サービスクォータ共有 バッチ処理がLambda同時実行数を占有 他サービスの機能停止
IAM権限の複雑化 条件キーを多用した複雑なポリシー 設定ミス、監査の困難
障害影響範囲 VPC設定変更で全環境が停止 事業継続性の危機
コンプライアンス PCI DSSスコープの肥大化 監査コストの増大、認証取得の遅延

マルチアカウント戦略のメリット

複数のAWSアカウントに分割することで、これらの課題を解決できます。

flowchart LR
    subgraph "マルチアカウントのメリット"
        direction TB
        M1[強力なセキュリティ境界<br/>アカウント=最強の分離単位]
        M2[明確なコスト配分<br/>アカウント単位で自動集計]
        M3[独立したクォータ<br/>アカウントごとに上限設定]
        M4[シンプルなIAM設計<br/>アカウント内の権限のみ考慮]
        M5[障害の局所化<br/>影響範囲を限定]
        M6[コンプライアンス対応<br/>スコープの明確化]
    end

AWSアカウントは最も強力な分離境界

AWSにおいて、アカウントはリソースを分離する最も強力な境界です。VPC、セキュリティグループ、IAMポリシーによる分離も有効ですが、設定ミスによるリスクが存在します。一方、アカウント分離では、明示的なクロスアカウントアクセス設定がない限り、他のアカウントのリソースにはアクセスできません。

flowchart TB
    subgraph "分離の強度比較"
        direction LR
        subgraph "弱い分離"
            SG[セキュリティグループ]
            NS[名前空間/タグ]
        end
        subgraph "中程度の分離"
            VPC[VPC分離]
            IAM[IAMポリシー]
        end
        subgraph "最も強い分離"
            ACCT[アカウント分離]
        end
    end
    
    SG --> VPC --> ACCT

ランディングゾーンの概念

ランディングゾーンとは、組織がAWS上でワークロードを安全かつ効率的に運用するための、事前構成されたマルチアカウント環境です。AWS Control Towerはこのランディングゾーンを自動的に構築・管理するサービスです。

ランディングゾーンの構成要素

Control Towerが構築するランディングゾーンは、以下の要素で構成されます。

flowchart TB
    subgraph "ランディングゾーン"
        subgraph "管理層"
            MGMT[管理アカウント<br/>Organizations/Control Tower管理]
        end
        
        subgraph "セキュリティ基盤"
            LOG[ログアーカイブアカウント<br/>CloudTrail/Config集約]
            AUDIT[監査アカウント<br/>セキュリティツール/監査]
        end
        
        subgraph "共有サービス"
            NET[ネットワークアカウント<br/>Transit Gateway/Direct Connect]
            SHARED[共有サービスアカウント<br/>CI/CD/共通ツール]
        end
        
        subgraph "ワークロード"
            PROD[本番アカウント群]
            DEV[開発アカウント群]
            STAGE[ステージングアカウント群]
        end
    end
    
    MGMT --> LOG
    MGMT --> AUDIT
    MGMT --> NET
    MGMT --> SHARED
    MGMT --> PROD
    MGMT --> DEV
    MGMT --> STAGE

Control Towerが自動作成するOU構造

Control Towerをセットアップすると、以下のOU構造が自動的に作成されます。

OU名 目的 含まれるアカウント
Security OU セキュリティ基盤 Log Archive、Audit
Sandbox OU 検証・学習環境 開発者の実験用アカウント

これはあくまで最小構成であり、実際の運用では組織の要件に応じてOU構造を拡張する必要があります。

OU設計パターン

組織単位（OU）は、アカウントをグループ化してポリシー（SCP、タグポリシーなど）を一括適用するための論理的な構造です。OU設計は、マルチアカウント戦略の成否を左右する重要な意思決定です。

AWS推奨のOU構造

AWS Security Reference Architecture（SRA）では、以下のOU構造が推奨されています。

flowchart TB
    ROOT[Root]
    
    ROOT --> SECURITY[Security OU]
    ROOT --> INFRA[Infrastructure OU]
    ROOT --> SANDBOX[Sandbox OU]
    ROOT --> WORKLOADS[Workloads OU]
    ROOT --> POLICY_STAGING[PolicyStaging OU]
    ROOT --> SUSPENDED[Suspended OU]
    ROOT --> INDIVIDUAL[Individual Business Users OU]
    ROOT --> EXCEPTIONS[Exceptions OU]
    ROOT --> DEPLOYMENTS[Deployments OU]
    ROOT --> TRANSITIONAL[Transitional OU]
    
    subgraph "Security OU"
        LOG_ARCHIVE[Log Archive Account]
        SECURITY_TOOLING[Security Tooling Account]
    end
    
    subgraph "Infrastructure OU"
        NETWORK[Network Account]
        SHARED_SERVICES[Shared Services Account]
    end
    
    subgraph "Workloads OU"
        PROD_OU[Prod OU]
        SDLC_OU[SDLC OU]
    end
    
    SECURITY --> LOG_ARCHIVE
    SECURITY --> SECURITY_TOOLING
    INFRA --> NETWORK
    INFRA --> SHARED_SERVICES
    WORKLOADS --> PROD_OU
    WORKLOADS --> SDLC_OU

各OUの役割と設計意図

Security OU

セキュリティとコンプライアンスに関する最重要アカウントを配置します。

アカウント 役割 主要サービス
Log Archive 全アカウントのログ集約・長期保管 S3、CloudTrail、Config
Security Tooling（Audit） セキュリティ監視・インシデント対応 Security Hub、GuardDuty、Detective

Security OUに適用するSCPの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLogArchiveDeletion",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::aws-controltower-logs-*",
        "arn:aws:s3:::aws-controltower-logs-*/*"
      ],
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/AWSControlTowerExecution"
          ]
        }
      }
    }
  ]
}

Infrastructure OU

組織全体で共有するインフラストラクチャリソースを管理するアカウントを配置します。

アカウント 役割 主要サービス
Network 集約型ネットワーク管理 Transit Gateway、Direct Connect、Route 53
Shared Services 共通ツール・サービス CI/CD、Active Directory、共通AMI 
flowchart TB
    subgraph "Network Account"
        TGW[Transit Gateway]
        DX[Direct Connect Gateway]
        R53[Route 53 Private Hosted Zone]
        EGRESS[Egress VPC<br/>NAT/Firewall]
        INGRESS[Ingress VPC<br/>ALB/CloudFront]
    end
    
    subgraph "Workload Accounts"
        WL1[Prod Account A]
        WL2[Prod Account B]
        WL3[Dev Account]
    end
    
    TGW --> WL1
    TGW --> WL2
    TGW --> WL3
    WL1 --> EGRESS
    WL2 --> EGRESS
    WL3 --> EGRESS

Workloads OU

実際のビジネスワークロードを運用するアカウントを配置します。通常、子OUとして環境別（Prod、SDLC）に分割します。

子OU 目的 適用するガードレール
Prod OU 本番ワークロード 厳格なセキュリティ制御
SDLC OU 開発・テスト 開発者の柔軟性を確保

Sandbox OU

開発者が自由に実験・学習できる環境を提供します。本番環境との接続を禁止し、コスト上限を設定することが重要です。

Sandbox OUに適用するSCPの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyVPCPeering",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateVpcPeeringConnection",
        "ec2:AcceptVpcPeeringConnection"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyExpensiveServices",
      "Effect": "Deny",
      "Action": [
        "redshift:CreateCluster",
        "rds:CreateDBInstance",
        "elasticache:CreateCacheCluster"
      ],
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringNotLike": {
          "rds:DatabaseClass": ["db.t3.*", "db.t4g.*"]
        }
      }
    }
  ]
}

その他の重要なOU

OU名 目的 使用シナリオ
PolicyStaging OU SCP変更のテスト 本番適用前の検証
Suspended OU 利用停止アカウント 退職者アカウント、不要アカウントの隔離
Transitional OU 移行中アカウント Organizations参加直後の一時配置
Exceptions OU 例外的なアカウント 特殊な要件を持つアカウント
Deployments OU CI/CDアカウント 本番デプロイ用の高権限アカウント

ワークロード分離パターン

Workloads OU配下のアカウント分割には、複数のパターンがあります。組織の規模、チーム構成、コンプライアンス要件に応じて適切なパターンを選択します。

パターン1: 環境別分離

最もシンプルで一般的なパターンです。開発、ステージング、本番の環境ごとにアカウントを分離します。

flowchart TB
    WL[Workloads OU]
    
    WL --> PROD[Prod OU]
    WL --> STAGE[Staging OU]
    WL --> DEV[Dev OU]
    
    PROD --> PROD_APP[本番アプリケーション]
    STAGE --> STAGE_APP[ステージング環境]
    DEV --> DEV_APP[開発環境]

メリット

  • 構造がシンプルで理解しやすい
  • 環境ごとに異なるセキュリティポリシーを適用しやすい
  • 小〜中規模組織に適している

デメリット

  • ワークロード数が増えると1つのアカウントが肥大化
  • プロジェクト間のコスト分離が困難

パターン2: ワークロード別分離

各ワークロード（アプリケーション、サービス）ごとにアカウントを作成し、さらに環境別に分割します。

flowchart TB
    WL[Workloads OU]
    
    WL --> APP_A[Application A]
    WL --> APP_B[Application B]
    WL --> APP_C[Application C]
    
    subgraph "Application A"
        APP_A --> APP_A_PROD[app-a-prod]
        APP_A --> APP_A_STAGE[app-a-stage]
        APP_A --> APP_A_DEV[app-a-dev]
    end
    
    subgraph "Application B"
        APP_B --> APP_B_PROD[app-b-prod]
        APP_B --> APP_B_STAGE[app-b-stage]
        APP_B --> APP_B_DEV[app-b-dev]
    end

メリット

  • ワークロードごとの完全な分離
  • 明確なコスト配分
  • チームごとの独立した運用が可能

デメリット

  • アカウント数が急増（ワークロード数 × 環境数）
  • 管理オーバーヘッドの増加

パターン3: チーム/プロダクト別分離

ビジネスユニット、プロダクトチーム、または事業部門ごとにOUを作成し、その配下に環境別アカウントを配置します。

flowchart TB
    WL[Workloads OU]
    
    WL --> BU1[Business Unit 1 OU]
    WL --> BU2[Business Unit 2 OU]
    
    subgraph "Business Unit 1"
        BU1 --> BU1_PROD[Prod OU]
        BU1 --> BU1_SDLC[SDLC OU]
        BU1_PROD --> BU1_P1[bu1-prod-app1]
        BU1_PROD --> BU1_P2[bu1-prod-app2]
        BU1_SDLC --> BU1_D1[bu1-dev-app1]
        BU1_SDLC --> BU1_D2[bu1-dev-app2]
    end
    
    subgraph "Business Unit 2"
        BU2 --> BU2_PROD[Prod OU]
        BU2 --> BU2_SDLC[SDLC OU]
    end

メリット

  • 事業部門の自律性を確保
  • 部門ごとの予算管理が容易
  • 大規模組織に適している

デメリット

  • OU構造が深くなりSCP継承が複雑化
  • 部門間の標準化が困難になる可能性

パターン選択の判断基準

判断基準 パターン1（環境別） パターン2（ワークロード別） パターン3（チーム別）
組織規模 小〜中規模 中〜大規模 大規模
ワークロード数 少ない（5未満） 中程度（5〜20） 多い（20以上）
コンプライアンス要件 低〜中 高（アプリ単位の監査） 中〜高
チームの独立性 低い 中程度 高い
管理オーバーヘッド 低い 中程度 高い

共有サービスアカウントの設計

複数のワークロードアカウントで共通して利用するリソースやサービスは、共有サービスアカウントに集約することで効率化とコスト最適化を実現できます。

共有サービスの種類と配置

flowchart TB
    subgraph "Infrastructure OU"
        subgraph "Network Account"
            TGW[Transit Gateway]
            DX[Direct Connect]
            FIREWALL[Network Firewall]
            DNS[Route 53 Resolver]
        end
        
        subgraph "Shared Services Account"
            AD[AWS Managed AD]
            CICD[CI/CDパイプライン]
            ARTIFACTS[共有アーティファクト]
            AMI[共有AMI/ECRイメージ]
        end
    end
    
    subgraph "利用側アカウント"
        WL1[Workload Account 1]
        WL2[Workload Account 2]
    end
    
    TGW --> WL1
    TGW --> WL2
    AD --> WL1
    AD --> WL2
    CICD --> WL1
    CICD --> WL2

ネットワークの集約パターン

大規模環境では、ネットワークリソースをNetwork Accountに集約するHub-Spokeモデルが推奨されます。

flowchart TB
    subgraph "Network Account（Hub）"
        TGW[Transit Gateway]
        
        subgraph "Egress VPC"
            NAT[NAT Gateway]
            NGFW[Network Firewall]
        end
        
        subgraph "Ingress VPC"
            ALB[Application Load Balancer]
            WAF[AWS WAF]
        end
        
        subgraph "Shared Services VPC"
            ENDPOINT[VPC Endpoints<br/>S3, DynamoDB, etc.]
        end
        
        subgraph "On-Premises Connectivity"
            DX[Direct Connect Gateway]
            VPN[Site-to-Site VPN]
        end
    end
    
    subgraph "Workload Accounts（Spoke）"
        PROD_VPC[Production VPC]
        DEV_VPC[Development VPC]
    end
    
    TGW --> PROD_VPC
    TGW --> DEV_VPC
    PROD_VPC --> NAT
    DEV_VPC --> NAT
    PROD_VPC --> ENDPOINT
    DEV_VPC --> ENDPOINT
    TGW --> DX

Hub-Spokeモデルのメリット

メリット 説明
コスト最適化 NAT Gateway、VPC Endpointを共有してコスト削減
セキュリティ集約 Egress/Ingressトラフィックを一元的に監視・制御
運用効率化 ネットワーク設定変更を1箇所で実施
オンプレミス接続 Direct Connect/VPNをワークロードアカウントと共有

CI/CDパイプラインの設計

CI/CDパイプラインは、セキュリティとガバナンスの観点から慎重な設計が必要です。

flowchart LR
    subgraph "Deployments Account"
        CODECOMMIT[CodeCommit/GitHub]
        CODEBUILD[CodeBuild]
        CODEPIPELINE[CodePipeline]
        ARTIFACTS[S3 Artifacts]
    end
    
    subgraph "Dev Account"
        DEV_DEPLOY[開発環境デプロイ]
    end
    
    subgraph "Staging Account"
        STAGE_DEPLOY[ステージングデプロイ]
        STAGE_TEST[統合テスト]
    end
    
    subgraph "Prod Account"
        PROD_DEPLOY[本番デプロイ]
    end
    
    CODECOMMIT --> CODEBUILD
    CODEBUILD --> ARTIFACTS
    CODEPIPELINE --> DEV_DEPLOY
    DEV_DEPLOY --> STAGE_DEPLOY
    STAGE_TEST --> PROD_DEPLOY

クロスアカウントデプロイのIAMロール設計

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::DEPLOYMENTS_ACCOUNT_ID:role/CodePipelineRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "deployment-pipeline"
        }
      }
    }
  ]
}

既存環境からの移行戦略

既存の単一アカウント環境やレガシーなマルチアカウント環境から、Control Towerベースのランディングゾーンへ移行する際の戦略を解説します。

移行アプローチの比較

アプローチ 概要 メリット デメリット 推奨シナリオ
グリーンフィールド 新規ランディングゾーンを構築し、ワークロードを移行 クリーンな環境、ベストプラクティス適用 移行工数大、ダウンタイムリスク 新規プロジェクト、小規模環境
ブラウンフィールド 既存Organizations環境にControl Towerを導入 既存アカウント活用、段階的移行 制約事項あり、互換性確認必要 既存Organizations環境
ハイブリッド 新規ランディングゾーンと既存環境を併用 柔軟性、リスク分散 複雑性増加、二重管理 大規模環境、段階的移行

移行フェーズ

flowchart LR
    subgraph "Phase 1: 評価・計画"
        P1_1[現状分析]
        P1_2[アカウント棚卸し]
        P1_3[OU構造設計]
        P1_4[移行計画策定]
    end
    
    subgraph "Phase 2: 基盤構築"
        P2_1[ランディングゾーン構築]
        P2_2[ネットワーク設計]
        P2_3[共有サービス構築]
        P2_4[ガードレール設定]
    end
    
    subgraph "Phase 3: 移行実行"
        P3_1[パイロットアカウント移行]
        P3_2[検証・調整]
        P3_3[本番アカウント移行]
        P3_4[レガシー環境廃止]
    end
    
    P1_1 --> P1_2 --> P1_3 --> P1_4
    P1_4 --> P2_1
    P2_1 --> P2_2 --> P2_3 --> P2_4
    P2_4 --> P3_1
    P3_1 --> P3_2 --> P3_3 --> P3_4

既存アカウントの登録

Control Towerには既存のAWSアカウントを登録（Enroll）する機能があります。

登録の前提条件

条件 詳細
Organizations所属 既存アカウントが同じOrganizationsのメンバーであること
信頼されたアクセス Control Towerの信頼されたアクセスが有効であること
デフォルトVPC 登録先リージョンでデフォルトVPCが削除可能であること
AWS Config 既存のConfigレコーダー/配信チャネルの削除が必要
CloudTrail 既存の組織証跡との競合がないこと

登録プロセス

sequenceDiagram
    participant Admin as 管理者
    participant CT as Control Tower
    participant ORG as Organizations
    participant ACCT as 既存アカウント
    
    Admin->>CT: アカウント登録開始
    CT->>ORG: アカウントの所属確認
    CT->>ACCT: 前提条件チェック
    CT->>CT: ガードレール適用
    CT->>ACCT: AWS Config有効化
    CT->>ACCT: CloudTrail設定
    CT->>ACCT: IAM Identity Center設定
    CT-->>Admin: 登録完了

ワークロード移行パターン

既存アカウントのワークロードを新しいアカウント構造に移行する方法は複数あります。

パターン 概要 適用シナリオ
リホスト EC2インスタンス、AMIをそのまま移行 迅速な移行が必要な場合
リファクタ アーキテクチャを見直して再構築 モダナイゼーションを同時に行う場合
アカウント分割 1アカウント内のワークロードを複数アカウントに分割 肥大化したアカウントの整理
アカウント統合 分散したリソースを1アカウントに集約 過度に分散した環境の整理

ガバナンスの継続的改善

ランディングゾーンは一度構築して終わりではなく、継続的な改善が必要です。

ガバナンスの成熟度モデル

flowchart LR
    L1[Level 1<br/>初期]
    L2[Level 2<br/>定義済み]
    L3[Level 3<br/>管理]
    L4[Level 4<br/>測定]
    L5[Level 5<br/>最適化]
    
    L1 --> L2 --> L3 --> L4 --> L5
    
    L1 -.- L1D[手動管理<br/>ドキュメントなし]
    L2 -.- L2D[ポリシー定義<br/>手動適用]
    L3 -.- L3D[自動化<br/>Control Tower導入]
    L4 -.- L4D[メトリクス収集<br/>コンプライアンス測定]
    L5 -.- L5D[継続的改善<br/>自動修復]

定期的なレビュー項目

レビュー項目 頻度 担当 チェックポイント
SCPレビュー 四半期 セキュリティチーム 新サービスへの対応、過剰な制限の見直し
OUドリフト確認 月次 クラウドCoE 不適切なOU配置のアカウント
未使用アカウント 四半期 財務/IT リソースのないアカウントの特定
ガードレール更新 Control Tower更新時 クラウドCoE 新しいガードレールの評価・適用
コンプライアンス監査 年次 監査チーム 全体的なガバナンス状態の評価

まとめ

本記事では、AWSマルチアカウント戦略とランディングゾーン設計について解説しました。重要なポイントを整理します。

マルチアカウント戦略の必要性

  • AWSアカウントは最も強力なリソース分離境界
  • セキュリティ、コスト管理、コンプライアンスの課題を解決

OU設計のベストプラクティス

  • Security OU、Infrastructure OU、Workloads OUを基本構造とする
  • 組織の規模と要件に応じて環境別/ワークロード別/チーム別のパターンを選択

共有サービスの設計

  • ネットワークはHub-Spokeモデルで集約
  • CI/CDは専用アカウントで管理し、クロスアカウントデプロイを実装

移行と継続的改善

  • 既存環境からの移行は段階的に実施
  • ガバナンスは継続的に評価・改善

次回の記事では、AWS Security Hubとガードレールを組み合わせた統合セキュリティ監視について解説します。

参考リンク