複数のアカウント運用が少し楽になるIaC基盤

概要

思い付きで書いた記事で、何か変なこと書いてるなと思うところがあったり賛否両論あるかと思いますが、
何卒暖かい目で見ていただき、
実際にこんな構成やサービスを組み合わせてるなどご意見などあればぜひコメント頂けると嬉しいです。

複数のAWSアカウントに対してガバナンスを利かせて運用する際に、
Case1のように共通アカウントから各アカウントに対してリソースなどを一斉展開したり、
Case2のようにアカウント側で事前に用意されたテンプレートを選択して適用できるようにするような運用をするケースがあるかと思います。

このようなケースの場合にどんな構成やアプローチだと良さそうなのか整理をしてみました。

全体のアカウント構成

AWS Organizationで複数のAWSアカウントを運用する際に、
以下のようなアカウント構成をとることが推奨構成なのかなと思います。
Control Towerで管理するアカウントも以下のような構成になりますね。

Security OU(Organization Unit)に監査用アカウントとログ用のアカウントがあり、
その他にSandbox OUやProject単位のOU配下にTeam1、Team2など、
それぞれのメンバアカウントがあります。

共通アカウント

リソースなどを展開したり、テンプレートを管理するアカウントとして個別にアカウントを用意します。

リソースを展開したいスコープ（以降管理スコープ）が所属するOU内に用意をするか、
管理スコープが複数のOUにわたる場合は共通基盤用のOUを設けて
共通アカウントを用意するのはどうかなと思いました。

AWS OrganizationsでCloudFormationを有効にすると各アカウントへスイッチできるロールが自動的に作成されるので、Management accountを使うという選択もありますが今回はなるべくOrganizationに縛られないに考えてみます。

Case1

共通アカウントから各メンバアカウントへ一斉にリソースを展開するケースです。

例えばCloudFormationはOrganizationでサポートしているため、
有効化にするとManagementアカウントからStackSetsが作成できるように各アカウントにIAMロールが自動的にデプロイされます。

ですがOrganizationでサポートしていないユーザカスタマイズによる設定など、
例えばSecurityHubのマスター-メンバアカウント関係とは別に、
一部のメンバアカウントが持つSecurityHubのデータを統合的に可視化する場合、
各メンバアカウントのSecurityHubのイベントをEventBridgeなどで統合アカウント側に転送する必要があります。
この際に1つ1つメンバアカウント側で設定をしなければなりません。

各メンバアカウントにログインして1つ1つ設定をするような修行をするのではなく、
共通アカウントから一度の実行で管理スコープにリソースを展開するようなことができると最高です。

良さそうなアプローチ

3つほどアプローチを考えてみましたが、
ケースによって使い分けるのがよさそうかなという印象でした。

Aの場合は各アカウントがもつリソースID（例えばVPC IDなど）が異なると、
リソースIDを検索するところが課題になりそうです。
リソースIDを各アカウントのParameter Storeに登録しておき、
動的参照するなどの方法もありそうですが、
そもそも各アカウントに登録するのが手間ですね。
そのため、リソースIDに懸念がない（例えばリソースの新規作成）展開なら一番よさそうかなと思いました。

Bの場合はTerraformの実行環境を用意する手間があり、
リソースIDの問題はAと同じなのですが、
リソースIDをCSVやJSONに定義してパラメータが渡せれば柔軟性はあるかなと思いました。

各アカウントのリソースIDをどのように拾ってくるかが課題になりそうですが、
例えばタグなどが統一されていることが前提としてSSM Automationで集めてくるなど、
その他には構成管理DBなどに各リソースIDの情報を集約しておくと便利そうかなと思いました。

Cの場合は手軽に使える反面、
構成などを管理することはできないためワンライナーな設定を適用する場合に向いているのかなと思いました。

Terraformを使ったパターンの補足

Terraformには複数のAWSアカウントに対してリソースをデプロイするという機能はない（2023/10月時点）と思いますので、
workspace機能を利用して展開をします。
通常は本番環境や開発環境の切り替えに使うのですが、
今回は環境切り替えによって実行の向き先が変わることを利用しています。

Terraformのworkspaceについては以下を参照ください。
https://developer.hashicorp.com/terraform/language/state/workspaces

1. CSVやJSONに管理スコープのアカウントIDとリソースID（VPC IDなど）を用意する。
2. Terraformのworkspaceの機能を利用して、管理スコープのアカウントIDでworkspaceを用意する。
3. リソースをデプロイする。

Case2

任意のアカウントが共通設定を展開したいときに利用するケースです。

Case1との違いは管理スコープのアカウントすべてに設定を適用する必要はなく、
あくまで各メンバアカウントが必要だと思った段階で、
また必要な共通設定を自身で展開するようなイメージです。

例えば共通基盤を利用するのに必要な設定を各アカウント側で実装しなければならない場合、
申請に基づいて実装してあげたり、手順書を渡して実装してもらったりことがしばしばですが、
テンプレートだけ用意をして後はアカウント側が任意に展開できると最高です。

AWSのラボやハンズオンなどでよくLaunch Stackボタンなどを見かけるかと思いますが、Launch Stackのソーステンプレートを共通アカウントで管理するようなイメージです。

よさそうなアプローチ

こちらも3つほど考えてみましたが、
Terraformなどの縛りがなければAが最もよいのではないかと思いました。
Cも良さそうではあるのですが複雑な構成は定義が難しく、
どちらかといえば何か設定を適用する場合に使いやすそうかなと思いました、

Terraformを使ったパターンの補足

Terraformを使った構成ですが、
実行環境はCloudShellですとボリュームの制約などがあり、
Cloud9だとサーバ管理などが発生するため、なるべくサーバレスな構成としてCodeBuildを選択しました。
また、Terraformにパラメータを渡すのに画面のようなものがあれば、
各アカウント側が実行しやすいかなと思いSSM AutomationからTerraformを実行する構成としています。

1. リソースを作成するアカウントAにログインします。
2. 共通アカウントへスイッチロールをしてアカウントを切り替えます。
3. SSM Automationを実行して、パラメータファイルを作成し、CodeBuildを実行します。
4. CodeBuildの中でTerraformが実行されます。
5. TerraformがアカウントAのロールを使ってリソースを展開します。

まとめ

複数のアカウントに対してリソースの展開、
共通設定を任意に展開してもらう構成について考えてみました。

複数のアカウントへ展開する際には、リソースIDの課題を考えなくても良いCloudFormationのStackSetsによる展開がよさそうですが、TerraformやSSM Automationもケースによっては使い道がありそうでした。

共通設定を任意に展開してもらう場合は、
Terraform縛りなどの制限などがなければService Catalogを使うのがよさそうです。

最後までご覧頂きありがとうございました。
思い付きで書いてみた記事なので、こんな構成もあるのでは？などのご提案やご指摘などあれば是非いただければと思います！
この記事がどなたかの参考になれれば幸いです。