[Chalk talk] Agile governance: Deploy AWS Control Tower in your current environment に参加しました #COP354 #AWSreInvent

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

2025 年の最終日ですが、現地で受けてきたセッション「Agile governance: Deploy AWS Control Tower in your current environment」を紹介します。
Chalk talk セッションはスピーカーと参加者がインタラクティブにやりとりするため、聞き取れなかった部分もありますがご了承ください。

3 行まとめ

• 既存環境（Brownfield）に Control Tower を導入する場合、管理アカウントにワークロードがなければ既存組織に、あれば新規組織への導入を検討する
• 予防的コントロール（SCP）は OU 階層を継承するが、検知的コントロール（Config ルール）は子 OU に継承されないため注意が必要
• 組織間のアカウント移行は「Direct Account Transfer」機能により簡素化され、請求やサポートプランも維持される

セッション概要

• セッション ID: COP354
• タイトル: Agile governance: Deploy AWS Control Tower in your current environment
• スピーカー
  • Pujah Goviel, Technical Account Manager, AWS
  • Vijay Shekhar Rao, Systems Engineer, AWS
• レベル: 300 – Advanced

How do you extend governance over your AWS environment in production without disrupting existing workloads? AWS Control Tower is the place to set up a well-architected, multi-account environment to govern your AWS workloads, and works hand in hand with AWS Organizations. In this chalk talk, explore proven approaches for enabling AWS Control Tower while preserving operational continuity. Learn to integrate AWS Control Tower with AWS CloudTrail, AWS Config and other foundational services you already use. Walk away with practical strategies to enhance your multi-account governance.

（機械翻訳）
既存のワークロードを中断することなく、本番環境の AWS 環境のガバナンスを拡張するにはどうすればよいでしょうか？AWS Control Tower は、AWS ワークロードを統括するための、適切に設計されたマルチアカウント環境を構築するためのツールであり、AWS Organizations と連携して機能します。このチョークトークでは、運用の継続性を維持しながら AWS Control Tower を有効化するための実証済みのアプローチを探求します。AWS Control Tower を AWS CloudTrail、AWS Config、その他既にご利用いただいている基盤サービスと統合する方法を学びます。マルチアカウントガバナンスを強化するための実践的な戦略を習得できます。

セッション内容

Control Tower の概要

Control Tower は自動化されたガバナンスを提供するサービスです。すでにテストされて実証済みのベストプラクティステンプレートが付属しており、環境の管理にすぐ使える多数のマネージドコントロールが提供されています。

ランディングゾーンをデプロイすると、管理アカウントに Control Tower が設定され、ログアーカイブアカウント（S3 バケットと集中ログ）と監査アカウント（Config アグリゲーター）が作成されます。また、14 以上の基盤サービス（AWS Organizations、IAM Identity Center、AWS Config、CloudTrail など）と連携します。

新規環境と既存環境への導入

新規のお客様（Greenfield）の場合は非常にシンプルです。新しいアカウントにサインアップし、Control Tower サービスでランディングゾーンをセットアップするだけで、30 分以内に Well-Architected な環境が構築できるとスピーカーは言っていました。
（30 分以内は言い過ぎでは？と思いましたが、ランディングゾーン 4.0 の Controls Dedicated experience のセットアップなら早いのかな？と聞きながら思いました。）

しかし、既存の AWS アカウントを持っている場合（Brownfield）は考慮事項が多くなります。

既存環境への Control Tower 導入方法

既存環境への導入には主に 2 つのアプローチがあります。

アプローチ 1: 既存の管理アカウントに Control Tower をデプロイ

管理アカウントがクリーンな状態（ワークロードがない）であれば、既存の組織にそのまま Control Tower をデプロイできます。

重要なポイントとして、ランディングゾーンをデプロイしただけではリンクされたアカウントにコントロールは適用されません。その後に OU を登録することで、はじめてガバナンスが拡張されます。

アプローチ 2: 新しい組織に Control Tower をデプロイ

管理アカウントでワークロードを運用している場合は、新しい組織を作成して Control Tower をデプロイすることが推奨されます。Control Tower のガバナンスは実際にはリンクされたアカウントで行われるため、管理アカウント内のリソースは管理対象外となります。また、管理アカウントでワークロードを動かしていると、運用担当者や開発者に管理アカウントへのアクセス権を与えることになってしまいます。

新しい組織に Control Tower をデプロイした後、既存アカウントを新しい組織へ移行します。

ランディングゾーン設定の考慮事項

Governed regions と Region deny

Control Tower をセットアップする際、ホームリージョンを選択します。ワークロードがある 2〜3 のリージョンをガバナンス対象リージョンとして選択します。

すべてのリージョンをガバナンス対象にすると、Detective コントロール（Config ルール）がすべてのリージョンに適用されるため、不要なコストが発生します。

ガバナンス対象外のリージョンを使用禁止にしたい場合は、Region deny を OU レベルで設定できます。

コアアカウントのオプトイン

既にランディングゾーンが定義されている場合、Control Tower に新しいアカウントを作成させるのではなく、既存の Config アグリゲーターアカウントを監査アカウントとして、既存のログ集約アカウントをログアーカイブアカウントとして取り込むオプションがあります。

その他のオプション設定

その他にも、S3 バケットの保持設定やアクセスログ設定、KMS 暗号化の有効化（推奨）、CloudTrail のオプトアウト（既存の組織証跡がある場合）などのオプションがあります。

IAM Identity Center の考慮事項

既存環境に IAM Identity Center がすでに設定されている場合、Control Tower デプロイ時にオプトアウトできます。同じリージョンに設定されていれば、Control Tower は既存の設定をそのまま維持します。

なお、組織間で IAM Identity Center を移行するためのバックアップ・リストア機能は現時点では存在しません。新しい組織で再作成が必要です（この機能については製品の機能追加要望が上がっているとのことです）。

AWS Config の考慮事項

既存の AWS Config 設定がある環境で Control Tower を有効化する場合、重要な考慮事項があります。

コアアカウント（ログアーカイブ、監査アカウント）

既存の Config レコーダーとデリバリーチャネルをすべてのリージョンから削除する必要があります。これは必須の手順であり、Control Tower が独自の Config 設定を正しく確立するために必要です。

メンバーアカウント

メンバーアカウントについては、コアアカウントと同様に既存の Config 設定を削除する方法と、サポートケースを作成してホワイトリストに登録することで既存の Config レコーダーとデリバリーチャネルを維持する方法の 2 つがあります。

後者が推奨される理由は、Config レコーダーが削除ではなく更新されるため、設定の再記録によるコストスパイクを抑えられるからです。

なお、Config ルール、アグリゲーター、コンフォーマンスパック、リソースコンプライアンス履歴、リソースタイムラインについては、どちらの方法でも維持されます。

一時的な可視性の喪失

ランディングゾーンの有効化中（約 30〜40 分）は Config レコーダーが停止するため、一時的に Config データが利用できなくなります。運用チームやセキュリティチームにはこのデプロイウィンドウを事前に通知することが推奨されます。

請求とサポートの考慮事項

Direct Account Transfer

数週間前にリリースされた新機能で、組織間でアカウントを直接移行できるようになりました。従来は、アカウントをスタンドアロンにしてから連絡先情報や請求支払い、サポートプランを手動で更新する必要がありましたが、新機能では新しい組織から招待を送信し、移行対象のアカウントが招待を受け入れるだけで完了します。

コスト配分タグ

移行中にアクティブステータスが失われるため、移行前に有効化し、移行後にも再度有効化が必要です。新しい組織でタグが再表示されるまでに約 24 時間かかります。

請求履歴

請求履歴は移行されないため、移行前に Cost Explorer レポートやカスタマイズレポートをエクスポートしておくことが推奨されます。

Savings Plans と Reserved Instances

メンバーアカウントで購入した Savings Plans や Reserved Instances は、アカウントと一緒に移行され、新しい組織に自動的に適用されます（機能共有の有効化を確認する必要はあります）。一方、管理アカウント（Payer アカウント）で購入した場合は、サポートに連絡して移行の可能性を確認する必要があるとのことでした。

コントロールの適用

必須コントロール

Control Tower をデプロイすると、必須コントロール（SCP）が適用されます。これは Control Tower 自身の設定を保護するためのもので、例えば Config サービスの停止や設定変更を防止します。

予防的（Preventive）コントロール vs 検知的（Detective）コントロール

予防的コントロール（SCP）は OU 階層を継承し、子 OU やアカウントにも適用されます。一方、検知的コントロール（Config ルール）は適用した OU の直下のアカウントにのみ適用され、子 OU には継承されません。

この動作は直感的ではないため、注意が必要です。子 OU にも検知的コントロールを適用したい場合は、その OU でも改めて適用する必要があります。

コントロールのベストプラクティス

Control Tower、Security Hub、Config と複数の方法でコントロールを適用できますが、まず Control Tower で利用可能なコントロールを使用し、Control Tower でカバーされていない部分を Config で補完することが推奨されます。

コントロールライブラリでは、強く推奨されるコントロール、フレームワーク別（業界固有のコンプライアンスフレームワークなど）、サービス別（S3、EC2 など）、目的別（データ保護など）といった方法でコントロールを検索・フィルタリングできます。

新しい機能について

セッションでは、Control Tower Landing Zone バージョン 4.0 がリリースされたことが紹介されました。主な新機能として「Controls Dedicated experience」があります。

また、ランディングゾーンを最新バージョンに更新した後は OU の再登録が必要になるため、健全なランディングゾーンを維持するための継続的なメンテナンスも重要です。

さいごに

Direct Account Transfer による組織間移行の簡素化や、Landing Zone 4.0 の Controls Dedicated experience など、Control Tower は継続的に改善されています。既存環境への導入を検討されている方は、最新のドキュメントも併せてご確認ください。
https://docs.aws.amazon.com/controltower/latest/userguide/2025-all.html#lz-40

Controls Dedicated experience について詳しく知りたい方は、以下のセッションレポートも併せてご覧いただければと思います。
https://dev.classmethod.jp/articles/202512-reinvent2025-cop365-chalktalk/

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