AWS Organizations入門：ゼロから作る、統制されたマルチアカウント基盤

AWSの利用が広がると、本番・検証・開発、部門ごとのPoCと、アカウントは自然に増えていきます。増えたアカウントを場当たり的に管理すると、権限・コスト・セキュリティの統制はあっという間に崩れます。本記事では、AWS Organizationsを軸に、Control Tower、IAM Identity Center、ログ集約までを組み合わせて、ゼロから「統制されたマルチアカウント基盤」を構築する手順を解説します。

貫く設計思想はひとつです。SCPで権限を絞り、機能を最小化した「小さなAWS」を精緻に作り上げ、分散させる──Organizationsというテーマは、この作り込みの精緻さにこそ設計者の腕が出ます。本記事でも、この視点を軸に各機能を見ていきます。

AWS Organizationsとは ── 4つの構成要素

AWS Organizationsは、複数のAWSアカウントを一つの「組織」として束ね、統制・課金・セキュリティを横断的に管理する仕組みです。登場人物は次の4つだけです。

• 管理アカウント：組織の頂点。請求と全体設定を統括する起点となるアカウント。
• メンバーアカウント：実際にワークロードを動かす個々のアカウント。
• OU（組織単位）：アカウントを用途別にまとめる階層フォルダ。
• SCP（サービスコントロールポリシー）：OUやアカウントに「使える機能の上限」を定める防壁。

図1：AWS Organizationsの基本構造（管理アカウント・OU・メンバーアカウント・SCP）

Organizations導入の3つのメリット

• 一括請求：全アカウントの請求を管理アカウントに集約し、ボリュームディスカウントを組織全体で享受できます。
• 集中ガバナンス：SCPで全アカウントの権限上限を一元的に統制できます。
• 影響の分離：障害・侵害・コスト超過を、それぞれのアカウントの中に閉じ込められます。

アカウントの分け方 ── OU設計

OU設計の哲学は、「できるだけ機能の少ない小さなアカウントを、SCPで統制しながら分散させる」ことです。1つひとつのアカウントを、必要な機能だけを持つ「小さなAWS」としてSCPでどこまで精緻に削り込めるか──ここがマルチアカウント設計の腕の見せ所です。用途ごとに細かく分けるほど、権限・課金・障害の影響範囲を内側に閉じ込められます。代表的なOU構成は次の4つです。

• Security OU：ログ集約・監査専用。人は普段触りません。
• Infrastructure OU：ネットワークなどの共有基盤を置きます。
• Workloads OU：本番／検証／開発を環境別のアカウントに分離します。
• Sandbox OU：実験用。強いSCPで隔離します。

SCPは許可リストではなく「ガードレール」

SCPは「何をさせるか」を1つずつ許可するリストではなく、「ここから先には行かせない」というガードレールとして設計します。ポイントは2つです。

• 最小機能の原則：各アカウントには必要なサービスとリージョンだけを許可し、それ以外は組織レベルで一律に拒否します。
• アカウント＝使い捨ての箱：小さく作って捨てやすくしておけば、1つのアカウントが侵害されても被害が他に波及しません。

たとえば「東京リージョン以外の利用を組織全体で禁止する」SCPは、次のように書けます（グローバルサービスの例外は一部省略しています）。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideTokyo",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["ap-northeast-1"] }
      }
    }
  ]
}

このようなSCPを、リージョンだけでなくサービス単位・アクション単位でどこまで精緻に積み上げられるか。アカウントを「何でもできる大きな箱」のまま渡すのではなく、SCPで削り込んだ小さなAWSを精緻に作り上げて渡せるかが、基盤設計者の力量がもっとも表れるポイントです。

AWS Control Tower ── 統制の自動化

AWS Control Towerは、Organizationsの上に「ベストプラクティス済みの統制環境（ランディングゾーン）」を自動構築するサービスです。手作業の組織設計を「自動化」する層と考えると分かりやすいでしょう。

• ランディングゾーン：Security系アカウント（Log Archive／Audit）を含むマルチアカウント基盤を、数クリックで自動セットアップします。
• ガードレール（コントロール）：予防的・発見的な統制を一括適用します。現行では280近いAWS Configコントロールが提供されています。
• Account Factory：標準化されたアカウントをテンプレートから払い出し、アカウント作成の属人化を排除します。

Organizationsを土台に、統制を「コード化された形」で展開・維持できるのが最大の価値です。最新のLanding Zone 4.0では、サービスごとに専用リソースを分離する構成が採用されています。ただし、Control Towerが自動化してくれるのはあくまで定型の統制まで。各アカウントをどこまで小さく精緻に削り込むかというSCPの設計そのものは、依然として設計者の腕にかかっています。

IAM Identity Centerとスイッチロール ── 人の入口を一本化

アカウントを細かく分けると、次の問題は「人がどう入るか」です。アカウントごとにIAMユーザーを作っていては、パスワードとアクセスキーが散乱してしまいます。IAM Identity Center（旧 AWS SSO）は、この「人の入口」を一本化する仕組みです。

• シングルサインオン：一度のログインで、権限のある複数アカウントへアクセスできます。
• 許可セット：役割ごとの権限テンプレートを定義し、アカウント横断で適用します。
• IdP連携：Microsoft Entra IDなどの社内ディレクトリと接続できます。
• Control Tower連携：グループと許可セットが自動構成されます。

スイッチロールの3ステップ

日常の運用では、常時強い権限を持たないことが重要です。スイッチロール（AssumeRole）の流れは次の3ステップです。

ログと監査 ── 証跡の集約

統制の最後のピースは、「誰が何をしたか」という証跡です。証跡は専用アカウントに集約し、改ざん・削除から守ります。マルチアカウント分離が、そのまま監査の強さにつながります。

• CloudTrail：全アカウントのAPI操作証跡を、組織トレイルで一元記録します。
• AWS Config：リソース構成の変化を追跡し、ルール準拠を継続評価します。
• Log Archiveアカウント：ログを集約して施錠。運用者でも消せない保管を実現します。
• Auditアカウント：セキュリティ調査と読み取り専用アクセスの拠点です。

図2：証跡の集約 ── ワークロードと監査をアカウント境界で分離する

なぜアカウントを分けると監査に強いのか

ログを生成するアカウントと、保管・閲覧するアカウントを分離すると、ワークロード側の権限を奪われても証跡には手が届きません。職務分掌（Separation of Duties）が、アカウント境界としてそのまま実装されるのです。これがマルチアカウント設計の隠れた、しかし最も重要な効能です。

ゼロからのセットアップ ── 8ステップ

ここまでの部品を、実際に組み上げる手順に落とし込みます。前半が「土台づくり」、後半が「統制と運用」です。

土台づくり（STEP 1〜4）

統制と運用（STEP 5〜8）

まとめ ── 小さく分けて、強く統制する

本記事のポイントを4つに整理します。

• Organizationsで束ねる：OUとSCPで、全アカウントの権限上限を一元統制する。
• Control Towerで自動化する：ランディングゾーンとガードレールで、統制を維持する。
• Identity Centerで入口を一本化する：SSOとスイッチロールで、常時の強権限を持たせない。
• ログを分離アカウントに集約する：証跡を改ざん不能にし、職務分掌をアカウント境界で実装する。

マルチアカウント設計は「アカウントが増えて困ってから」ではなく、最初の1アカウントを作る時点から始まっています。SCPでいかに「小さなAWS」を精緻に作り上げ、分散させるか──そこにこそ、設計者の腕が出ます。これからAWS基盤を立ち上げる方は、ぜひ本記事の8ステップから始めてみてください。

なお、Organizations導入の「そもそもなぜ必要か」という観点は、AWS Organizationsで始める、クラウド統治の現実解で詳しく解説しています。あわせてご覧ください。