[実践]AWS Organizationsの世界に足を踏み入れよう！

Posted at 2025-02-16

概要

AWSを利用した大規模案件となると、AWSアカウントを複数利用するマルチアカウントが一般的かと思います。そういったケースでは、マルチアカウントを管理するサービスとしてAWS Organizations(以降、Organizations)を利用するのが大半です。
ただ、Organizationsの機能をゴリゴリ使ってマルチアカウント管理を経験することはなかなかできません。僕もその一人です。
そこで今回は、Organizationsの世界に足を踏み入れようと思います。Organizations自体は無料で、AWSサポートプランによる制限もないため個人利用の環境でも使用可能です。

ちなみにOrganizationsとは関係ないですが、AWS Well-Architected フレームワークセキュリティの柱にてマルチアカウント戦略が推奨されています。

マルチアカウント戦略を取り、環境 (本番稼働、開発、テストなど) とワークロードの間に共通ガードレールを構成し、分離を確立します。アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。

AWS Organizations

Organizationsは、複数のアカウントを一元管理するためのサービスです。
Organizationsを構成する要素は後述します。
Organizationsを有効化する際、機能セットを選択します。選択肢は「Consolidated Billing Only(一括請求のみ)」「All Feature(全ての機能)」の２つです。各違いは以下の通りです。

	Consolidated Billing Only (一括請求のみ)	All Feature (全ての機能)
管理アカウントへの一括請求	〇	〇
メンバーアカウントの新規作成/招待/削除	〇	〇
ポリシーによる一元管理例. SCP, RCPs等	×	〇
選定基準	⽀払い代⾏のみ実施したい場合	マルチアカウントの統制を実施したい場合

構成要素

構成要素は以下の通りです。

構成要素	概要
組織	ルートを頂点に、階層的なOUにより木構造で整理された AWSアカウントの集合
ルート	管理アカウントに含まれ、階層的なOUの頂点となるコンテナ
管理アカウント	Organizationsを有効化したアカウント(変更不可) デフォルトはルート直下ですが任意のOUに移動可能 ✅以下実施可能 ● メンバーアカウントの新規作成/招待/削除/OU移動 ● OU作成/削除 ● ポリシーの作成/削除 ● ポリシーをルート/OU/メンバーアカウントにアタッチ・デタッチ ● 委任管理者アカウントの指定
OU	メンバーアカウントを束ねるグループ
メンバーアカウント	● 管理アカウント以外の組織に所属するAWSアカウント ● OU配下(推奨)/ルート直下(非推奨)に配置可能
委任管理者アカウント	● 一部のAWSサービスは組織全体で統合管理することが可能(≒OrganizationsとAWSサービスを統合する) ● 統合すると初期設定では管理アカウントにてサービスを管理する ● その管理を任意のメンバーアカウントに委任することが可能 ● 管理を委任されたアカウントを委任管理者アカウントと言う
ポリシー	許可/拒否を記載したドキュメントルート/OU/メンバーアカウント単位で適用する ✅大きく2つのポリシーに分けられる ● 承認ポリシー ● 管理ポリシー

カスタマー管理ポリシーは管理アカウントに直接アタッチできません
AWS管理ポリシーは管理アカウントにもアタッチされます
管理アカウントはポリシーで制御できません
ポリシーは階層構造の上位から継承されます
明示的な許可であり、ポリシーで宣言されていない場合は暗黙の拒否が働きます

推奨OU設計

OUの推奨設計が以下ホワイトペーパーで公開されています。
記載されている内容全て実装すべきということではなく、要件に合わせて取り入れていきましょう。

上記の内容を分かりやすくまとめてくださっているブログがありますので、掲載させていただきます。

実践

それでは実践していきましょう！
既にAWSアカウントを１つ所有していることを前提に進めていきます。
Before/Afterは以下のようにします。

既存のAWSアカウントにてOrganizationsを有効化し管理アカウントにするのでも良いです。
しかし既存のアカウントにはワークロード用のリソースが存在し、管理アカウントのベストプラクティス「組織の管理アカウントにワークロードをデプロイすることを避ける」に反すると考え、今回は初めに管理アカウント用のAWSアカウントを新規に作成し、そこでOrganizationsを有効化します。そして、既存のAWSアカウントを招待する形式で進めていきます。

管理アカウント用AWSアカウント作成

以下の公式サイトを参考にAWSアカウントを新規で作成します。
アカウント作成用のメールアドレスが無いよという方は補足を参考にしてみてください。

アカウント作成が完了したら、真っ先にrootユーザーのMFAを有効化することをお勧めします。

作成後、AdministratorAccessがアタッチされたIAMユーザーを作成し、以降の作業はIAMユーザーで実施します。

IAMユーザーのMFA有効化もお勧めします。

Organizations有効化(組織を作成)

まず組織を作成しましょう。
新規作成したAWSアカウントにAdministratorAccessがアタッチされたIAMユーザーでログインした状態です。
Organizationsのサービスページに遷移します。

サービスページ遷移後、「組織を作成する」をクリックします。

正常に組織が作成されると、有効化したアカウントが管理アカウントとしてルートの直下に表示されます。

機能セットはデフォルトで「全ての機能」になっていた

AWS Organizationsの章で記載した通り、有効化する際に選択するかと思っていましたがそうでもなかったみたいです。

ポリシーは全て無効になっている

初期状態では、全てのポリシーが無効になっていました。

現状は以下の通りです。

OU作成

続いてOUを作成していきましょう。
今回はルート直下にOUを作成していきますので、ルートにチェックを入れて、「アクション」→「新規作成」をクリックします。

OU名を記入し「組織単位の作成」をクリックします。

OUが作成されました。同じ要領で他のOUも作成していきます。

作成したOUはこちらです。

現状は以下の通りです。

メンバーアカウント招待

続いて、既に所有しているAWSアカウントを組織に招待していきましょう。
Organizationsサービスページの左ペイン「招待」から、「AWSアカウントを招待」をクリックします。

「既存のAWSアカウントを招待」が選択されていることを確認し、招待するAWSアカウントIDを入力後、「招待を送信」をクリックします。

Invitationのメールが招待されたアカウントのメールアドレスに届きます。

ちなみにですが、メール内に記載のあるロールはメンバーアカウントにて機能セットの「全ての機能」を有効化するために必要なサービスリンクロールです。

AWS Organizations verifies that every member account has a service-linked role named AWSServiceRoleForOrganizations. This role is mandatory in all accounts to enable all features. If you deleted the role in an invited account, accepting the invitation to enable all features recreates the role. If you deleted the role in an account that was created using AWS Organizations, that account receives an invitation specifically to recreate that role. All of these invitations must be accepted for the organization to complete the process of enabling all features.

招待されたアカウントに管理者権限のあるIAMユーザーでログインしOrganizationsサービスページに遷移すると、招待がある旨の記載があるためクリックします。

招待に関する詳細が記載されているため、内容に問題がなければ「招待を承認する」をクリックします。

管理アカウントのOrganizationsサービスページに戻ると、招待したアカウントが参加済みになっていることが確認できます。

メンバーアカウントをOU配下に移動

招待承認直後は、ルート直下にメンバーアカウントがいます。そのため、今回は指定のOUに移動させます。
対象のメンバーアカウントにチェックを入れ、「アクション」→「移動」をクリックします。

組織内のOU一覧が表示されるので、移動先のOUにチェックを入れ「AWSアカウントを移動」をクリックします。

今回はWorkloads OU配下に移動させました。

現状は以下の通りです。

SCP有効化

続いてSCPを有効化していきます。
ポリシーから「サービスコントロールポリシー」をクリックします。

「サービスコントロールポリシーを有効にする」をクリックします。

有効化されると「FullAWSAccess」というAWSマネージドのSCPが自動で作成されます。

そのタイミングで組織内のルート/管理アカウント/OU/メンバーアカウントにアタッチされます。

現状は以下の通りです。

メンバーアカウントのrootユーザー制限用SCP作成

最後にせっかくなのでrootユーザーを制限するSCPを作成していきましょう。

現在は、「ルートアクセス管理機能」により、メンバーアカウントのrootユーザーを無効化することが可能ですが、そちらは次回以降試したいと思います。

サービスコントロールポリシーページにて「ポリシーを作成」をクリックします。

以下項目を入力し「ポリシーを作成」をクリックします。

項目	値
ポリシー名(任意名称)	DenyRootUser
ポリシーの説明(任意文)	SCP to deny all operations by root user
ステートメント	下記記載

ステートメント

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