HENNGE が Account Factory for Terraform を導入して実現できたこと

最初に、管理している AWS アカウント数やアカウントの払い出しを実施しているメンバー数についてお話しします。Account Factory for Terraform (AFT) 導入前は AWS アカウント数は 43 で、AFT 導入後に 100 まで増えています。

AWS アカウント数が増えた理由は開発者に向けてサンドボックス環境を払い出したこともあります。AWS アカウントの払い出しを実施しているメンバーは 2 人で、AFT の導入は 2 人で検討した後にほぼ 1 人で実施しました。

Terraform は Terraform Open Source を利用していて、AFT 導入前からリソース管理のために 7 年ほど利用経験がありました。

Account Factory for Terraform (AFT) を導入するモチベーションとして、開発速度を向上させるために開発者 1 人 1 人に専用のサンドボックスアカウントを払い出したいという目標がありました。サンドボックス環境として AWS アカウントを単純に作成して開発者に渡すだけでは統制が効かないため、対策として AWS Organizations、AWS Control Tower 、そして AFT の導入を行いました。

AWS Organizations の すべての機能 を有効化して利用を開始した際の課題としては、社内 IT が状況を把握しきれていないという点がありました。

各部署から届く AWS アカウント作成依頼を手動で対応していて、時には AWS アカウントを作成されたことを経理から教えてもらって後から組織に追加することもあったため、まず AWS アカウントは AWS Organizations から払い出すようにプロセスを変更しました。

AWS Control Tower 導入前は、ガバナンスに関しても課題は感じていたものの、メンバーは限られていたのでなかなか対応できない部分がありました。可能な限りマネージドサービスを利用してガバナンスを効かせたいと考えていた際に東京リージョンで AWS Control Tower が利用可能になったことを知ったので、すぐに利用を開始しました。

Account Factory for Terraform (AFT) を利用することになったきっかけとして、AWS アカウント作成の自動化を目指していた点があります。

AWS Control Tower を使うことで AWS アカウントの作成もある程度は楽にできるようになりましたが、当時は同時に作成できる AWS アカウントの数が 1 つで作成に時間がかかってしまうために、開発者個人のサンドボックスは用意できていませんでした。ただ、Control Tower を導入してガードレールの整備が進んだことによって、多数のアカウントを作成するための土台ができました。

AFT を知った際に AWS が用意した仕組みを使って Terraform で AWS アカウントを作れる点に興味を持ちました。AFT は内部でキューを持っているので Terraform ファイルに複数アカウントの情報を書いておけば順番に AWS アカウントを作ることができます。

同時に 1 つしか AWS アカウントを作成することができないという制約があっても、待っていれば統制の効いたアカウントを複数作れる仕組みとなっており、Terraform 利用に関しては社内に知見も多くあったので、AFT を採用しました。

Account Factory for Terraform (AFT) の導入時に悩んだ点についても共有します。ワークショップ があったので、手順に従って進めることで AFT を実行すること自体は容易でした。ただ、Control Tower 管理アカウントと AFT 管理アカウントの役割の違いがすぐに理解できておらず、運用に関する手順がワークショップになかったこともあり AFT のバージョンアップをどこのアカウントでどのように実施するかも把握するまでに少し時間がかかりました。

アカウントの役割の違いとして、AFT 管理アカウントは Terraform ファイルを元に、 Control Tower を使って AWS アカウントを発行するために必要なリソースが動くアカウントになります。AWS アカウント作成用の Terraform ファイルを作成すると、AFT 管理アカウントのリソースが Control Tower 管理アカウントにアクセスするため AWS アカウント作成時に Control Tower 管理アカウントにログインして対応する必要はありません。

ただ、AFT のバージョンアップに関しては Control Tower 管理アカウントに対して Terraform モジュールを適用するため、作業を Control Tower 管理アカウントで実施する必要があり、これらの点の理解には時間がかかりました。

AFT を導入したことでほとんどの作業は自動化されましたが、ルートユーザーの MFA の設定は手作業が残っています。セキュリティの観点からは MFA の設定は重要だと考えています。ルートユーザーの MFA はマネジメントコンソールで有効化する必要があるので、手作業で実施しています。

また、AWS IAM Identity Center を利用する部分については AFT と分けた方がやりやすいと判断して、AFT の後続作業として別の Terraform を実行して設定を実施しています。AFT はカスタマイズの自由度が高いので作り込めば Control Tower 管理アカウントに対する操作も追加することができますが、アカウント作成フローは長くなるためエラーハンドリングといった別観点を考慮した結果、今のやり方を取っています。Terraform による IAM Identity Center の設定自体は Resource を使って実現が可能です。

Account Factory for Terraform (AFT) によって、長年実施したいと考えていた開発者用のサンドボックスアカウントを払い出すことができました。Control Tower の導入でガバナンスを高めることができたことと、AFT によって AWS アカウント作成のリードタイムが短縮できたことが理由です。

自動化も進めた結果、AWS アカウント作成をリクエストする側が出すべき情報も明確になり、社内のアカウント作成フローもシンプルになりました。アカウント作成のリクエストを受け、実施する作業の流れとしては以下になります。

1. TF ファイルを作成する
2. リポジトリに push する
3. AFT を通じて AWS アカウントが作成されることを待つ
4. ルートユーザーの MFA を設定する
5. AFT を利用し、より制限の厳しい組織単位 (OU) に移動する
6. AWS Identity Center 設定等の残作業を実施する

1 で最初に設定する OU は Control Tower の必須コントロールが適用された OU としています。

5 で移動する OU は、ルートユーザーとしてのアクションを許可しないサービスコントロールポリシー (SCP) を含む、必須コントロールだけではなく別の Control Tower のコントロールも有効化した OU となっています。

6 の AWS Identity Center 設定等は別 Terraform を実行して処理しています。作業の所要時間は 1 から 6 までで約 30 分です。

HENNGE では Infrastructure as Code (IaC) を導入していて、本番環境と検証環境は基本的に開発者への権限を絞っているため、サンドボックスで開発者に強い権限を付与してリソース作成を試せることは開発スピードを高めることにつながります。

強い権限によって得られる自由には責任が伴うことを開発者にアカウントを渡す前に伝えていたことと、AWS Budgets を使って利用料が高まった際には通知を飛ばしているので、今のところ大きな事故もありません。

開発者が様々なことを試しやすくなったことで AWS により興味を持ったり、認定資格取得者が増えたりといった想定外のポジティブな結果も得られています。

Account Factory for Terraform (AFT) に限りませんが、今後実施していきたいことも紹介します。

まず、新しい AWS アカウントは AFT を通じて作成していますが、AFT 導入前から存在する AWS アカウントはまだ AFT 管理下に入っていないものもあります。AFT の管理下に移す作業は実施している最中なので継続して対応していく予定です。

他には開発者が実施する PoC (Proof of Concept) のスピードを早めるために、AWS Proton や AWS App Runner の導入を検討しています。AWS のサンプル を参考にしながら開発者がコンテナイメージ作成まで行えば済む状況を作れたらと考えています。

Account Factory for Terraform (AFT) を実際に導入した私たち HENNGE の 2 人からなぜ AFT を導入したかをお伝えしました。

2 人という限られた人数であってもマネージドサービスを利用することで既存の環境に対するガバナンスを強化し、開発速度を向上させるために開発者にサンドボックス環境を渡すという目標が実現できました。

AFT の採用理由は元々 Terraform を利用していたことと、できるだけマネージドサービスや AWS が用意した仕組みを利用したいという点でした。AFT 利用によってサンドボックス環境が整備され、開発者がより AWS に興味を持って認定資格の取得者も増えるといった結果を得ることができました。

あまり AFT について記載されている記事は多くないと思いますので、本記事が AFT や AWS Control Tower に興味を持った方の参考になれば幸いです。