今回は、AWSを複数のアカウントで利用する際に欠かせないサービス「AWS Organizations」について、概要から基本概念、実際の設定手順まで順を追って紹介します。
AWS Organizationsとは
AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです。企業や組織では、開発・ステージング・本番といった環境ごとにAWSアカウントを分けて運用するケースが一般的です。こうした複数アカウントの管理を効率化し、セキュリティポリシーの一括適用や請求の統合を実現するのがAWS Organizationsの役割です。
たとえば、10個のAWSアカウントがあるとします。それぞれ個別に管理していると、セキュリティポリシーの適用漏れや請求確認の手間が大きくなります。AWS Organizationsを使えば、これらをひとつの「組織（Organization）」としてまとめて管理できるため、運用負荷を大幅に削減できます。
Active Directoryとの比較で理解するAWS Organizations
オンプレミス環境でのインフラ管理経験があるエンジニアの方は、Active Directory（AD）のドメインコントローラになじみがあると思います。AWS Organizationsは、このADと構造的によく似ており、AD経験者であれば直感的に理解しやすいサービスです。ここでは両者を比較しながら、AWS Organizationsの特徴を整理します。
似ている点
以下の表のとおり、用語や概念レベルで共通点が多く見られます。
| Active Directory（ドメインコントローラ） | AWS Organizations |
|---|---|
| ドメインでユーザー・PCを一元管理 | 組織でAWSアカウントを一元管理 |
| グループポリシー（GPO）で設定を強制 | SCP（サービスコントロールポリシー）で操作を制限 |
| OU（組織単位）でオブジェクトをグループ化 | OU（組織単位）でアカウントをグループ化 |
| フォレスト／ドメインの階層構造 | ルート → OU → アカウントの階層構造 |
OUという用語が両者に存在しているのは偶然ではなく、「組織を階層的に管理する」という設計思想が共通しているためです。ADの知識があれば、AWS OrganizationsのOU構造やポリシー適用の考え方はスムーズに理解できるでしょう。
異なる点
一方で、目的と管理対象が異なる点には注意が必要です。
- 管理対象が違う：ADはユーザーアカウントやコンピューターオブジェクトを管理しますが、AWS OrganizationsはAWSアカウント（＝クラウド環境そのもの）を管理します。
- 認証の役割は持たない：ADのドメインコントローラはログイン認証が主な役割のひとつですが、AWS Organizationsにはユーザーのログイン認証機能はありません。AWSへのサインイン管理は、IAM（Identity and Access Management）やIAM Identity Center（旧AWS SSO）が担います。
- ポリシーの対象が違う：GPOはユーザーやコンピューターの設定（デスクトップ設定、ソフトウェア配布など）を制御しますが、SCPはAWSサービスの利用可否（どのAWSサービス・操作を許可・拒否するか）を制御します。
整理するとこのようなイメージ
ADとAWSの対応関係をざっくり整理すると、次のようになります。
| Active Directoryの機能 | AWSの対応サービス |
|---|---|
| OU構造・GPOによるポリシー管理 | AWS Organizations（OU＋SCP） |
| ユーザー認証・シングルサインオン | IAM Identity Center（旧AWS SSO） |
| ユーザー・グループの権限管理 | IAM（ユーザー・ロール・ポリシー） |
ADの管理経験がある方は、「AWS OrganizationsはADのOU＋GPO部分に相当する」と捉えると理解が早まります。ログイン認証やユーザー管理については、IAMやIAM Identity Centerと役割を分担している点を押さえておきましょう。
AWS Organizationsの主な機能
AWS Organizationsには、大きく分けて以下の機能があります。
- 一括請求（Consolidated Billing）：複数アカウントの請求を1つの管理アカウントにまとめることができます。コストの可視化や管理が容易になります。
- サービスコントロールポリシー（SCP）：組織内のアカウントに対して、利用できるAWSサービスやアクションを制限するポリシーを適用できます。
- 組織単位（OU：Organizational Unit）：アカウントをグループ化して階層的に管理できます。部門や環境ごとにOUを作成し、それぞれにポリシーを適用できます。
- AWSサービスとの統合：AWS CloudTrail、AWS Config、AWS Security Hubなど、さまざまなAWSサービスと連携し、組織全体でのガバナンスを強化できます。
基本的な用語・概念の解説
管理アカウント（Management Account）
Organizations全体を管理するルートとなるAWSアカウントです。以前は「マスターアカウント」と呼ばれていました。組織の作成・管理、ポリシーの適用、メンバーアカウントの招待などを行います。管理アカウント自体は、組織内の他のアカウントから制御されることはありません。
メンバーアカウント（Member Account）
管理アカウントの配下に属するAWSアカウントです。新規作成または既存アカウントの招待によって組織に追加できます。実際の業務システムや開発環境など、用途ごとにメンバーアカウントを作成・管理します。
ルート（Root）
組織の階層構造における最上位のコンテナです。すべてのOUとアカウントは、このルートの配下に属します。ルートに対してSCPを適用すると、組織全体のすべてのアカウントにポリシーが適用されます。
組織単位（OU：Organizational Unit）
アカウントをグループ化するためのコンテナです。たとえば「開発OU」「本番OU」「セキュリティOU」などと分けて管理します。OUは階層構造（ネスト）にすることも可能で、柔軟な組織設計が行えます。
サービスコントロールポリシー（SCP）
組織またはOUに適用するポリシーです。IAMポリシーに似た記述形式で、特定のAWSサービスやアクションを許可・拒否できます。SCPはIAMポリシーと組み合わせて機能し、IAMで許可されていてもSCPで拒否されているアクションは実行できません。
AWS Organizationsの設定手順
ここからは、AWS Organizationsの基本的な設定手順を解説します。AWSマネジメントコンソールを使った操作を前提としています。
ステップ1：組織の作成
- AWSマネジメントコンソールにログインします。
- サービス検索で「Organizations」と入力し、AWS Organizationsを開きます。
- 「組織を作成」ボタンをクリックします。
- 確認画面が表示されるので、内容を確認して「組織を作成」を選択します。
これで組織が作成され、現在のアカウントが管理アカウントとなります。なお、一度作成した組織の管理アカウントは変更できないため、専用の管理アカウントを用意することをおすすめします。
ステップ2：メンバーアカウントの追加
既存アカウントを招待する場合：
- AWS OrganizationsのコンソールでAWSアカウントを選択します。
- 「招待を送信」をクリックします。
- 招待したいアカウントのIDまたはメールアドレスを入力し、招待を送信します。
- 招待されたアカウント側でサインインし、招待を承諾します。
新しいアカウントを作成する場合：
- AWS OrganizationsのコンソールでAWSアカウントを選択します。
- 「アカウントを追加」→「AWSアカウントを作成」をクリックします。
- アカウント名、メールアドレス、IAMロール名を入力して作成します。
ステップ3：OUの作成とアカウントの移動
- AWS OrganizationsのコンソールでAWSアカウントを選択します。
- 「ルート」を選択した状態で「組織単位を作成」をクリックします。
- OU名（例：「Dev」「Prod」「Security」）を入力して作成します。
- 作成したOUにアカウントをドラッグ＆ドロップ、またはアカウントを選択して「移動」から対象OUを指定します。
ステップ4：SCPの作成と適用
- AWS Organizationsコンソールの左メニューから「ポリシー」→「サービスコントロールポリシー」を選択します。
- 「ポリシーを作成」をクリックします。
- ポリシー名と説明を入力し、JSONエディタでポリシーを記述します。
- 作成したSCPを対象のOUまたはアカウントにアタッチします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-northeast-1"]
}
}
}
]
}上記のSCPを適用すると、対象アカウントでは東京リージョン（ap-northeast-1）以外でのAWSサービス操作が拒否されます。誤ったリージョンへのリソース作成を防ぐ際などに有効です。
AWS Organizationsを使う際の注意点
- 管理アカウントには通常業務を載せない：管理アカウントはOrganizations管理専用として使用し、業務システムのリソースは作成しないことがベストプラクティスです。
- SCPのDenyは強力：SCPでDenyを設定すると、管理者権限（AdministratorAccess）を持つIAMユーザーでも操作できなくなります。設定前に影響範囲をよく確認してください。
- 組織からの脱退には制限あり：管理アカウントが作成したアカウントは、一定期間（通常7日）が経過するまで組織から脱退できません。
- メールアドレスの管理：各メンバーアカウントには固有のメールアドレスが必要です。組織内アカウントの棚卸しと合わせて管理することをおすすめします。
まとめ
今回は、AWS Organizationsの概要・基本概念・設定手順について解説しました。Active Directoryに慣れ親しんだエンジニアの方にとっては、OU構造やポリシー管理の考え方が共通しているため、比較的スムーズに理解できるサービスです。一方で、ユーザー認証はIAM / IAM Identity Centerが担うなど、役割の分担がADとは異なる点も意識しておきましょう。
