AWS Organizations入門｜マルチアカウント管理とSCPでガバナンスを統制する実践ガイド

「開発チームごとにAWSアカウントを作ったら、いつのまにか20個近くになっていた。誰がどのアカウントの管理者なのかも、請求がどこに乗っているのかもわからない」
オンプレ時代はActive Directoryで一元管理できていたユーザーや権限が、AWSではアカウントが増えるたびに分散していく。気づけば請求書も部門別にバラバラ、IAMの設定も各アカウントで微妙に違う、本番アカウントで開発者が誤ってリソースを作成してしまう、といった事故が頻発する。

この記事では、AWS Organizationsについて、オンプレでADやドメインコントローラーを設計してきたインフラエンジニア向けに、基本概念からOU設計・SCP（Service Control Policy）の作り込み・一括請求・運用上の落とし穴まで、現場で再現できるレベルで解説します。マルチアカウント環境のガバナンスを「ツールに頼って統制する」ところまで一気に進めましょう。

なぜAWS Organizationsが必要なのか（オンプレとの違いと背景）

AWSにおける「アカウント」はオンプレでいう「個別のドメイン」に近い独立した境界です。リソースもIAMも請求も、原則としてアカウント単位で完結します。オンプレでは1つのADフォレストに複数ドメインをぶら下げて統制できましたが、AWSでは標準では何の関係もない独立アカウントが乱立してしまう構造です。

AWS Organizationsは、この乱立しがちな複数アカウントを「組織（Organization）」という階層構造でまとめ、ポリシー・請求・監査ログを一元管理するためのサービスです。2017年に正式リリース、2026年現在ではマルチアカウント運用の事実上の標準となっており、Control TowerやIAM Identity Center、Security Hubなどの上位サービスは全てOrganizationsを前提に設計されています。

1. アカウント分割が推奨される理由

AWS Well-Architected Frameworkでは、本番・開発・検証・サンドボックス・監査ログ用といった目的別にアカウントを分割することが推奨されています。理由は4つあります。

・権限分離: アカウント境界を越えるのは難しい仕組みなので、誤操作の影響範囲を物理的に限定できる
・料金可視化: アカウント単位で請求が分かれるため、部門・プロジェクト別のコスト把握が容易
・サービス上限の独立: EC2のvCPU上限などのService Quotaはアカウント単位で管理されるため、本番が開発の影響を受けない
・セキュリティ監査: 各アカウントのCloudTrailを監査専用アカウントに集約して改ざん耐性を確保できる

2. オンプレ時代との具体的な違い

オンプレADで「ドメインを分ける」判断は重い意思決定でしたが、AWSでは数分でアカウントを追加できるため、設計思想そのものが「分離を前提に組み立てる」方向に変わります。

AWS Organizationsの基本構造を理解する

Organizationsの構造は3階層で表現されます。Root（組織のルート）の直下にOU（Organizational Unit）が複数並び、各OUの中にアカウントが所属する形です。OUは入れ子にもできますが、深くしすぎると管理が複雑になるため、実務では2〜3階層に収めるのが定石です。

1. 用語整理

・管理アカウント（Management Account）: Organizationsを作成した最初のアカウント。請求の集約先で、メンバーアカウントに対する強い権限を持つ
・メンバーアカウント: Organizationsに参加した個別のAWSアカウント。SCPが適用される対象
・Root: 組織のトップにある仮想的な階層。ここにSCPを適用すると全アカウントに効く
・OU（Organizational Unit）: アカウントをグルーピングする論理単位。OU単位でSCP適用が可能
・SCP（Service Control Policy）: 「許可の上限」を定義するポリシー。IAMポリシーで許可されていてもSCPで拒否されればアクションは実行できない

2. 推奨されるOU設計パターン

AWSが公式に推奨している「Multi-Account Strategy」では、以下のOU構成がベースラインとなります。

# 推奨OU構造（小〜中規模向け）
Root
 ├── Security OU
 │    ├── Log Archive Account（CloudTrail/Config集約）
 │    └── Audit Account（Security Hub・GuardDuty集約）
 ├── Infrastructure OU
 │    ├── Network Account（Transit Gateway・Direct Connect）
 │    └── Shared Services Account（Active Directory・DNS）
 ├── Workloads OU
 │    ├── Prod OU
 │    │    ├── prod-app1
 │    │    └── prod-app2
 │    └── NonProd OU
 │         ├── dev-app1
 │         └── stg-app1
 └── Sandbox OU
      └── sandbox-engineer-001

このパターンの肝は「Security OUを最初に切ること」と「ProdとNonProdをOUレベルで分離すること」です。SCPはOU単位で柔軟に適用できるため、後から「本番だけ特定のリージョンに絞る」「サンドボックスは高額サービスを禁止する」といった統制を追加しやすくなります。

SCP（Service Control Policy）の設計と書き方

SCPは、Organizations配下のアカウント・OUに対して「実行できるアクションの上限」を定める仕組みです。IAMポリシーが「個別ユーザーに何を許可するか」を定義するのに対し、SCPは「アカウント全体として何を絶対に禁止するか」を定義します。Rootユーザーに対しても効くため、ガバナンス上の最終防衛線として機能します。

1. SCPの基本ルール

・SCPは「許可」ではなく「許可境界の制限」: SCPでAllowしてもユーザーに権限は付かない。実際の権限付与はIAMで行う
・明示Denyが最強: SCPでDenyすればIAMで何を許可していても拒否される
・管理アカウントには適用されない: 管理アカウントはSCPの対象外。管理アカウントで本番ワークロードを動かさない理由のひとつ
・サービスリンクロールには適用されない: AWSサービスが内部的に作成するロールにはSCPが効かない

2. 実務でよく使うSCPサンプル

以下は本番OUに適用する代表的なSCPの例です。「東京リージョン以外を全面禁止」「特定の高額サービスをブロック」「CloudTrail停止操作を禁止」などをカバーします。

# 本番OU向けSCPサンプル（JSON）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideTokyo",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "cloudfront:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    },
    {
      "Sid": "DenyDisableCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

NotActionでIAMやRoute53などのグローバルサービスを除外している点に注意してください。これらをDenyに含めるとアカウント自体が壊れます。

3. SCP適用時の必須チェック項目

本番アカウントに新しいSCPを当てる前に、必ず以下を確認します。

・テスト用OUで先に検証: サンドボックスOUに同じSCPを当て、想定外の動作がないか1週間ほど観察
・CloudTrailで影響範囲確認: Athena等で過去ログを検索し、Denyされる予定のアクションが現実に呼ばれていないか確認
・ロールバック手順を準備: SCPは即時反映されるため、問題があった場合の差し戻しスクリプトを事前に用意
・変更履歴をGit管理: SCPはYAML/JSONをGitリポジトリで管理し、レビュー必須にする

一括請求（Consolidated Billing）の仕組みとコストメリット

Organizationsの設立時に自動で有効化される一括請求は、地味ながら最大の即効性メリットです。請求が管理アカウントに集約されるだけでなく、ボリュームディスカウントが組織全体で適用されるため、アカウントを分けてもコスト効率は落ちません。

1. 一括請求で何が起きるか

・請求書の集約: メンバーアカウントの利用料が管理アカウントに合算される
・S3ボリュームディスカウントの統合: 各アカウントの転送量を合算して階段料金が適用される
・リザーブドインスタンスの共有: 1アカウントで購入したRIを他のアカウントが利用可能（無効化も可）
・Savings Plansの組織横断適用: Compute Savings Plansは複数アカウントで割引が適用される

2. コスト試算の実例

例として、本番・開発・検証・監査の4アカウント構成で、毎月以下の利用がある場合を考えます（2026年4月時点のap-northeast-1料金、概算）。

上記のケースでは、S3だけで月$512、年間で約$6,000の差が出ます。RIやSavings Plansの共有を含めれば、年間数十万円〜数百万円の差につながることも珍しくありません。

マルチアカウント運用の実務Tips

1. アカウント新設時のチェックリスト

新しいAWSアカウントをOrganizationsに追加するとき、以下を漏れなく実施してください。

・適切なOUに配置: 仮置きでRoot直下に置くと、後で移動するのが面倒になる
・CloudTrail有効化確認: 組織の証跡（Organization Trail）が新アカウントを自動カバーしているか確認
・GuardDutyの委任有効化: 監査アカウントから新アカウントの脅威検知を有効化
・Config記録の有効化: リソース構成の変更追跡を最初から有効化
・請求アラート設定: 想定外コスト発生に備えてBudgetsで月額アラートを設定
・IAM Identity Centerの権限割り当て: Permission SetをアタッチしてSSO経由でアクセス可能にする

2. CLI操作の基本コマンド

# AWS CLI: 組織情報の確認
aws organizations describe-organization

# 全アカウント一覧
aws organizations list-accounts

# OU一覧
aws organizations list-organizational-units-for-parent --parent-id r-xxxx

# 新規アカウント作成
aws organizations create-account \
  --email new-account@example.com \
  --account-name "prod-app3"

# アカウントを別OUに移動
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-xxxx-yyyy

# SCPの適用
aws organizations attach-policy \
  --policy-id p-xxxxxxxx \
  --target-id ou-xxxx-yyyy

3. Control Towerと併用するか単独運用するか

AWSにはOrganizations上に統制機能を上乗せする「AWS Control Tower」というサービスがあります。両者の使い分けは以下が目安です。

2026年時点での実務感覚としては、5〜10アカウントまでならOrganizations単独で十分、それ以上になるならControl Towerを最初から入れるのが近道です。

よくあるトラブルと対処法

1. SCPが効かない

「SCPで禁止したはずなのにアクションが実行できる」という相談が最も多いトラブルです。原因の8割は以下のどれかです。

・管理アカウントで操作している: 管理アカウントはSCPの対象外。メンバーアカウントで再現確認する
・SCPがOUに紐付いていない: ポリシーを作っただけで、attachを忘れているケース
・FullAWSAccessの解除を忘れている: デフォルトで全許可のSCPが付いており、これを残したまま個別Denyを書いても通る
・サービスリンクロールでの操作: AWSサービスが裏で動かすロールはSCP対象外

2. アカウントを組織から外せない

メンバーアカウントを脱退させようとして「失敗する」場合、ほとんどが「個別の支払い情報が登録されていない」のが原因です。組織に参加した時点で支払いが管理アカウントに集約されているため、脱退時には独立した請求情報の再登録が必要です。サポート経由で対応するケースもあります。

3. 請求書が想定より高い

一括請求でコスト最適化されるはずなのに、月末の請求が予算を超えるケース。管理アカウントのCost Explorerで「Linked Account」別に分解し、どのアカウントで何が動いているかを特定します。サンドボックスOUでEC2が放置されている、開発アカウントでRDSが起動しっぱなし、といった事故が定番です。

4. Service Quotaに引っかかる

OrganizationsそのもののQuotaも存在します。デフォルトではアカウント数の上限が10程度に設定されているため、20アカウント以上に拡張する場合は事前にService Quotasから引き上げ申請が必要です。承認まで数日かかることもあるので、計画的に申請してください。

FAQ

Q1. すでに複数のAWSアカウントを個別に持っているが、後からOrganizationsにまとめられる？

はい、可能です。新しく管理アカウントを作るか既存アカウントの1つを管理アカウントに昇格させ、他のアカウントを招待する形でOrganizationsに参加させます。請求情報や既存リソースは保持されます。

Q2. 管理アカウントで本番ワークロードを動かしてもいい？

強く非推奨です。管理アカウントはSCPが効かないため、誤操作や侵害時の影響が組織全体に及びます。管理アカウントは「Organizations管理と請求のみ」に専念させ、ワークロードは必ずメンバーアカウントで動かしてください。

Q3. SCPとIAMポリシーはどちらを優先して設計すべき？

SCPは「組織として絶対に許さないこと」だけを定義し、個別の権限はIAMで設計するのがセオリーです。SCPを細かく書きすぎると保守不能になります。「本番リージョン制限」「監査ログ削除禁止」「組織離脱禁止」など、最低限の3〜5項目から始めましょう。

Q4. Organizationsを使うとコストはかかる？

Organizations自体は無料です。ただし、CloudTrailの組織証跡やConfigの組織集約を有効にすると、それぞれのサービス利用料が発生します。Control Towerを併用する場合も同様にCloudTrail/Configの料金が発生します。

Q5. オンプレADと連携してSSOしたい場合は？

AWS IAM Identity Center（旧AWS SSO）をOrganizationsの管理アカウントで有効化し、外部IdP（Active DirectoryやAzure ADなど）と連携させます。これにより、ユーザーは1度のサインインで配下の全AWSアカウントにPermission Set経由でアクセスできます。詳しくは姉妹記事のIAM Identity Center入門も参照してください。

Q6. SCPで「全リージョン禁止して東京だけ許可」にしたら全部壊れた

NotActionでグローバルサービス（IAM、Route53、CloudFront、Support、Organizations自身など）を除外していないのが原因です。これらはエンドポイントが特定リージョンにしか存在しないため、Region条件で全弾きされるとアカウント操作自体ができなくなります。本記事のSCPサンプルを参考に、必ずNotActionで除外してください。

Q7. 何アカウントから分割管理すべきか？

3アカウント以上になったらOrganizationsの導入を強く推奨します。本番1・開発1・検証1の最小構成でも、CloudTrail集約・SCP適用・一括請求のメリットは十分に得られます。逆に1〜2アカウントでは過剰投資になりがちです。

Q8. Control Towerに移行したら今のOrganizationsは壊れる？

既存のOrganizationsにControl Towerを後付けで導入できます。ただし、既存のOU構造やSCPはControl TowerのLanding Zone構造と整合させる必要があり、数日〜数週間の設計・移行作業を見込んでください。本番運用中の組織で大規模変更する場合は、AWS Professional Servicesやパートナーへの相談も選択肢です。

本記事のまとめ

AWS Organizationsは、複数アカウント運用が前提となった現代のクラウドにおいて、ガバナンス・セキュリティ・コスト管理を一元化するための土台です。オンプレADでドメイン・OU・GPOを設計してきた経験は、Organizationsの構造設計にそのまま活きます。違いは「アカウント追加が数分で終わる」「SCPは許可ではなく境界の制限である」「請求が組織横断で最適化される」という3点です。

導入の進め方は、①最初にSecurity OUとログ集約アカウントを切る、②本番・開発・サンドボックスをOUで分離する、③ガードレールとなる最低限のSCPを当てる、④一括請求のメリットを享受する、という順序が王道です。10アカウントを超えるならControl Towerの併用も視野に入れてください。

クラウドセキュリティの基礎については、姉妹サイトのSecurityMaster.JPでも詳しく解説しています。Linuxサーバーを各アカウントで動かす際の運用ノウハウはLinuxMaster.JPを参照してください。