AWS Organizations徹底解説：GCPリソース階層・Azure Management Groupsとの比較で学ぶマルチアカウント設計

はじめに（要点サマリー）

• 本記事では AWS Organizations を主役に、GCPのリソース階層（Organization / Folder / Project）、Azure Management Groups＋サブスクリプション構造 を横並びで比較しながら、マルチアカウント／マルチプロジェクト時代のクラウド設計 を丁寧に整理していきます。
• AWS Organizations は、複数のAWSアカウントをポリシーベースで一元管理し、アカウント作成の自動化・ガバナンス・コスト管理・監査の集約 を実現するサービスです。追加料金なしで利用でき、スケールする環境の“土台”になります。
• これに対して、GCPは Organization / Folder / Project のリソース階層と Cloud IAM / Org Policy、Azureは Management Group / Subscription / Resource Group と Azure RBAC / Azure Policy で、同じような「階層ガバナンス」を提供しています。
• 設計の肝は、
  1. アカウント（またはプロジェクト／サブスクリプション）を“組織図”ではなく“ガバナンスと責任”で切ること
  2. SCP（Service Control Policy）やOrg Policy／Azure Policyで“上限ルール”を決めること
  3. セキュリティ・ログ・請求を集約する“ハブ”アカウント／プロジェクトを用意すること
  4. 環境（prod / stg / dev）やチーム単位でOU／フォルダ／Management Groupを整理すること
  5. 将来のマルチクラウドを見据え、命名・階層・権限設計を“クラウド横断で再利用できる形”にしておくこと
• 想定読者は、情報システム部門のクラウド統括担当、SRE／プラットフォームエンジニア、セキュリティ・ガバナンス担当、複数プロダクトを抱える開発組織のリードエンジニア、スタートアップCTO のみなさまです。
  • 単一アカウントを卒業して**「そろそろアカウントを分けたい」「部門ごとに責任境界を分けたい」**と思い始めたフェーズにぴったりの内容になっています。

1. AWS Organizationsとは：マルチアカウントを“1つの組織”として扱うサービス

1.1 基本イメージ

AWS Organizations は、ざっくり言うと

「複数のAWSアカウントを一つの“組織”として束ねて、
アカウント作成・ポリシー・請求・ガバナンスをまとめて管理するためのサービス」

です。

主な特徴は次のとおりです。

• 複数アカウントの一元管理
  • 1つの「組織（Organization）」配下に複数アカウントをぶら下げ、階層構造（OU）で整理できます。
• アカウントライフサイクルの自動化
  • API／CloudFormation／各種テンプレート（Landing Zone系ソリューション）から、新しいアカウントを自動作成できます。
• ポリシーベースのガバナンス（SCP）
  • 組織／OU／アカウント単位で Service Control Policy (SCP) を適用し、「この組織では iam:* は一切ダメ」「このOUでは東京リージョン以外禁止」といった上限ルールを定義できます。
• 請求の集約（コンソリデーテッドビリング）
  • 組織配下のアカウントの利用料を1つの請求にまとめて管理でき、ボリュームディスカウントも効きやすくなります。

1.2 主要コンポーネント

AWS Organizations の世界観を構成する用語を、かんたんに整理しておきます。

• Organization（組織）
  • AWSアカウントの集合体。1つの管理アカウントを頂点として、複数アカウントをぶら下げます。
• Management Account（管理アカウント）
  • 組織を最初に作った“親”アカウント。
  • アカウント招待／作成・SCP設定・請求管理など強い権限を持つため、原則人が直接触らないようにしたい存在です。
• Member Account（メンバーアカウント）
  • 組織に参加している通常のアカウント。既存アカウントを招待／新規アカウントの作成どちらもOKです。
• Root（ルート）
  • 組織階層の最上位ノード。ここにSCPをかけると、組織内すべてのアカウントに効くことになります。
• OU（Organizational Unit）
  • アカウントをまとめる“フォルダ”のような単位。OUの中に別のOUも作れるので、階層化された組織構造を表現できます。

これらを組み合わせて、「セキュリティ用アカウント」「ログ集約アカウント」「プロダクトA本番」「プロダクトA検証」…といった形でアカウントを整理していきます。

2. AWS / GCP / Azure の“階層構造”を揃えて理解する

「Organizationsって、GCPやAzureだと何にあたるの？」という疑問に、まずお答えしておきますね。

2.1 3クラウドの階層構造のざっくり比較

AWS（Organizations＋IAM）

• Organization
  • Root
    • OU（部門／環境などを表現）
      • Account（AWSアカウント）
        • 各種リソース（VPC, EC2, RDS…）

GCP（Resource Manager＋Cloud IAM）

• Organization
  • Folder（任意階層のフォルダ。部門／システム／環境などを表現）
    • Project
      • 各種リソース（Compute Engine, Cloud SQL, GKE…）

Azure（Management Groups＋Subscriptions）

• Management Group（組織全体の“上位コンテナ”）
  • Management Group（入れ子可能）
    • Subscription
      • Resource Group
        • 各種リソース（VM, Storage, SQL DB, AKS…）

どのクラウドも、「上位ノードに設定したポリシーや権限は、配下に継承される」というルールになっており、

• AWS：SCP＋IAM
• GCP：Cloud IAMのAllow / Denyポリシー、Org Policy
• Azure：Azure RBAC＋Azure Policy

で似たような世界を作っています。

2.2 感覚的な対応表

• AWS Organization ⇔ GCP Organization ⇔ Azure テナント＋Management Groups
• AWS OU ⇔ GCP Folder ⇔ Azure Management Group
• AWS Account ⇔ GCP Project ⇔ Azure Subscription

と覚えておくと、頭の中でマッピングしやすいです。
（厳密には少し違いもありますが、「**クラウド全体の“フォルダ構造”」**という意味ではほぼ同じ役割です）

3. 代表ユースケース：どんなときにOrganizationsを使うのか

3.1 部門・環境ごとにアカウントを分けてガバナンスを効かせたい

よくあるパターンは、次のようなツリー構造です。

• Root

  • security OU
    • セキュリティツール用アカウント
    • ログ集約アカウント
  • shared-services OU
    • ネットワークハブアカウント
    • 共通基盤（CI/CD・IAM Identity Centerなど）
  • workloads OU
    • prod OU
      • プロダクトA本番アカウント
      • プロダクトB本番アカウント
    • nonprod OU
      • プロダクトA開発・検証アカウント
      • プロダクトB開発・検証アカウント

• セキュリティ／ネットワーク／共通基盤は “共有サービス”アカウント

• 各プロダクトチームは自分のアカウントに閉じて作業、ただしSCPで危険な設定は制限

という形にすると、責任分界がはっきりしつつ、運用も整理しやすくなります。

GCPなら Organization配下に security / shared / workloads フォルダ を作り、その下にProjectをぶら下げるイメージ、Azureなら Management Groups配下にサブスクリプションを分けるイメージで、ほぼ同じ構造を再現できます。

3.2 コンソリデーテッドビリングによるコスト管理

部門ごとにアカウントを分けつつ、請求は一本化して経理処理したいときにもOrganizationsが役立ちます。

• 各アカウントの利用額はCost Explorerや請求レポートでアカウント単位に見える
• でも請求書は組織としてまとまるので、支払いはシンプル
• ボリュームディスカウントやSavings Plansなども組織全体に効きやすい

GCPでも請求アカウント＋プロジェクト、AzureでもEnterprise Agreement / CSP＋複数サブスクリプションという形で同じような集約が可能ですが、AWSはOrganizationsとCost Managementツールが密に統合されているのが特徴です。

3.3 規制・コンプライアンス対応のガードレール

• 「この組織では指定されたリージョン以外を使ってはいけない」
• 「このOU配下ではrootユーザーでの操作は禁止」
• 「この部門は特定サービス（例：高リスクなテスト系サービス）を使ってはいけない」

といったルールを、SCPとしてRoot／OU単位で宣言しておくことで、アカウント個別の設定漏れを防げます。

同様に、GCPのOrg PolicyやAzureのAzure Policy＋Management Groupでも、「特定リージョン制限」「特定サービス禁止」「タグ必須」などを組織レベルで定義できます。

4. SCP（Service Control Policy）で“上限”を決める

4.1 SCPの役割

IAMポリシーが「そのユーザー／ロールに対する権限付与」であるのに対して、SCPは

「このアカウント（またはOU配下のアカウント）は、そもそも何をしてはいけないか」

を決める “上限ガードレール” です。

• IAMポリシーでAllowされていても、SCPでDenyされていれば最終的にNG
• 逆に、SCPでAllowされていても、IAMポリシーでAllowされていなければNG

という二重構造になっています。

4.2 代表的なSCPサンプル

4.2.1 rootユーザーのAPI使用禁止

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

このSCPをRootまたは特定OUに付けておくと、rootユーザーでのAPI操作を完全に禁止できます（ログインや課金情報の閲覧など一部はConsole側の仕様に依存しますが、少なくとも“うっかりrootキーで操作”を防げます）。

4.2.2 東京リージョン以外の利用禁止

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsExceptTokyo",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

コンプライアンス上、利用リージョンを限定したい場合に有効です。
GCPでもOrg Policyでconstraints/gcp.resourceLocationsを使ってリージョン制限をかけたり、AzureでもManagement Group＋Policyでlocation制限をかけることで、ほぼ同じ考え方が実現できます。

5. アカウント構成パターン：規模別の“型”

5.1 小規模〜スタートアップ向け（2〜5アカウント）

• management（or root）：Organizations管理・請求のみ（普段は人が入らない）
• security：CloudTrail集約、セキュリティツール、ログ保管
• shared：VPCハブ、IAM Identity Center、共通CI/CD
• prod：本番ワークロード
• nonprod：開発・検証ワークロード

最初はこれくらいのシンプルさでも十分です。後から必要に応じてprod-a prod-bのように増やしていけばOKです。

GCPならorganization配下にsecurity/shared/prod/nonprodフォルダ＋Projectを、AzureならManagement Groups＋複数Subscriptionで同じ世界を作れます。

5.2 中〜大規模組織向け（部門／国／事業単位）

• security OU
• shared-services OU
• corp-it OU（社内IT向けシステム）
• business-unit-a OU
  • prod / nonprod
• business-unit-b OU
  • prod / nonprod

というように、ビジネス単位×環境でOUを切りながら、共通ルール（リージョン制限／root禁止／ロギング必須など）をSCPでかけていきます。

GCPのFolder階層や、AzureのManagement Group階層も同様に、

• org
  • shared
  • corp-it
  • bu-a
  • bu-b

といった構造でガバナンスを効かせるのが一般的です。

6. GCP・Azureとの対比で見る“ガバナンスのツボ”

6.1 IAMとの組み合わせ

• AWS：
  • OrganizationsのSCPが**“やって良いことの上限”、IAMポリシーが“実際に誰に何を任せるか”**
• GCP：
  • Cloud IAMロール＋Org Policyで、階層ごとのAllow/Denyを制御
• Azure：
  • Management Group／Subscription／Resource Group階層に対し、RBACロール＋Azure Policyで制御

どのクラウドでも、「上位のコンテナにガードレールを敷き、下位で日々の権限付与を行う」という二段構えが共通しています。

6.2 ログ・監査との連携

• AWSでは、ログ集約用アカウントをOrganizations配下に置き、
  • CloudTrail
  • Config
  • セキュリティ系ログ
    を1か所に集約するのが定番パターンです。
• GCPでも、Loggingのログシンク先プロジェクトを一つ用意して各プロジェクトから転送、AzureでもLog Analyticsワークスペースを集約して、Activity Logや診断ログをそこへ集める、という形で似た構成がよく使われます。

6.3 マルチクラウドをまたいだ“頭の使い方”

• 「最上位ノード（Organization / Tenant / Management Groupの最上段）に“全社ルール”を置く」
• 「部門・プロダクト・環境ごとに中間ノード（OU / Folder / Management Group）を切る」
• 「課金単位（Account / Project / Subscription）で責任分界と予算管理を行う」

という3ステップで考えると、AWS／GCP／Azureどれでも同じパターンで設計できるようになります。

7. よくある落とし穴と回避策

7.1 単一アカウントに“全部詰め込んでから”Organizationsに移行しようとする

• 問題点：
  • VPC・IAM・タグ・命名規則が“ごちゃ混ぜ”のまま拡大してしまい、
  • いざアカウント分割しようとすると移行コストが爆発します。
• 回避策：
  • まだ小規模なうちから、Organizations＋少なくとも2〜3アカウントに分ける習慣をつける。
  • GCPでも複数Project、Azureでも複数Subscriptionでの運用を「当たり前」にしておきます。

7.2 SCPで強く締めすぎて詰む

• 問題点：
  • 「とりあえずセキュリティ強く！」と、SCPで"*"をDenyしまくると、
  • 後から必要なサービスが使えず、SCPの再設計だけで大工事になります。
• 回避策：
  • 最初は「明らかに危険な操作（root API・リージョン制限など）だけをSCPで封じる」レベルから始める。
  • GCP／Azureでも、Org PolicyやAzure Policyをいきなり全面導入せず、段階的に適用範囲を広げるのが無難です。

7.3 OU構造を“人事組織”に寄せすぎる

• 問題点：
  • 人事の組織改編のたびに、OUやFolder、Management Groupの構造を変えたくなってしまい、ガバナンスポリシーの移設が地獄になります。
• 回避策：
  • OU／Folder／Management Groupは、**「責任とガバナンス」「システム構成」「環境（prod / nonprod）」**を軸に構成し、人事組織とはゆるく対応づける程度にしておきます。

8. 想定読者別：この内容がどう役立つか

8.1 情報システム部門・クラウド統括担当の方へ

• 複数部門・複数プロダクトがAWSを使い始めたとき、**「アカウントをどう分ければ、管理・監査・コストが楽になるか」**という悩みが出てきますよね。
• AWS Organizationsを軸に、security / shared / workloads OU構造＋SCP＋ログ集約アカウントの組み合わせを採用することで、
  • 「部門に自由度は渡しつつ、最低限ここだけは守ってもらう」
  • 「全アカウントの操作履歴と請求を一箇所で把握する」
    といった、“現実的な統制” を実現しやすくなります。

8.2 SRE／プラットフォームエンジニアの方へ

• 「ランディングゾーンをどう設計するか」「セキュアなベースラインをどう配布するか」というお仕事の中で、Organizationsは必須のピースになります。
• 本記事のパターンをベースに、
  • OU構造
  • アカウントの役割分担
  • SCPテンプレート
  • ログ集約パターン
    をコード（IaC）に落としておくと、新しいプロダクトやチームが生まれたときにも同じ型で素早く展開できます。

8.3 セキュリティ・ガバナンス担当の方へ

• 「この会社として、クラウドで何をしてはいけないのか」をドキュメントだけでなく技術的なガードレールとして実装できるのが、SCP／Org Policy／Azure Policyです。
• Organizationsレベルで
  • root禁止
  • リージョン制限
  • ログの必須化
    をSCPとして敷き、GCP／Azure側にも同じ内容を反映しておくことで、マルチクラウドかつ一貫したコンプライアンスを保ちやすくなります。

8.4 スタートアップCTO・テックリードの方へ

• 立ち上げ初期は「1アカウントで全部やっちゃえ」となりがちですが、成長してからの分割はかなり大変です…。
• 本記事の**“5アカウント構成”**くらいを最初から採用しておくと、
  • 投資家向けの説明／監査への対応
  • 新しいプロダクトの追加
  • 海外展開
    にもスムーズに対応できる“伸びしろ”を確保できます。

9. 今日からできる3ステップ

1. 現状のアカウント／プロジェクト／サブスクリプションを棚卸しする
   • 「何のための環境か」「誰が責任を持つか」「ログと請求はどこに行くか」を書き出してみましょう。
2. “5アカウント（or 5プロジェクト/サブスクリプション）モデル”にマッピングしてみる
   • security / shared / prod / nonprod / management に割り当てていき、足りないものを洗い出します。
3. Organizations（またはGCPのOrg、AzureのManagement Group）で最小限の階層を作る
   • いきなり完璧を目指さず、まずはRoot直下に security / shared / workloads くらいのOU／Folder／Management Groupを作ってみるだけでも、考え方がかなり整理されます。

10. まとめ：アカウントは「組織図」ではなく「責任とガバナンス」で切る

AWS Organizations は、単にアカウントを束ねるだけのサービスではなく、

• アカウント設計の“型”を決めるフレームワーク
• SCPで全社ガードレールを敷くための土台
• ログ・請求・セキュリティの集約ポイント

として、クラウド環境の“骨組み”を支えてくれる存在です。

GCPのResource Manager（Organization / Folder / Project）や、AzureのManagement Groups＋Subscriptionsも、同じ目的を持つ仲間たちです。
クラウドごとの細かな違いにとらわれすぎず、

1. 最上位に全社ルールを置く
2. 中間階層で部門やシステム・環境を表現する
3. 課金単位（Account / Project / Subscription）で責任と予算を分ける

という“共通の頭の使い方”さえ身につけてしまえば、マルチクラウドの世界でも迷いにくくなります。

次のサービスでは、このOrganizationsやIAM、VPCとも密接に関わる**ECS / EKS（コンテナ基盤）**を題材に、**GCP（GKE / Cloud Run）・Azure（AKS / Container Apps）**との比較まで含めて、「アプリをどこにどう載せるか」という観点からクラウド設計を深掘りしていきますね。
一緒に、少しずつ“壊れにくくて伸びやすいクラウド”を育てていきましょう。

参考リンク（日本語・英語公式ドキュメント中心）

• AWS Organizations とは（ユーザーガイド）

• AWS Organizations 製品ページ（クラウド管理）

• AWS Organizations 解説記事（日本語）〈Black Belt資料〉

• Google Cloud Resource Manager：Resource hierarchy

• Azure Management Groups / Subscriptions 概要

  • Management Groups Overview
  • Azure サブスクリプションの概要

※具体的な制限値・最新機能・料金体系は、必ず各クラウドの公式ドキュメント／料金ページをご確認ください。