Control TowerにAWSアカウントを追加した時のガードレール展開の動きを確認する

前提

希少な例ではありますが、以下のような環境を想定して書いています。

• Control Towerを有効化している
• Control Towerサポート外のリージョンにガードレールを展開する以下のソリューションを利用している

• 上記ソリューションでConformance Packs管理者をAuditアカウントに委任している

上記の設定をしている環境で新しくAWSアカウントをControl Towerに追加したとき、どのような動きをするのか理解できていなかったのでまとめておきます。

Control Towerって何？

マルチアカウント管理の統制をいい感じにまとめてくれるサービス。現時点(2021/03/26)で東京リージョン未対応です。 前提としてマルチアカウント統制のベストプラクティスに従った構成の考え方である「Landing Zone」を理解する必要があります。この辺りのエントリを一読してみるとわかるかも。

Conformance Packs(適合パック) って何？

主にConfigルールがたくさん書かれたCloudFormationテンプレートを展開できる仕組み。以下のエントリがとっても分かりやすいのでおすすめです。

今回のConformance PacksはControl Towerで展開される発見的(検出)ガードレールと同じConfigルールを定義したCloudFormationテンプレートを展開する仕組みです。

Control Towerサポート外のリージョンに同じガードレールを展開する仕組みの中でConformance Packsを利用しているのが先ほど前提にリンクを載せたソリューションです。実際にやってみたエントリはこちらになるのでイメージを掴むにはこちらを参照して下さい。

AWSアカウント追加時の動き

Control Towerにアカウントが追加されたときのガードレールの展開ですが、大きく3つの動きがあります。

• Control Towerがサポートしているリージョンへの展開
• (Control Towerサポート外リージョン)Configの有効化
• (Control Towerサポート外リージョン)Conformance Packsの展開

それぞれどのようにガードーレールを展開しているのかを詳細を確認していきましょう。

Control Towerがサポートしているリージョンへの展開

新規のAWSアカウントが追加された時のControl Towerの動きを簡単にみていきます。

Control TowerにはアカウントファクトリーというAWSアカウントを作成/登録する仕組みが用意されており、正常に追加が完了すると新規アカウント上にControl TowerのMainアカウントから管理に必要な様々なリソース(ガードレールやIAMロール、ClooudTrail等)が展開されます。

展開されるリソースの詳細についてはドキュメントを参照して下さい。

発見的ガードレールを展開している実体はMainアカウントのStackSetsが各アカウントへスタックを展開しています。

Control Towerサポートリージョンは特に何もしなくともConfigの有効化と発見的ガードレールの展開を行ってくれるので、前提条件を満たしていれば問題ないと思います。

ここまででControl Towerのアカウント追加は完了しますが、展開できているのはサポートされているリージョンのみで、管理外のリージョンに対してガードレールは展開できていません。

(Control Towerサポート外リージョン)Configの有効化

Control Towerサポート外リージョンについてはControl Towerから自動でConfigが有効化されないため、別の仕組みで展開してあげる必要があります。

そこで利用するのが先ほど紹介しているこちらのソリューションです。手順通り展開すると、EventBridge(CloudWatch Events)、SQS、LambdaがControl TowerのMainアカウントに展開されます。

Control Towerでは管理上行われる様々な操作をライフサイクルイベントとしてEventBridgeに通知されるようになっていて、EventBridgeではライフサイクルイベントであるCreateManagedAccountをトリガーとして動くようになっています。Control Towerからどのようなライフサイクルイベントが発行されるかは公式ドキュメントを参照して下さい。

Control TowerからCreateManagedAccountのライフサイクルイベントが発行されると、EventBridge(CloudWatch Events)からSQS、Lambdaという順番で動作します。

ExtendedRegionLELambdaでは受け取ったイベントがCreateManagedAccountだった場合にConfigを有効化するStackSet-CUSTOM-CONFIG-STACKSET-xxxxxxというConfigを有効化するStackSetsを追加されたアカウントへ展開します。

ここまでで新規AWSアカウントの管理外リージョンはMainアカウントからConfigの有効化までが行われた状態になります。

(Control Towerサポート外リージョン)Conformance Packsの展開

ここまででControl Towerサポート外リージョンはConfigが有効化されていますが、発見的ガードレールについては未展開となっているので、Conformance Packsを使って展開していきます。

Conformance PacksにはOrganizationsとの連携機能があり、新規のアカウントが追加されたときに自動で対象のアカウントに対してConformance Packsを展開することができます。

Control Towerによって作成/登録されるAWSアカウントはOrganizationsのOU配下に追加されることになるため、Conformance Packsとして設定したルールが自動的にプロビジョニングされます。

イメージとしてはこんな感じになります。(Config有効化のフローは省略)

OrganizationsにAWSアカウントが追加されたタイミングで、恐らく内部的にはPutOrganizationConformancePackのAPIをConfigが自動で実行して展開しています。(CloudTrailから確認できなかったので間違ってるかもしれません。)

ここで展開されるスタックのテンプレートはソリューション通りに設定していればLog archiveアカウントに設定したS3から取得されます。

Control Tower管理外のリージョンへのガードレール展開では、Mainアカウント側ではConfigを有効化するスタックが展開され、AuditアカウントからはConformance Packsが展開されるという大きく2つの流れがあることを覚えておいてください。

これで新規アカウントの全リージョンに発見的ガードレールを展開することができました。

ここまでの一連の流れが、Control Towerを有効化してこちらのソリューションを展開しているとき、新規アカウントを追加した時の流れになります。

注意事項

先ほども一度紹介しましたが、AWSアカウントを追加する前にはしっかりとドキュメントの前提条件を満たしておきましょう。

新規のアカウントをアカウントファクトリーから発行する場合には考慮不要ですが、既存のAWSアカウントをControl Tower配下に移管する場合にはいくつか条件を満たしている必要があります。

特に今回のようにConformance Packsを使ったガードレールの展開をする場合は、移管する全リージョンでConfigが無効になっていること、STSが有効になっていることを確認しましょう。

Control TowerのサポートリージョンのみSTSを有効化していると、Control Towerのコンソール上アカウントの追加は問題なく完了しますが、サポート対象外のリージョンはConfigが有効化されずにConformance Packsも展開されない状態となってしまいます。その場合、手動でConfigとConformance Packsを再展開する必要があるので注意しましょう。

またConfigが有効化されているリージョンがある場合、恐らくStackSetsを展開するLambdaが失敗します。移管前にこちらのコマンドを実行して全リージョン無効化するのを忘れないようにしましょう。

まとめ

Control TowerやConformance Packsは複雑でよく分からなくなったのでまとめてみました。

リージョンごとにControl TowerとConformance Packsの管理が分かれてしまうという多少の手間はありますが、全て自動で展開できることや一度展開したあとの修正はあまり行わないことを考えると非常に便利なソリューションだと思います。

Control Towerは最近対応リージョンが増えてきていますが、東京リージョン含めまだ未対応のリージョンがあるため、正しく理解しながら使っていきたいですね。

どんどん活用してマルチアカウントの統制やっていきましょう！