【重要サービス】AWS Organizationsってどんなサービスで、どんな時使うの？ ～AWS100本ノック～ 25/100

# はじめに

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/13a38d41-a6a4-6ca1-7d22-ab45c41a0875.png)

**AWS Organizations**って知っていますか？
一言で言うと、**簡単に、マルチアカウントの管理・運用を出来るようにする**サービスです。

S3やLambdaなどと違い、開発者の方が触ることはほとんどなかったりするんですが、非常に重要なサービスなのでご紹介します。

:::note info
ちなみに、AWS Organizationsは無料で利用できます
:::

# アカウント管理(シングルアカウント戦略/マルチアカウント戦略)
まず、Organizationsの説明へ入る前に、アカウント管理について説明していきます。
アカウント管理方法としては、大きく分けて
- シングルアカウント戦略
- マルチアカウント戦略 ※個人利用じゃない場合は、基本こっちのはずです

の2つがあります。

## シングルアカウント戦略とは
その名の通り、1つのAWSアカウントで複数環境(開発/ステージング/本番etc)のAWSリソースを作成するやり方です。
※流石にクライアントの会社が違う場合は、AWSアカウントはみなさん分けていると思いますが...

以下のように環境毎にVPCを分けたりして運用していきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/9c4056b8-1890-0d8c-c58e-184712d92d22.png)


メリットとしては、全てのAWSリソースを1つのAWSアカウントで管理するため、シンプルで導入が楽という点になります。

ただ、以下のようにデメリットが非常に多いです。
- **リソース名の衝突**などを意識しないといけない
- (タグ付けでなんとかなりはするが)各環境でかかった**コストがわかりにくい**
- **AWSアカウントの上限のquota**を食いつぶし合うため、ステージング環境で過度に負荷をかけた際に本番環境で影響が出るかもしれない
- 開発環境のAWSリソースを削除しようとして、**誤って本番環境のAWSリソースを削除してしまう**などのリスクがある
- 権限周りなど、**セキュリティの統制**が取りづらくなる

## マルチアカウント戦略とは
マルチアカウント戦略では、プロジェクト毎・環境毎などでAWSアカウントを分離します。
シングルアカウントであげたデメリットが解消され、安心・安全に構築することが可能になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/2f6f3692-ddf7-90a3-1a31-d065bcc70a30.png)


ただ、AWSアカウントが増えれば増えるほど以下のデメリットが出てきます。
- **アカウント毎のアクセス・権限管理**を修正する際に、手間がかかる
- **アカウントごとのコスト**を各AWSアカウントに入らないと見られない
- ログなどが各AWSアカウントに存在するため、**運用が手間**

※`CloudFormation StackSets`(複数のアカウント・リージョンにCloudFormationsを展開し、AWSリソースデプロイするサービス)を利用すればある程度は楽になる部分はあります

こういったマルチアカウント戦略のデメリットを解消するためのサービスが**AWS Organizations**になります！

# AWS Organizationsの全体像
AWS Organizationsを構成する主要な概念は以下になり、これらをまとめて**組織**と呼びます。
組織は、AWS Organizations内で**1つのみ**作成することが出来ます。

- **管理ルート**
- **OU**
- **管理アカウント**
- **メンバーアカウント**
- **ポリシー**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/c2375b7f-980b-a31a-6ac7-a6b19f70152b.png)

では、それぞれについて説明していきます。

## 管理ルート
**組織階層の最上位**に当たり、AWSアカウントを整理するための出発点です。
管理ルートを起点に、OUを作成してグルーピングしていきます。

## OU
`Organizational Unit`の略で、**組織内のメンバーアカウントのグループ**になります。
OUには、メンバーアカウントを含めることが出来るのに加えて、OUも含めることが出来ます。
例えば、営業部・総務部のグループを作り各グループにAWSアカウントを所属させ、開発部のグループには開発部1課・開発部2課と子OUを作ったりします。
実際の会社・プロジェクトの構造、環境(開発/検証/本番)で階層化するイメージです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/40030416-52ba-2085-eb24-cbe1cad77890.png)


## 管理アカウント
**組織を管理する**アカウントになります。AWS Organizationsで組織を作成したアカウントがこれに当たります。
メンバーアカウントと違い、管理アカウントは組織内で**1つのみ**存在します。

管理アカウントでは、様々なことが出来るので、最小限のメンバーのみがアクセスできる形が望ましいです。
管理アカウントで出来ることについては、以降で説明します。

:::note warn
管理アカウントを組織内の別メンバーアカウントに変更することは出来ません
:::


## メンバーアカウント
メンバーアカウントは、今まで使っていた各AWSアカウントのことを指します。
管理ルート直下、または、OU配下にメンバーアカウントを作ります。

:::note warn
メンバーアカウントは1つの組織にのみ所属できます
:::


## ポリシー
組織内のグループ・アカウントに適用するポリシーのことで、**管理ポリシー**と**承認ポリシー**の2つがあり、それぞれ以下のポリシーから用途に応じて利用します。

- **管理ポリシー**
  - **宣言型ポリシー**：組織全体で特定のAWSサービスに対して必要な設定を一元的に宣言して適用できるようにするポリシー
  - **バックアップポリシー**：バックアッププランを一元管理し、組織のアカウント全体のAWSリソースに適用できるようにするポリシー
  - **タグポリシー**：組織のアカウントのAWSリソースにアタッチされたタグを標準化できるポリシー
  - **チャットボットポリシー**：SlackやTeamsなどのチャットアプリケーションから組織のアカウントへのアクセスを制御できるようにするポリシー
  - **AIサービスのオプトアウトポリシー**：組織内の全てのアカウントのAIサービスのデータ収集を制御できるポリシー
- **認可ポリシー**
  - **SCP(サービスコントロールポリシー)**：組織内のIAMユーザーとIAMロールが利用できるアクセス許可の最大数を一元的に制御できるポリシー
  - **RCP(リソースコントロールポリシー)**：組織内のリソースに対して使用可能なアクセス許可の最大数を一元的に制御できるポリシー

色々ポリシーの種類があるのですが、この中で一番よく使うSCPについて説明します

:::note info
管理ルートにポリシーをアタッチした場合は、
- 管理ポリシーをアタッチすると、`管理アカウントを含む`全てのOUとアカウント
- 認可ポリシーをアタッチすると、`管理アカウント以外の`全てのOUとアカウント

に適用されます。
:::

### SCP(サービスコントロールポリシー)とは
SCPは、IAM Policyと同様にjson形式のステートメントで定義し、管理ルート・OU・アカウントのいずれかにアタッチします。
デフォルトだと、**FullAWSAccess**というポリシーが全て(管理ルート・OU・アカウント)にアタッチされています。
FullAWSAccessでは、全てのリソースに対する全てのアクションを許可しています。
```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
```

ここでIAMポリシーと何が違うんだ？って思う方もいるかもしれませんね:smile:
SCPとIAMポリシーでは**目的や対象**が違います。

IAMポリシーは、
- AWSアカウント内のIAMユーザ・グループ・ロールなど**特定のIAMアイデンティティ**を対象
- 対象に**許可/拒否の権限の付与**をすることを目的

とします。一方、SCPは
- 管理ルート・OU・アカウント内の**全てのリソース**を対象とする
- 対象に**権限の境界設定**をすることを目的とする

となり、SCPの方が**上位**で設定されることになります。

以下の例だと、
- 管理ルート・OU・アカウントに`全てのリソース・全てのアクションを許可する境界のFullAWSAccess`がアタッチ
- 開発部1課(OU)にEC2の`全てのアクションを拒否するSCP-EC2Deny`がアタッチ
- AシステムアカウントのIAMユーザには、`全てのリソース・全てのアクションを許可するポリシー`がアタッチされています

この場合はどのような動きになるでしょうか？

Lambda関数の作成は、SCP・IAMポリシーの両方で許可されているため作成することが出来ます。
しかし、EC2インスタンスの作成はSCP-EC2Denyで拒否されているため、例えIAMポリシーで許可していても作成することは出来ません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/d9d4020c-5575-08ca-e819-b5c5ece2dfce.png)

このようなSCPとIAMポリシーの違いがあるのですが、FullAWSAccessが全てのOU・アカウントにデフォルトでアタッチされていることから想像するに、基本的にはSCPでは**FullAWSAccessで全てを許可**しつつ、**必要に応じて拒否のSCPをアタッチ**するのが良いと思います。
例：本番環境(OU)では、ログの削除は行えないようにする、CloudTrailの設定は特定のIAMユーザ以外は行えないようにする、など

:::note info
Organizationsのベストプラクティスとしては、OU単位でSCPのアタッチを行い、アカウントにはFullAWSAccessのみアタッチすることが推奨されています。

また、管理アカウントはSCPの影響を受けません。
:::

SCPには、継承という概念があるのですが、そちらに関しては別記事を書くようにいたします:bow:

# AWS Organizationsで出来ること
全体像を説明したところで、管理アカウントで出来るAWS Organizationsの機能について説明します。
主に、以下のことが出来ます。

- **AWSアカウントの一元管理**
- **組織外AWSアカウントの組織への招待**
- **管理ルート・OU・メンバーアカウントへのポリシーのアタッチ**
- **請求とコストの一元管理**
- **アカウント間のリソース共有**
- **サービスの統合**
- **サービス統合における管理者権限のメンバーアカウントへの委任**

## AWSアカウントの一元管理
OUの作成と削除を行い、**組織構造**を作ることが可能です。

また、各OUに所属する**メンバーアカウントの作成/削除**が行えます。
通常のアカウント追加と違い、メンバーアカウント追加時に**クレカ情報などが不要**で簡単に追加することが出来るのは良い点です。
**別OUへの移動/組織からの除外**も可能です。

## 組織外AWSアカウントの組織への招待
今までAWS Organizationsを使っていないで運用していた場合は、組織外のAWSアカウントが複数あることになります。これを組織に後から加えたい場合は**組織へ追加するための招待**を送ることが出来ます

## 管理ルート・OU・メンバーアカウントへのポリシーのアタッチ
先ほど説明したポリシー(SCPなど)を管理ルート・OU・アカウントにアタッチして**境界を設定**できます。

## 請求とコストの一元管理
今までは各アカウントで請求を管理していましたが、AWS Organizationsで**一元管理**することが可能です。
これによって、各AWSアカウントで支払設定をしたり請求情報を閲覧することが無くなり、請求処理や各アカウントの請求閲覧を**管理アカウントのみ**で行うことができるようになります。

:::note warn
請求処理を同一クレジットカードによって、一括で行うことによるクレジットカード上限オーバーには注意しましょう
:::

また、一括請求にすることによってEC2やRDSなどで**使用量による割引のボリュームディスカウント**を適用できる可能性があります。

今までは単一アカウントの使用量でしたが、Organizations配下のアカウント**合計の使用量**で、ボリュームディスカウントが適用されるか決まるためです。
さらに、リザーブドインスタンスとSavingPlansに関しても別アカウントと**割引の共有**を行うことも可能です。

## アカウント間のリソース共有
AWS RAM(Resource Access Manager)を利用して、組織全体・OU・アカウント内で**リソースの共有・管理**を行うことが出来ます。
S3バケットだったり、VPCだったり、DBだったりで本当は各アカウントで作る必要がなかったものがあれば、リソース共有することで**ランニングコスト・運用コスト**を削減することが出来ます

## サービスの統合
通常、各AWSサービスの管理やログは、各AWSアカウントで行いますがアカウントが増えれば増えるほど**運用の手間**が増えてきます。
そこで、**サービスの統合**を利用して、AWS Organizations配下のAWSアカウントで利用するAWSサービスのタスクをメンバーアカウントに変わって**代理実行し、集約管理**することができます。

統合できるサービス一覧は[こちら](https://blog.serverworks.co.jp/Integration-delegation)に記載があるのですが、以下のサービスはみなさん[統合](https://blog.serverworks.co.jp/Integration-delegation)しているようです。

- **CloudFormation StackSets**
  - 組織内の**複数アカウント・リージョンに**CloudFormationスタックを展開できる機能
  - 各環境で作りたいリソースを組織全体、または、指定した**OS配下のアカウントに一括で**作成することが可能
  - アカウント追加・削除時の、**自動デプロイ/削除機能**も利用可能
- **GuardDuty**
  - 組織内のログを分析して抽出された**脅威検出イベント**を集中管理
- **Secuity Hub**
　- 組織内の**複数のセキュリティサービスの検出結果**を集中管理
- **AWS Config**
  - 組織内のAWSリソース情報と、**ルールやコンプライアンスチェック**の集中管理
- **CloudTrail**
  - **組織内の証跡**(AWSアカウント内で実行されたアクションやイベント)の集中管理

:::note info
なお統合を有効化する際は、Organizationsのコンソール画面ではなく、各AWSサービスのコンソール画面かAWS CLIで行うのが良いそうです
[参考](https://dev.classmethod.jp/articles/cloudformation-stacksets-apis-organizations/)
:::

## サービス統合における管理者権限のメンバーアカウントへの委任
サービスを統合して集約出来るようになって、管理は非常に楽になりました。
しかし、管理アカウントは**非常に強い権限**を持っているため、管理アカウントにアクセスできる人は限定したほうが良いとされています。

しかし、これだけのサービスを少人数で管理するのは難しいかもしれませんし、CloudTrailやGuardDutyなどの監査・監視系の担当は別の人を立てたり外部の会社に頼むかもしれません。
そういった場合に、別のメンバーアカウントに**対象AWSサービスの管理を委任**することが出来ます。
これによって、不必要に管理アカウントにログイン出来るユーザを増やす必要もなく、責任を分離して安全に作業することが出来ます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/b7af2b62-6fcf-dcc6-ba0c-a7b6aed2384e.png)



# AWS Organizations利用が前提のサービス
以下のサービスは、AWS Organizationsを利用していないと利用することが出来ません。
簡単に紹介します！


## Control Tower
Control Towerは、AWS Organizationsや各種セキュリティサービスなどを自動的にセットアップし、マルチアカウント統制環境(Landing Zone)を簡単に構築できます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/9c81e558-d427-54f6-04a3-c52cfd8c890e.png)

## IAM Identity Center(旧名称：AWS SSO)
IAM Identity Centerでは、以下のことが出来ます。
- 組織内アカウントへのログインの簡素化(SaaSも可)
- 複数アカウントのアクセス制御の一元管理
- ユーザ管理(外部ID管理と連携可能)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/25ff3b4c-b7d2-3790-26f4-2c5ca035d0a1.png)

## AWS Firewall Manager
AWS Firewall Managerでｈ、AWS WAFやAWS Shield、セキュリティーグループなどを一元管理することが出来ます。
また、ベースラインを作成して監視し、違反した場合には自動的に更新するようなことも出来ます。

![スクリーンショット 2025-02-06 163713.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/73e729df-4349-a672-8aa6-a71887005704.png)


# おわりに
今回はマルチアカウントの管理・運用を簡単にする、AWS Organizationsについて説明しました。
複数アカウントを利用しているのにまだ使ってない、って方は是非利用することをお勧めします:smile: