ウェルスナビにおけるAccount Factory for Terraformの導入事例

こんにちは、インフラエンジニアの伊藤です。

今回は、最近弊社で導入したAccount Factory for Terraform(AFT)に関して、背景や今後展開していきたい内容などのお話をします。

AWS Control Tower Account Factory for Terraform(AFT)とは

hashicorpに記載されている内容によると

AWS Control Tower Account Factory for Terraform (AFT) は、組織のセキュリティガイドラインに準拠した新しいアカウントを簡単に作成およびカスタマイズできる Terraform モジュールです。AFT では、AWS Control Tower アカウントを自動かつ一貫して作成するためのパイプラインを定義し、Terraform のワークフローと Control Tower のガバナンス機能の利点を提供します。AWS がこのモジュールを保守します。

とのことです。

またAFTはマネージドサービスではなく、所謂ソリューションになります。

一般的な AFT スキーマ (出典: Hashicorp AFT )

AFT導入に至った背景

現在ウェルスナビでは、サービス関係のアカウントが本番用、開発用含めた10個に加えて、監査ログやマスターアカウントなど設定系のアカウントが8個ほどの計18アカウント存在しています。また複数プロダクト展開を見据えており、今後もアカウントは増加する予想です。
弊社ではプロダクトレベルでの開発者の権限の調整に対する複雑さなどを考慮した結果、AWSマルチアカウントの前提とした運用方針になっています。
そのため、AWS Control Tower経由でアカウントを管理していましたが、下記問題が発生していました。

新規アカウントを払い出す際、毎回権限の設計や、責任区分の明確化などが発生しており、払い出すまでの間に非常に時間がかかってしまう。
弊社はAWS OrganizationsやControlTowerのサービス提供前からAWSを利用しているため、局所最適に陥っている箇所がある
...
etc.

選定理由

AWS Control Towerの調整においては大まかには下記の手段があります。

AWS Control Tower のカスタマイズ (CfCT): Terraform非対応（CloudFormationのみ）
AFC: Terraform対応。ServiceCatalogの適用は手動。設定できるBluePrintは1つだけ。
- 弊社での導入時にはまだTerraform未対応でした。
AFT: Terraform対応。GitOpsで展開できる

これらのことを踏まえた上で、TerraformでIaCを実施していて、且つGitOpsを採用している弊社としては、AFTを導入することが一番適していると判断しました。
結果的にセキュリティガードレールやVPC等の初期設定といった全体的な対応、開発者の権限や社内からの通信のみを許可するためのSGの作成といったアカウント単位での個別対応のコストが軽くなりました。

AFT導入によって実現できたこと

アカウント作成の高速化や、コード管理下におけたという点において、非常に楽にはなっています。しかしながら現状まだAFTのメリットを十分に活用できているとは言い難く、今後も引き続き改善を進めていく必要がある状況です。

AFT導入に関して苦労したこと

未だに導入事例が少なく、自社の環境によって変わってしまう部分もあるため、設計こそ大変ではあります。
簡単な例としては、IAM Identity Center権限セットなど一定以上、変更頻度が高く想定されているものに関しては、別のTerraformで管理した方がやりやすい認識です。またそもそもデフォルトの状態だと、マスターアカウント自身を管理対象にはできず、ある程度作り込む必要があります。このように共通設定、アカウント単位の設定、AFT外で管理すべきものを選別していくことなどが挙げられます。

今後実施したい内容

今後としては下記内容を取り組んでいきたいと考えています。

AWS Config Rulesでの設定配布
- 現状GuardDuty, SecurityHub, CloudTrailはOrganizationsの機能で配布しています。
本番環境における権限のジャストインタイム対応
- AWSによるTEAM解説
VPC設定やCI/CD用のRole作成、ルートアカウントの無効化とMFAの強制などの初期設定の充実化