[Chalk talk] Architecting enterprise-scale governance beyond AWS Control Tower に参加しました #ARC323 #AWSreInvent

こんにちは、クラウド事業本部 コンサルティング部のいたくらです。
AWS re:invent 2025 は現地参加しています。

「Architecting enterprise-scale governance beyond AWS Control Tower」に参加したのでレポートします。
Chalk talk セッションはスピーカーと参加者がインタラクティブにやりとりするため、聞き取れなかった部分もありますがご了承ください。

3 行まとめ

• Control Tower はアカウント管理のためのツールであり、リソース管理とは明確に区別して考える必要がある
• ガバナンスの実装サイクルは「Define Directives → Account Baselining → Self service & scalability → Provide Evidence」の流れで進める
• プラットフォームチームには本番環境とは別のテスト用ランディングゾーンが必要であり、成熟度向上には文化の醸成が不可欠

セッション概要

• セッションID: ARC323
• タイトル: Architecting enterprise-scale governance beyond AWS Control Tower
• スピーカー
  • Alastair Bate, Cloud Optimisation SA, Amazon Web Services
  • Paul Bayer, Principal Technologist, Foundations, Amazon Web Services
• レベル: 300 – Advanced

Discover advanced governance strategies that build upon AWS Control Tower for enterprise-scale environments. Learn to implement infrastructure across the six Well-Architected Foundations capabilities, understanding critical trade-offs in each area. Learn to build efficient multi-account structures and streamline account provisioning processes that balance security and innovation. Understand how to architect governance solutions for both new deployments and expanding environments, with focus on automated compliance checks and standardization. Walk away with practical knowledge to create a Well-Architected foundation that enable self-service capabilities for even the largest of organizations.

（機械翻訳）
エンタープライズ規模の環境において、AWS Control Tower を基盤とした高度なガバナンス戦略をご紹介します。Well-Architected Foundations の 6 つの機能にわたるインフラストラクチャの実装方法と、各領域における重要なトレードオフについて学びます。効率的なマルチアカウント構造の構築方法と、セキュリティとイノベーションのバランスを取りながらアカウントプロビジョニングプロセスを効率化する方法を習得します。新規デプロイメントと拡張環境の両方に対応したガバナンスソリューションの設計方法を、自動化されたコンプライアンスチェックと標準化に焦点を当てて理解します。最大規模の組織でもセルフサービス機能を実現する Well-Architected な基盤を構築するための実践的な知識を持ち帰ることができます。

セッション内容

Control Tower の位置づけと関連ツール

セッションの冒頭で、参加者への質問がありました。Control Tower をインストールしたことがある人、LZA（Landing Zone Accelerator）をインストールしたことがある人など、挙手で確認が行われました。

スピーカーからは、ツールは本来の目的に沿って使うべきというメッセージがありました。1 つのツールですべてを解決しようとすると、うまくいかないことが多いとのことです。

Control Tower 周辺のカスタマイズツールとして、以下の紹介がありました：

ツール	特徴
AFT（Account Factory for Terraform）	Terraform ベース
CFCT（Customizations for Control Tower）	CloudFormation ベース
LZA（Landing Zone Accelerator）	CDK ベース、YAML 形式の設定ファイル

これらはすべて Control Tower と連携して動作し、アカウント作成時に自動的にカスタマイズを適用できます。

Control Tower を導入した後に考えるべきこと

Control Tower をインストールしただけでは、すべてが解決するわけではありません。開発者やセキュリティチームから「もっと機能が必要だ」「これだけでは足りない」と言われることがあります。

Landing Zone インフラストラクチャとして考えるべき要素が議論されました。Account Structure（アカウント構造）、Network Connectivity（ネットワーク接続）、Identity（アイデンティティ）、Security（セキュリティ）、Service Approval（サービス承認）、Tagging Policy（タグ付けポリシー）、Data Perimeter（データ境界）などです。

参加者からは「セキュリティとネットワークがもっとも複雑」「アカウント構造とアイデンティティは比較的簡単」という意見が出ていました。

ガバナンス実装サイクル

セキュリティには 4 つのステップがあります。Directive（指令）、Preventative（予防）、Detective（検知）、Remediation（修復）です。

AWS は下の 3 つ（Preventative、Detective、Remediation）には多くのツールを提供していますが、Directive（指令）は顧客自身が定義する必要があるとのことです。何が重要かを自分たちで決めなければ、ツールも活かせません。

この指令に基づいて、Account Baselining（アカウントの基本設定）→ Self-service & Scalability（開発者への提供）→ Provide Evidence（コンプライアンス証拠の提供）→ Define Directives（指令の改善）というサイクルを回します。

アカウント管理 vs リソース管理

セッションでもっとも強調されたポイントの 1 つです。

アカウント管理は、アカウントの作成・プロビジョニング・ベースライン設定など、全アカウントに共通の設定を適用するものです。IAM ロール、CloudTrail、セキュリティ設定などが該当します。

一方、リソース管理は、EKS クラスター、S3 バケット、RDS インスタンスなど個別のワークロードに特化した設定で、開発者のパイプラインで管理するものです。

なぜこの区別が重要なのか。AFT や LZA は基盤インフラ（ネットワーク、セキュリティ、IAM など）を管理するためのツールであり、EKS クラスターのようなワークロード固有のリソースを個別アカウントごとに管理するのは推奨されておらず、アカウント数の増加に伴いパイプラインの実行時間も増加するため、ワークロードリソースは別の CI/CD パイプラインや Terraform で管理すべきとのことです。

ベストプラクティスとして、アカウントベースラインはできるだけ広く適用されるもの、リソース管理はできるだけ狭く適用されるものと整理するのが良いとのことでした。

CloudFormation vs Terraform の使い分け

スピーカーの意見として、アカウント管理には CloudFormation（Stack Sets）がオススメとのことでした。CloudFormation Stack Sets は 1 つのテンプレートを多数のアカウントに適用できます。
（注記：ドキュメント上は 1 つの Stack Set で最大 100,000 stack instances まで対応可能）
一方、Terraform をアカウントごとに個別管理する設計にした場合、400 アカウントあれば 400 個の状態管理が必要になり、構成のドリフトが発生しやすくなります。
（注記：調査したところ、AFT の Global Customizations を採用するとこの問題は回避できるようです）

ただし、リソース管理には Terraform や CDK など、チームに合ったツールを使用すれば良いとのことです。

テスト環境の重要性

参加者から「プラットフォームチームが過去 2 年間で 4 回も本番環境を壊した、どうすれば回避できたか？」という質問がありました。SCP（Service Control Policy）の変更や VPC ピアリングの変更が原因だったそうです。

これに対するアドバイスとして、まず開発環境だけでは不十分という点が挙げられました。多くの人は「Dev / Non-prod」アカウントを持っていますが、それは開発者のためのものです。プラットフォームチームには、本番と同じ構成を持つ 専用のテスト用ランディングゾーン（別の AWS Organization） が必要です。

ただし、完全なコピーは不要とのことでした。中央の基盤アカウント（ログ、監査、ネットワーク）を 1〜3 つ用意し、必要に応じて一時的なワークロードを立ち上げてテストすれば十分とのです。イベントが発生しなければ CloudTrail などのコストもかかりません。

テストの流れとしては、まずテスト用ランディングゾーンにデプロイし、テスト完了後に最初の本番環境にデプロイ、問題なければ残りの本番環境に展開という順序になります。

成熟度モデル

組織の成熟度について、5 つの段階が紹介されました。

最初は Beginning の段階で、アドホックなリクエストが飛び交い、ドキュメントが散在し、何がどこで動いているか分からない状態です。次の Reactive では、まだ火消しに追われていますが、稼働時間を計測し始めます。その後、サービス全体の稼働時間で測定し変更管理を実施する Proactive の段階、サービスを提供する立場として認識される Service-oriented の段階へと進みます。最終的には Value Added に到達します。
スピーカーからの重要なメッセージとして、「成熟度は買えない」という言葉がありました。ツールを導入しただけでは成熟しません。成熟度は文化の一部であり、組織に根付かせる必要があるとのことです。

また、各段階を進むにつれて、Account Baselining、Service Catalog、Systems Manager、分散パイプライン、そして Cloud Center of Excellence といったツールや仕組み、チームを活用するようになっていくという説明もありました。

さいごに

Control Tower を導入した後の「次のステップ」について、非常に実践的な内容のセッションでした。

とくに「アカウント管理とリソース管理を明確に区別する」という考え方は、マルチアカウント環境を運用する上でとても重要だと感じました。AFT や LZA でワークロードリソースまで管理しようとすると管理の複雑さが増すという指摘は、これから大規模環境を構築する方にとって参考になると思います。

また、「成熟度は買えない、文化の一部である」というメッセージは印象的でした。ツールを導入するだけでなく、組織全体でガバナンスの重要性を理解し、継続的に改善していく姿勢が大切だと改めて認識しました。

セッションの最後に紹介されたリソースも共有しておきます。

この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら（＠itkr2305）でした！