はじめに

Control Tower未使用の状態からセットアップする流れについて書きたいと思います。

2025/11/17にランディングゾーンのバージョン4がリリースされました。
バージョン4以前との差異について軽く触れていますが、網羅的には触れられていません。

本記事の主題としては、現時点（2026/1）における最新の初期セットアップの流れがどうなっているかを残しておければと思います。

前提条件

OrganizationsでConfigの「信頼されたアクセス」が有効になっている場合は無効にしておく必要があります。

セットアップの流れ

Control Towerを有効化します。

ステップ1 - セットアップ設定を選択

バージョン4からControl Towerのコントロールのみを利用できるようになりました（右側）。
今回は従来からあったランディングゾーン含む設定をしていきます（左側）。

リージョン拒否コントロールはデフォルトで無効が選択されていますが、有効にしてみます。

確認をクリックします。

自動アカウント登録はデフォルトでチェックが入っています。このまま次へ進みます。

「自動アカウント登録」は2025/11/10にリリースされた機能です。

アカウントを移行したり、OU 構造を変更したりする際に、お客様がアカウントを手動で更新したり、OU を再登録したりする必要がなくなりました。アカウントが新しい OU に移動されると、AWS Control Tower は自動的にそのアカウントを登録し、新しい OU のベースライン設定とコントロールを適用し、元の OU のベースライン設定とコントロールを削除します。

(引用元) https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-control-tower-automatic-enrollment/

ステップ2 - OU作成

Securityは必須、Sandboxはオプションです（デフォルトではチェックが入っています）。

OU名が日本語表記になってしまっていますが、実際に作られるOU名はSecurityとSandboxです。

OUが作成されました。

なお、Security OUの名称は後から変えられます。

AWS Control Tower は、[Foundational OU] (基礎となる OU) (当初の名前は [Security OU] (セキュリティ OU)) を利用します。この OU の名前は、初期セットアップ時やその後に OU の詳細ページから変更できます。
(引用元) https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/configure-ous.html

ステップ3 (オプション) - サービス統合を設定

バージョン4から、Control Towerによって自動的に実装される各種サービスをそれぞれ有効/無効化できるようになっています。

オプションのサービス統合 - ランディングゾーン 4.0 では、環境で有効にするサービス統合を選択できます。統合を無効にすると、マネージドアカウントとサービス統合中央アカウントで、その統合に固有の AWS Control Tower がデプロイしたリソースがクリーンアップされます。サービス統合を選択的に有効または無効にできるようになりました。

AWS Config

AWS CloudTrail

セキュリティロール

AWS バックアップ

(引用元) https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/2025-all.html#lz-40

OU

「サービス統合のデフォルトOU」と記載されていますが、こちらはドキュメントにおける「Foundational OU」のことです。

Control Towerによって利用されるログアーカイブアカウントと監査アカウントは、この「Foundational OU」に属している必要があります。

AWS Control Tower では、各 AWS サービス統合用に設定されたすべてのアカウントが同じ親 OU の下にある必要があります。
(引用元) https://docs.aws.amazon.com/controltower/latest/userguide/key-changes-lz-v4.html

ログアーカイブアカウントと監査アカウントは、Control Towerにおいて「共有アカウント」または「ハブアカウント」と呼ばれるアカウントです。

以前は共有アカウントが「Security OU」に属している必要がありましたが、バージョン4でその制約がなくなりました。つまり、共有アカウントが属するOUに任意のOUを利用できるようになったということです。ただし、すべての共有アカウントが同じOUに属する必要があります。

Flexible Organization Structure - ランディングゾーン 4.0 は、以前の組織構造要件を削除します。

セキュリティ OU を使用する必要がなくなりました

独自の組織構造を定義できます

唯一の要件は、すべてのハブアカウントが同じ OU 内にあることです。

(引用元) https://docs.aws.amazon.com/controltower/latest/userguide/2025-all.html#lz-40

Config

Configは有効で進めます。

画面上の「アグリゲーターアカウント」はControl Tower共有アカウントの内のログアーカイブアカウントのことです。
新規作成からアカウントを作成します。「アカウント名を変更」の部分にデフォルト値として「アグリゲーターアカウント」と入力されています。

そのまま作成を進めると・・・エラーになりました。日本語は使えないですよね・・・

英語で設定したところ、アカウント作成に成功しました。

その他オプションを適当に設定します。

CloudTrail

CloudTrailも有効で進めます。
アカウント名にはここでも日本語で「CloudTrail 管理者」とデフォルト値が入力されていますが、英語名で入力して作成を進めます。

作成できました。

その他オプションを適当に設定します。

Identity Center

Identity Centerは設定済みであったため、左側を選択しました。

BackUp

BackUpは、今回はデフォルトの無効で進めます。

ステップ4 - 確認

これまでの設定内容を確認します。

Control Towerを有効化します。

20～30分ほどで設定が完了しました。

ここまででセットアップは完了です。

実装内容を確認

バージョン4の変更点の一つに下記があります。

AWS Configおよび AWS CloudTrail では、共有リソースの代わりに個別の専用 S3 バケットと SNS トピックを使用するようになりました。
(引用元) https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/config-updates-v4.html

CloudTrailとConfigの設定を見ていきたいと思います。

CloudTrail

CloudTrailのログ記録アカウントには先ほど「CloudTrail管理者アカウント」に設定したアカウント（今回はaudit）が設定されており、S3バケットにはauditアカウント上のaws-controltower-cloudtrail-logs-プレフィックスのバケットが設定されています。

証跡は「組織の証跡」(参考) として管理アカウントに作成されます。
ログの配信先については、S3はauditアカウント、CloudWatchログは管理アカウントに指定されています。

Config

Configのアグリゲーターアカウントには、先ほど「アグリゲーターアカウント」に設定したアカウント（今回はlog）が設定されています。

アグリゲーターアカウントのConfig設定を確認すると、Config配信先バケットはアグリゲーターアカウントになっています。

アグリゲーターはログアーカイブアカウントに作成されます。

ランディングゾーンアップグレードの場合

ランディングゾーンをバージョン4にアップグレードする場合は下記の挙動になるようです。

既存データ
- そのまま既存の保管場所に残る
新規データ
- CloudTrail: 既存のS3バケットが引き続き利用される
- Config: 新しいS3バケットに保管されるようになる

バージョン 4.0 にアップグレードする場合、既存のデータと S3 バケットは移動されません。AWS CloudTrail 統合では、プレフィックスがaws-controltower-logsの既存の S3 バケットが引き続き使用されます。更新オペレーション後の新しい AWS Config データは、AWS Control Tower が CentralConfigBaseline に指定されたアカウントに作成するプレフィックスaws-controltower-configを持つ新しい S3 バケットに保存されます。
(引用元) https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/config-updates-v4.html

ドリフト通知

バージョン4からドリフト通知の仕様が変わっており、通知を受け取る場合はEventBridgeで通知を実装する必要があります。

AWS Control Tower は、 AWSControlTowerBaselineを有効にせずにランディングゾーン 4.0 のすべてのお客様の SNS トピックへのドリフト通知の送信を停止し、代わりに管理アカウントの EventBridge へのドリフト通知の送信を開始します。
(引用元) https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/key-changes-lz-v4.html

そもそもControl Towerにおけるドリフトとは下記のとおりで、Control Tower上のガバナンス設定とアカウントの実態に差異が生じている状態のことです。

ガバナンスドリフトは組織ドリフトとも呼ばれ、OU、SCP、およびメンバーアカウントが変更または更新されたときに発生します。AWS Control Tower で検出できるガバナンスドリフトのタイプは次のとおりです。

アカウントと OU ガバナンスのドリフト

ランディングゾーンのドリフト

非 SCP コントロールのコントロールドリフト

ベースラインとコントロールの継承ドリフト

(引用元) https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/governance-drift.html

さいごに

今回はランディングゾーンバージョン4におけるControl Towerのセットアップを試してみました。
CloudTrailとConfigのログ保管先バケットが変わったり、共有アカウントが属するOUの名称が任意に変えられるようになったりして、融通が効くようにはなった点は良いと思いますが、呼称に関してはちょっとややこしいと感じました。会話の中で何を指しているか気を付けないと認識齟齬が生じる可能性もあるかもしれません。
さいごに、このややこしい部分を表で整理しておきたいと思います。

V4以前の呼称	V4以前の主な用途	V4セットアップ中	V4セットアップ後	V4の主な用途	アカウント名
ログアーカイブアカウント	CloudTrailとConfigのログを単一バケットで保持	アグリゲーターアカウント	AWS Config > アグリゲーターアカウント	・ConfigログをS3で保管・Configアグリゲーター	・`log archive`が当初のアカウント名・デフォルトのまま使う顧客が多い
監査アカウント	・Configアグリゲーター・コンプライアンス非準拠通知	CloudTrail管理者	AWS CloudTrail集中型ログ記録 > ログ記録アカウント	CloudTrailログをS3で保管	・`audit`が当初のアカウント名・`Security`とする顧客が多い

弊社では一緒に働く仲間を募集中です！

現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。