AWS Organizations の AWS アカウントをすごく自動構築したかった話

AWS Organizations で AWS アカウントを多数作成する必要があったため、そのために調べたことをまとめました。

今回は、マルチアカウント展開を考えている方へ、AWS マルチアカウントの概要や AWS マルチアカウント管理サービスの概要をお送りします。


## AWS Organizations で出来ること

AWS Organizations で複数の AWS アカウントを管理することができます。
<img width="600" alt="BasicOrganization.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/385681/d4ec74bb-8923-8e2d-cb82-f3feb14c45f0.png">
[AWS Organizations の用語と概念 - AWS Organizations](https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_getting-started_concepts.html)より引用

組織にはマスターアカウントとメンバーアカウントが存在します。
マスターアカウントは Organizations を作成した AWS アカウント、
メンバーアカウントは Organizations で作成、招待された AWS アカウントです。
(作成後にマスターアカウントは変更できないので注意です)


サービスの詳細は [AWS Organizations ユーザーガイド](https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_introduction.html) にまとまっています。
ここでは、利用する前に個人的に気になっていた部分を記載しつつ説明していきます。

- AWS アカウントの一元管理
  - メンバーアカウントを新規作成したり、他の AWS アカウントを組織に招待することができます。
  - グループ単位 (OU) で AWS アカウントを管理できます。


- メンバーアカウントの一括請求 (旧 Consolidated Billing)
  - マスターアカウントでメンバーアカウントの AWS 利用料をまとめて支払うことができます。
  (ちなみにマスターアカウントからは、AWS コンソール上の[請求書]>[アカウント毎の料金明細]でメンバーアカウント別の利用料を確認できます。)


- メンバーアカウントのアクセス制御
  - Organizations の SCP を利用して、メンバーアカウントのアクセス権限を設定できます。
  - SCP は、IAM のアクセス権限ポリシーとほぼ同じ構文です
  （一部 SCP で利用できないポリシーもあるようですが、[アップデートで使えるポリシーがかなり増えました。](https://aws.amazon.com/jp/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/)）
  - OU に SCP ポリシーをアタッチして OU 単位でアクセス権限を設定できます。


- 他の AWS サービスを使用して、マスタカウントに情報集約
  - CloudTrail、Config などを集約しマスターアカウントから管理できます。
  - メンバーアカウントの利用状況を把握したり、よりセキュアに AWS アカウントを管理することが可能になります。
  使用するサービスごとのメリットは以下の AWS ドキュメントにまとまっています。
  [AWS Organizations で使用できる AWS のサービス](https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_integrated-services-list.html)


展開する際の手順は、 [AWS Black Belt Online Seminar AWS Organizations](https://www.slideshare.net/AmazonWebServicesJapan/20180214-aws-blackbeltorganizations) に分かりやすくまとまっています。

## メンバーアカウントの自動構築がしたい
ここからが今回の本題です。
多数のメンバーアカウントの作成となった場合、さらに気になるのは自動構築です。
そして自動構築にはいくつか方法があります。

AWS のドキュメントとしては、2019年の AWS 資料 [AWS Control Tower を活用したランディングゾーンの構築](https://d1.awsstatic.com/Compliance%20V2/JP_Security%20and%20Compliance/AWS%20ControlTower-and-Landingzone-SolutionDays2019_JP.pdf)  の概要図がとても分かりやすかったです。
構成は複雑なのですがとても分かりやすい。(語呂が無い)


### 1. AWS Landing Zone

<img width="600" alt="2019-12-03_10h03_16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/385681/46b41816-4da1-079b-9962-a441c54ed39c.png">
[AWS Control Tower を活用したランディングゾーンの構築](https://d1.awsstatic.com/Compliance%20V2/JP_Security%20and%20Compliance/AWS%20ControlTower-and-Landingzone-SolutionDays2019_JP.pdf)  より引用

Landing Zone を利用することで、ベストプラクティスに基づいてマルチアカウントを
自動的にセットアップすることができます。

実際に利用する際は、[Landing Zone \| AWS Solutions](https://aws.amazon.com/jp/solutions/aws-landing-zone/)  のサービスページから
AWS に問い合わせて展開してもらう必要があります。
最初はマルチアカウント構成が中々イメージできなかったため、構成がかなり参考になりました。


<img width="600" alt="2019-12-03_10h04_10.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/385681/2d19f6ce-7d3b-6b36-a5c1-ae5264ebfc55.png">
[AWS Control Tower を活用したランディングゾーンの構築](https://d1.awsstatic.com/Compliance%20V2/JP_Security%20and%20Compliance/AWS%20ControlTower-and-Landingzone-SolutionDays2019_JP.pdf)  より引用

Landing Zone の Pipeline を見ているとある程度カスタマイズしながら構築できるようです。
そして、AWS ドキュメントの [Overview - AWS Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/mrp-solution/overview.html) には、
企業の現在のクラウド利用状況の評価なども行い企業のクラウド導入のサポートをする
という記載もありました。凄いですね。


### 2. AWS Control Tower

Landing Zone の後に出てきたのが Control Tower という AWS サービスです。
[AWS Control Tower とは? - AWS Control Tower](https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/what-is-control-tower.html)

AWS コンソール上から Control Tower を通して、Landing Zone のマルチアカウントを
自動セットアップすることができます。
(コンソールで確認してみると Set up landing zone となってました！)
<img width="600" alt="2019-12-02_15h53_33.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/385681/0a139006-6bb3-dc6b-2384-c891e527c4b6.png">

Control Tower を利用する場合は、既存の Organizations の組織に連携することは出来ないので、
新しい組織を作成する必要があります。

また、Landing Zone の構成には Guard Duty がありますが Control Tower では有効にならないなど、
サービス構成は少し異なる点があるようです。
Config ルール3つが必ず有効になるなど、コスト面で考慮しておく点もあります。

現在サポートしているのは以下のリージョンです。(2019年12月3日現在)

- US East (N. Virginia)
- US East (Ohio)
- Europe (Ireland)
- US West (Oregon)

ログ集約やガードレールという新機能は、サポートされたリージョンのみなど、制約があります。

東京リージョンのサポートさえ来てくれれば、ぜひ利用したい！
今後のアップデートに期待です。
[AWS Control Tower の一般提供を開始](https://aws.amazon.com/jp/about-aws/whats-new/2019/06/aws-control-tower-is-now-generally-available/)


### 3. AWS Security Blog で公開されているスクリプト
そして、AWS Security Blog で公開されているスクリプトを利用して自動化する方法もあります！
以下のブログでは、新しいアカウントを自動的にセットアップするスクリプトが公開されています。
[How to Use AWS Organizations to Automate End-to-End Account Creation \| AWS Security Blog](https://aws.amazon.com/jp/blogs/security/how-to-use-aws-organizations-to-automate-end-to-end-account-creation/)

アカウントの利用用途によって構成を追加したい場合もあると思います。
S3 のブロックパブリックアクセス (アカウント設定)と CloudFormation の StackSets 用のロールを
一緒に設定する場合など有用だと思います。

ちなみに、bash スクリプトと Python スクリプトの2つが用意されています。
構成を追加する部分だけスクリプトを書くだけでいいですね。ありがたいです。

補足として、スクリプトを利用した場合は、以下の様なアカウントのセキュリティ設定は
別途設定する必要があります。

1. CloudTrail
    - 全リージョンで有効化
    - マスタアカウントのS3へログ集約
2. Config
    - 全リージョンで有効化
    - Config ルールの有効化
    - マスタアカウントのS3へログ集約
3. GuardDuty
    - 全リージョンで有効化
    - マスタアカウントへ集約

など...

実際に設定する際には、
`1. CloudTrail`と `2. Config` は Organizations の設定で有効化できます。
(Config ルールはスクリプトの中で展開できます)
<img width="600" alt="2019-12-02_18h20_58.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/385681/838a1145-7fc7-ad71-934b-2919d8449052.png">

`3. GuardDuty` は AWS 側で Python スクリプトが用意されているのでそちらを利用できます。
[Amazon GuardDuty でのアカウントの管理 - Amazon GuardDuty](https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_accounts.html)


## 最後に
メンバーアカウントをすごく自動構築したかっただけだったのですが、
AWS のマルチアカウント制御の軌跡を見ることができました…。

スクリプトを利用する場合も紹介したのですが、今後のアップデート次第で必要無くなるかもしれません。
ですが、コストや追加設定したいサービスなど、利用用途によって構成を変えることは必要です。
そのためにもサービスからベストプラクティスを知ることから始めるのが大事だと思います。

re:Invent 2019 前に期待をこめての滑り込み投稿でした！