はじめに
こんにちは！
私たちの会社は、デジタルマーケティングを専門とする企業で、複数のアプリケーションを運用しています。私たちは SRE として、AWS の環境を管理する役割を担っています。最近、AWS Control Tower を使ってマルチアカウント環境を構築した経験があり、そのプロセスが予想以上に面白かったので、ブログで共有することにしました。
この記事は 2 部構成で、今回はその第一部として、私たちがなぜこの道を選び、どう準備したかを紹介します。
最初の課題とマルチアカウントを選んだ理由
AWS Organizations 導入から 3 年以上経ち、現行の開発スタイルがアカウント構成によってボトルネックになっていました。開発環境、テスト環境、本番環境で共有されるアカウントが存在し、新しい技術の調査に役立てるためだけにビジネスとは関係のないリソースが含まれている場合もあります。
小さなプロジェクトなら問題なかったのですが、規模が大きくなると混乱が起きました。たとえば、コストがどのチームやプロジェクトに紐づくのか追跡が難しくなり、誰かが誤って本番の設定を変更してしまうリスクもありました。
新たなアプリケーションを追加するたびに、手動で IAM ポリシーや VPC を設定する作業は時間がかかり、ミスも増えました。このままではスケールできないと気づき、マルチアカウント戦略を考えるようになりました。
複数のアカウントを使えば、環境を分離し、セキュリティを強化し、コスト管理も明確になると考えたのです。同時に、AWS 環境の Infrastructure as Code (IaC) 管理のための便利なパスも開かれます。
なぜ AWS Control Tower を選んだか？
マルチアカウントを実現する方法はいくつかありますが、私たちは AWS Control Tower を選びました。理由はシンプルです。Control Tower は、ランディングゾーン（AWS 環境の基盤）を自動で構築し、ベストプラクティスに基づくガードレール（ルールを強制する仕組み）を提供してくれるからです。
AWS Organizations を手動で設定することもできましたが、時間と専門知識が必要で、私たちのチームには少しハードルが高かったです。Control Tower なら、数クリックで初期設定が終わり、セキュリティやコンプライアンスのルールもすぐに適用できます。これが、AWS にまだ慣れていない我々にとって大きな魅力でした。
最初のステップ：計画と準備
Control Tower を導入する前に、私たちはまず AWS のマルチアカウント環境について深く理解することから始めました。最初は、正直言って少し混乱しました。Control Tower とは何か、AWS Organizations との違いは何なのか、ランディングゾーン（Landing Zone）って何を意味するのか、一つ一つ調べる必要がありました。
チームで AWS の公式ドキュメントや Control Tower のホワイトペーパーを読み込み、「マルチアカウント戦略とは、セキュリティ、ガバナンス、スケーラビリティを向上させるための基盤だ」という基本理念を把握しました。さらに、AWS Well-Architected Framework や Control Tower のベストプラクティスを参考に、どうすれば私たちのニーズに合う設計ができるかを考えました。例えば、「ログを一元管理する」「開発と本番を完全に分離する」といったアイデアが浮かびました。
次に、具体的な計画を立てる段階に移りました。まず、管理アカウント（Management Account）をどうするかを決めました。既存のルートアカウントをそのまま使うことにし、ホームリージョンとして「us-east-1」を選択しました。そして、組織単位（OU）の設計に取り掛かりました。最初はシンプルに「Security」「Sandbox」「Workloads」の 3 つの OU を考えました。Security はログアーカイブや監査用、Sandbox は開発者が自由に実験できる場所、Workloads は開発、テスト、本番環境を分けるためのものです。
しかし、設計を進めるうちに、「将来の拡張性も考慮すべきだ」と気づき、Workloads 内にさらにプロダクトごとに階層化する案も試してみました。ホワイトボードに何度も図を描き、チームでディスカッションを重ねました。
この設計に至った理由は、私たちにとって説得力のあるものでした。単一アカウントでは、コスト追跡が難しく、誰かが誤って本番データを削除するリスクがありました。例えば、以前、テスト用の EC2 インスタンスを本番環境で起動してしまい、予期せぬコストが発生したことがありました。
マルチアカウントなら、各チームが独立したアカウントを持ち、IAM ポリシーで権限を厳密に管理できます。また、Control Tower のガードレールを使えば、「CloudTrail を誰も無効化できない」「特定のリージョン以外は使えない」といったルールを強制でき、セキュリティが大幅に向上します。さらに、Account Factory で新アカウントを迅速に作成できるため、新しいプロジェクトの立ち上げが数日ではなく数時間で済みます。これが、私たちがマルチアカウント環境を選んだ大きな動機でした。
準備の最後に、Control Tower が必須とするログアーカイブと監査アカウント用にメールを用意しました。log-archive@example-company.com と audit@example-company.com を作成し、アカウント登録を進めました。ここまで来て、ようやく「ランディングゾーンを設定」のボタンを押す準備が整いました。
第一部の終わり
計画が固まり、いよいよ Control Tower の「ランディングゾーンを設定」ボタンを押す時が来ました。でも、実際の展開は計画通りに進んだのでしょうか？予想外のトラブルは？第二部で、私たちがどう実装し、何を学んだかを詳しくお伝えします。次回をお楽しみに！