メインコンテンツまでスキップ

AWS Organizations とは?マルチアカウント管理の基本を学ぼう

タグ:

AWS を本格的に活用するようになると、環境ごとにアカウントを分けたい、複数チームで別々のアカウントを使いたいという場面が出てきます。AWS Organizations はそのような複数の AWS アカウントを一元管理するためのサービスです。本記事では Organizations の基本概念から実際の使い方まで説明します。

AWS Organizations とは

AWS Organizations は複数の AWS アカウントをまとめて管理するためのサービスです。アカウントをグループ化して階層構造で整理したり、全アカウントへのポリシー適用や請求の一元化ができます。

開発・ステージング・本番のように環境ごとにアカウントを分けることで、リソースの分離やコスト管理がしやすくなります。また、セキュリティポリシーを組織全体に強制的に適用できるため、ガバナンス強化にも役立ちます。

主要コンポーネント

Organizations は以下のコンポーネントで構成されています。それぞれの役割を理解しておくことが運用の第一歩です。

コンポーネント説明
組織 (Organization)複数の AWS アカウントをまとめる最上位の単位。1 つの組織に 1 つの管理アカウントが存在する
管理アカウント (Management Account)組織を作成・管理するアカウント。他のアカウントの招待や OU・ポリシーの管理を行う
メンバーアカウント (Member Account)組織に所属している管理アカウント以外の AWS アカウント
ルート (Root)組織内の階層構造の最上位ノード。すべての OU とアカウントの親となる
組織単位 (OU)アカウントをグループ化するためのコンテナ。OU にポリシーを適用するとその配下のアカウントすべてに影響する
サービスコントロールポリシー (SCP)OU やアカウントで許可・拒否する操作を定義する JSON ポリシー。IAM の上位で機能する

組織にアカウントを追加する方法は 2 通りあります。1 つは管理アカウントから新規にアカウントを作成する方法、もう 1 つはすでに存在する AWS アカウントを招待して組織に参加してもらう方法です。招待されたアカウントの所有者が承諾すると、そのアカウントは組織のメンバーアカウントになります。

Organizations で扱えるポリシーは SCP だけではないです。リソースへのタグ付けルールを強制するタグポリシーや、AWS Backup のバックアップ計画を組織全体に適用するバックアップポリシーなど、用途に応じたポリシータイプが用意されています。組織の作成時に有効化する機能セット(ALL または CONSOLIDATED_BILLING)によって使えるポリシータイプが変わる点にも注意しましょう。

組織単位(OU)の設計

OU は組織の骨格となる部分です。用途に合わせた階層設計を行うことで、ポリシー管理が大幅に楽になります。

よく使われる設計パターンとして、環境ごとに OU を分ける方法があります。たとえば「Production」「Staging」「Development」という OU を作成し、それぞれに本番・ステージング・開発環境のアカウントを入れます。

Root
├── Production
│ └── account-prod
├── Staging
│ └── account-staging
└── Development
└── account-dev

別のアプローチとして、部門・チームごとに OU を分ける方法もあります。組織の規模やガバナンスの要件に応じて選びましょう。

サービスコントロールポリシー(SCP)

SCP は組織全体または特定の OU・アカウントに対して許可・拒否する操作を定義するポリシーです。IAM ポリシーより上位で機能するため、たとえ管理者権限の IAM ユーザーであっても SCP で拒否されている操作は実行できないです。

SCP には以下のような用途があります。

用途SCP の例
利用リージョンの制限東京リージョン以外での操作を拒否する
特定サービスの無効化本番環境での EC2 の削除を拒否する
ルートユーザー操作の制限メンバーアカウントのルートユーザーによる操作を拒否する
コスト超過の防止高コストなインスタンスタイプの起動を拒否する

SCP はあくまで「上限」を定めるものであり、SCP で許可しただけでは操作できないです。実際の権限付与は引き続き IAM ポリシーで行います。SCP で許可されており、かつ IAM ポリシーでも許可されている場合のみ操作が可能です。

一元請求(Consolidated Billing)

Organizations を使うと、組織内のすべてのアカウントの利用料金を管理アカウントに集約して支払えます。メンバーアカウントごとに請求先を分ける必要がなくなるため、経理処理の手間が減ります。

一元請求のもう一つの利点は、ボリュームディスカウントや Savings Plans、リザーブドインスタンスの割引を組織全体で共有できる点です。たとえば、複数のメンバーアカウントで EC2 を使っている場合、アカウントごとの利用量が合算されるため、単独のアカウントでは届かない割引段階に到達しやすくなります。購入したリザーブドインスタンスの割引も、条件を満たす他のアカウントの使用量に自動的に適用されます。

AWS CLI で Organizations を操作してみる

AWS CLI を使って組織の情報を確認する基本的な操作を試してみましょう。操作には Organizations の読み取り権限が必要です。また、以下のコマンドは既存の組織が作成済みであることを前提としています。組織の作成は AWS マネジメントコンソールの Organizations ページから行えます。

組織情報の確認

現在の組織情報を取得します。管理アカウント ID や組織 ID を確認できます。

❯ aws organizations describe-organization
{
"Organization": {
"Id": "o-0a1b2c3d4e5f",
"Arn": "arn:aws:organizations::123456789012:organization/o-0a1b2c3d4e5f",
"FeatureSet": "ALL",
"MasterAccountArn": "arn:aws:organizations::123456789012:account/o-0a1b2c3d4e5f/123456789012",
"MasterAccountId": "123456789012",
"MasterAccountEmail": "admin@example.com",
"AvailablePolicyTypes": [
{
"Type": "SERVICE_CONTROL_POLICY",
"Status": "ENABLED"
}
]
}
}

アカウント一覧の取得

組織に所属しているアカウントの一覧を確認します。アカウントの名前・ステータス・参加日時なども取得できます。

❯ aws organizations list-accounts
{
"Accounts": [
{
"Id": "210987654321",
"Arn": "arn:aws:organizations::123456789012:account/o-0a1b2c3d4e5f/210987654321",
"Email": "sandbox@example.com",
"Name": "Sandbox",
"Status": "ACTIVE",
"State": "ACTIVE",
"Paths": [
"o-0a1b2c3d4e5f/r-0a1b/ou-0a1b-2c3d4e5f/210987654321/"
],
"JoinedMethod": "CREATED",
"JoinedTimestamp": "2024-01-01T00:00:00.000Z"
},
{
"Id": "123456789012",
"Arn": "arn:aws:organizations::123456789012:account/o-0a1b2c3d4e5f/123456789012",
"Email": "admin@example.com",
"Name": "Production",
"Status": "ACTIVE",
"State": "ACTIVE",
"Paths": [
"o-0a1b2c3d4e5f/r-0a1b/ou-0a1b-6e7f8a9b/123456789012/"
],
"JoinedMethod": "INVITED",
"JoinedTimestamp": "2023-01-01T00:00:00.000Z"
}
]
}

OU の一覧取得

ルートの ID を取得してから、配下の OU を一覧表示します。まず list-roots でルート ID を確認し、その ID を使って OU を照会します。

❯ aws organizations list-roots
{
"Roots": [
{
"Id": "r-0a1b",
"Arn": "arn:aws:organizations::123456789012:root/o-0a1b2c3d4e5f/r-0a1b",
"Name": "Root",
"PolicyTypes": []
}
]
}

ルート ID を使って配下の OU を確認します。

❯ aws organizations list-organizational-units-for-parent --parent-id r-0a1b
{
"OrganizationalUnits": [
{
"Id": "ou-0a1b-2c3d4e5f",
"Arn": "arn:aws:organizations::123456789012:ou/o-0a1b2c3d4e5f/ou-0a1b-2c3d4e5f",
"Name": "Sandbox",
"Path": "o-0a1b2c3d4e5f/r-0a1b/ou-0a1b-2c3d4e5f/"
},
{
"Id": "ou-0a1b-6e7f8a9b",
"Arn": "arn:aws:organizations::123456789012:ou/o-0a1b2c3d4e5f/ou-0a1b-6e7f8a9b",
"Name": "Production",
"Path": "o-0a1b2c3d4e5f/r-0a1b/ou-0a1b-6e7f8a9b/"
}
]
}

アタッチされている SCP の確認

特定の OU やアカウントにどの SCP がアタッチされているかは list-policies-for-target で確認できます。--target-id に OU やアカウントの ID、--filter にポリシータイプを指定します。

❯ aws organizations list-policies-for-target --target-id ou-0a1b-6e7f8a9b --filter SERVICE_CONTROL_POLICY
{
"Policies": [
{
"Id": "p-examplepolicyid",
"Arn": "arn:aws:organizations::123456789012:policy/o-0a1b2c3d4e5f/service_control_policy/p-examplepolicyid",
"Name": "DenyLeaveOrganization",
"Description": "",
"Type": "SERVICE_CONTROL_POLICY",
"AwsManaged": false
}
]
}

意図せず適用されている SCP に気づかず、必要な操作が拒否されて原因調査に時間がかかることもあるため、OU の階層を変更する際はアタッチ状況を確認しておくと安心です。特に、上位の OU にアタッチした SCP は配下のすべての OU・アカウントに継承されるため、階層を深くするほど影響範囲の把握が難しくなる点に注意しましょう。

まとめ

AWS Organizations の基本概念から OU・SCP の設計、一元請求、CLI での操作方法まで説明しました。複数のアカウントを扱うようになったら、以下のポイントを押さえて組織の管理に取り入れてみましょう。

  • AWS Organizations は複数の AWS アカウントを一元管理するサービスで、請求の集約や組織全体へのポリシー適用が可能
  • OU を使ってアカウントを階層構造でグループ化することで、環境や部門ごとの管理がしやすくなる
  • SCP は IAM の上位で機能し、OU やアカウントに対して操作の上限を定めるポリシー
  • SCP で許可された操作であっても、IAM ポリシーでの権限付与は引き続き必要
  • 一元請求を使うと、ボリュームディスカウントや割引を組織全体で共有できる
  • AWS CLI を使って組織の情報確認や OU の一覧取得、SCP のアタッチ状況の確認が可能