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

![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/d8fbd4d3-5df6-4750-a002-00df0d8af702.png)

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

:::note info
ちなみにOrganizationsとは関係ないですが、**AWS Well-Architected フレームワーク セキュリティの柱にてマルチアカウント戦略が推奨**されています。
>マルチアカウント戦略を取り、環境 (本番稼働、開発、テストなど) とワークロードの間に共通ガードレールを構成し、分離を確立します。アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。
:::

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_securely_operate_multi_accounts.html

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

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


#### 構成要素
構成要素は以下の通りです。
![画像4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/9a17d6ab-ae2a-46ab-afc0-8ae1e6be45d3.png)

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

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

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

https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous-and-accounts.html

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

https://blog.serverworks.co.jp/recommended-ous


### 実践
それでは実践していきましょう！
既にAWSアカウントを１つ所有していることを前提に進めていきます。
Before/Afterは以下のようにします。
![画像2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/b1045c84-4b9a-4b1b-9532-7fcc50b2f92a.png)

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

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html#best-practices_mgmt-use

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

https://aws.amazon.com/jp/register-flow/

:::note warn
アカウント作成が完了したら、<font color="Red">**真っ先にrootユーザーのMFAを有効化すること**</font>をお勧めします。
:::

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

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

#### Organizations有効化(組織を作成)
まず組織を作成しましょう。
新規作成したAWSアカウントに**AdministratorAccess**がアタッチされたIAMユーザーでログインした状態です。
Organizationsのサービスページに遷移します。
![画像8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/ee10fac5-b582-47d8-ab66-aac6e74a370d.png)

サービスページ遷移後、「**組織を作成する**」をクリックします。
![画像9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/60865afd-987d-4da2-98f8-5e64de388641.png)

正常に組織が作成されると、有効化したアカウントが管理アカウントとしてルートの直下に表示されます。
![画像10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/66fe6061-8bf4-4dfa-ab59-19406fbe8f8d.png)

:::note info
##### 機能セットはデフォルトで「全ての機能」になっていた
[AWS Organizations](#aws-organizations)の章で記載した通り、有効化する際に選択するかと思っていましたがそうでもなかったみたいです。
![画像11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/22fba029-5e79-492f-9cdb-426ba39cde87.png)

##### ポリシーは全て無効になっている
初期状態では、全てのポリシーが無効になっていました。
![画像12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/98aa750c-2705-4822-afb9-50b9f071ce27.png)
:::

現状は以下の通りです。
![画像13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/acb7dabe-d101-4151-aac7-aba9bb6a50bc.png)


#### OU作成
続いてOUを作成していきましょう。
今回はルート直下にOUを作成していきますので、ルートにチェックを入れて、「アクション」→「新規作成」をクリックします。
![画像14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/49b63088-8f20-4990-9f81-6b81951ce1c5.png)

OU名を記入し「組織単位の作成」をクリックします。
![画像15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/0d24ad64-01c1-4067-9d53-9e80346bd998.png)

OUが作成されました。同じ要領で他のOUも作成していきます。
![画像16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/ebbde5ec-6c3b-40f7-b14f-9c93f1aae2f0.png)

作成したOUはこちらです。
![画像17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/4ed5a0e0-893a-4bab-9034-f6efc6d3b2b3.png)

現状は以下の通りです。
![画像18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/a73ebe91-f452-47ab-989b-5f78fb239387.png)


#### メンバーアカウント招待
続いて、既に所有しているAWSアカウントを組織に招待していきましょう。
Organizationsサービスページの左ペイン「招待」から、「AWSアカウントを招待」をクリックします。
![画像19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/01ee2771-cf06-4ce5-8d2f-fcf2af12ceca.png)

「既存のAWSアカウントを招待」が選択されていることを確認し、招待するAWSアカウントIDを入力後、「招待を送信」をクリックします。
![画像20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/00386460-7b50-4662-848d-9e67ef6d265b.png)

Invitationのメールが**招待されたアカウントのメールアドレス**に届きます。
![画像22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/00a594af-8af3-45d3-b257-5b769810498a.png)

:::note info
ちなみにですが、メール内に記載のあるロールはメンバーアカウントにて機能セットの「全ての機能」を有効化するために必要なサービスリンクロールです。
>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.

:::

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html


**招待されたアカウントに管理者権限のあるIAMユーザーでログイン**しOrganizationsサービスページに遷移すると、招待がある旨の記載があるためクリックします。
![画像23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/70000438-779b-4118-859c-b3b1c2bf315a.png)

招待に関する詳細が記載されているため、内容に問題がなければ「招待を承認する」をクリックします。
![画像24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/d421cff8-4da2-4ad1-8f59-8e4a4897c977.png)

**管理アカウントのOrganizationsサービスページ**に戻ると、招待したアカウントが参加済みになっていることが確認できます。
![画像25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/d290b9b3-f29f-45d8-b38c-9cf9b908788d.png)

#### メンバーアカウントをOU配下に移動
招待承認直後は、ルート直下にメンバーアカウントがいます。そのため、今回は指定のOUに移動させます。
対象のメンバーアカウントにチェックを入れ、「アクション」→「移動」をクリックします。
![画像26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/94f183aa-6300-4a08-902a-b570185a293c.png)

組織内のOU一覧が表示されるので、移動先のOUにチェックを入れ「AWSアカウントを移動」をクリックします。
![画像27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/68597d14-c6a6-49f7-be8b-c0361f06a0c3.png)

今回はWorkloads OU配下に移動させました。
![画像28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/d7ff609b-e287-4273-b6b2-7baaadc01c97.png)

現状は以下の通りです。
![画像29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/e9fad8bf-d00a-431c-9d9e-b60a765cf1d7.png)

#### SCP有効化
続いてSCPを有効化していきます。
ポリシーから「サービスコントロールポリシー」をクリックします。
![画像30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/001f027a-80a7-4ecb-8dc6-e57367ea70fd.png)

「サービスコントロールポリシーを有効にする」をクリックします。
![画像31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/d017cbfb-c037-42e8-9296-919ddb30b01e.png)

有効化されると「FullAWSAccess」というAWSマネージドのSCPが自動で作成されます。
![画像32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/3fef6277-8ce0-4729-8f9f-8592d8c2c128.png)

そのタイミングで組織内のルート/管理アカウント/OU/メンバーアカウントにアタッチされます。
![画像33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/139d8523-9a2a-4727-8c87-a22df0ee4885.png)

現状は以下の通りです。
![画像34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/51326237-c0e5-4d5b-ab12-f1fcdd030de8.png)


#### メンバーアカウントのrootユーザー制限用SCP作成
最後にせっかくなのでrootユーザーを制限するSCPを作成していきましょう。

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

サービスコントロールポリシーページにて「ポリシーを作成」をクリックします。
![画像35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/74f9a2a6-7969-4308-aa00-a6150c30e978.png)

以下項目を入力し「ポリシーを作成」をクリックします。
|項目|値|
|:-|:-|
|ポリシー名(任意名称)|DenyRootUser|
|ポリシーの説明(任意文)|SCP to deny all operations by root user|
|ステートメント|下記記載|

```json:ステートメント
{  
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "*"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:root"
          ]
        }
      }
    }
  ]
}
```

カスタマー管理ポリシーが作成されるので、チェックを入れ、「アクション」→「ポリシーのアタッチ」をクリックします。
![画像36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/ea460c47-e38d-4220-a6ce-d9f0228be182.png)

今回は全てのOU/メンバーアカウントに適用したいので、ルートにアタッチし継承させます。
ルートにチェックを入れ、「ポリシーのアタッチ」をクリックします。
![画像37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/3f10421c-e88c-4589-9d9c-d71bdcb26383.png)

:::note info
ちなみに、管理アカウントに直接アタッチしようとするとエラーになります。
![画像38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/3fece78c-9d6f-48a5-9080-dd5f4832e58a.png)
:::

:::note info
実際、**ルートにポリシーをアタッチ**すると階層的に**管理アカウントに継承**されます。
![画像39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/30e1b54d-d390-486c-9205-b1e95cb0c6a5.png)

しかし、公式にも記載がある通り、どのようなポリシーが管理アカウントに適用されても、**管理アカウントによって実行されるすべてのアクションは制限されません**。
>SCPs を使用して以下のタスクを制限することはできません。
>* 管理アカウントによって実行されるすべてのアクション
:::

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html


記載は省略させていただきますが、メンバーアカウントにてrootユーザーでログインすると、全てのアクションができなくなっています。
ただし、上記のリンクでも記載がある通り、**rootユーザーでの一部の操作は制限できません**。
最終的に以下のようになりました。
![画像41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/288e54e9-a20c-4ad6-9442-7ee68eba6f0c.png)


### まとめ
今回は、AWS Organizationsの世界に足を踏み入れようということで記事にしてみました！
今後はOrganizationsに関する設定や機能について少しずつ試して備忘録を残していこうかなと思います。

### 補足
#### アカウント用メールアドレス作成(Gmailエイリアス)
今後Organizationsにてメンバーアカウントを作成する際に、アカウント毎にメールアドレスが必要になります。
その際にメールアドレスを複数作成する必要がありますが、その方法の一つとしてGmailのメールエイリアスがあります。参考程度に記載しておきます。

##### 1. Gmailにログイン
ご自身のPCで[Gmail](https://accounts.google.com/ServiceLogin?hl=ja&service=mail)にログインします。

##### 2. 画面右上の「歯車マーク」をクリック
![画像3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/1eb7db86-d58a-44ad-b770-177c11d9c7f8.png)

##### 3. 「すべての設定を表示」をクリック
![画像4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/984dbcc9-5b1a-450a-947e-911b8f3fbaed.png)

##### 4. 「アカウントとインポート」をクリック
![画像5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/d1ff3931-a2d5-4980-9cc0-2dbaa5d872e7.png)

##### 5. 「他のメールアドレスを追加」をクリック
![画像6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/21a9e4bc-ca30-4a73-ae2e-4cc589d30558.png)

##### 6. メールアドレスを追加
情報入力のポップアップ画面が表示されるため、「名前」「メールアドレス」を入力し、「エイリアスとして扱います。」にチェックを入れて「次のステップ」をクリックします。
以上で完了です。
![画像7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3984127/4cf21416-ad33-4d47-99d5-ca81d6266079.png)

参考までに、メールアドレス形式についての記事を掲載させていただきます。

https://mailwise.cybozu.co.jp/column/140.html

### 参考文献
#### リファレンス
* [AWS Organizations ユーザーガイド](https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_introduction.html)
* [AWS Black Belt - AWS Organizations -](https://pages.awscloud.com/rs/112-TZM-766/images/20180214_AWS-Blackbelt-Organizations.pdf)
* [AWS Organizationsで使用できるAWSサービス](https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_integrate_services_list.html)
* [AWS Whitepaper - Recommended OUs and accounts -](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous-and-accounts.html)
#### ブログ
* [AWS Organizationsの委任管理者アカウントについて調べてみた](https://dev.classmethod.jp/articles/multi-account-tips-delegated-administrator/#toc-)
* [Best Practices for Organizational Units with AWS Organizations](https://aws.amazon.com/jp/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)
* [AWSのホワイトペーパーから学ぶ AWS Organizations における推奨 OU 構成](https://blog.serverworks.co.jp/recommended-ous)