AWS Control Towerのランディングゾーンv4.0のまとめ
投稿日: 2026/3/31
はじめに
こんにちは、高橋です。
AWS Control Tower のランディングゾーンは、約 2 年ぶりにアップデートされ、バージョン 4.0 となりました。
本アップデートにより利便性は向上した一方で、バージョンアップ時に注意すべき点も見受けられます。
そこで本記事では、AWS Control Tower のランディングゾーン v4.0 について整理してご紹介します。
なお、「そもそも AWS Control Tower とは何か？」という方は、以下の過去記事をご参照ください。
1. バージョン4.0の主な変更点
2年ぶりの更新ということもあり、バージョン 3.3 からはさまざまな機能変更が行われました。
主な変更点は以下のとおりです。
| 項目 | バージョン 3.x（従来） | バージョン 4.0（変更後） |
|---|---|---|
| AWS Config | 自動的に有効 | 有効・無効を選択可能 |
| Audit / LogArchiveアカウントの扱い | Auditは必須、LogArchiveは任意 | どちらも任意 |
| Security OU | 必須でAudit / LogArchiveアカウントはこちらに配置 | 必須ではなく、Audit / LogArchiveアカウントは任意のOUに所属可能 |
| AWS Config Logの扱い | LogArchiveアカウントに集約 | Auditアカウントに集約 |
| ドリフト検出通知 | SNS（AggregateSecurityNotifications） | EventBridge（管理アカウント） |
最も大きな変更点は、これまで必須だった AWS Config を、任意で有効・無効に選択できるようになった点です。
この変更により、前述の 4 つの変更点が発生しています。
すでにバージョン 3.3 の時点で CloudTrail は任意で有効・無効を選択できるようになっていましたが、今回新たに AWS Config も選択可能となったことにより、従来は AWS Control Tower を利用する際に必須であった Audit アカウントおよび LogArchive アカウントを用意する必要がなくなり、より手軽に Control Tower を利用できるようになりました。
また、CloudTrail と AWS Config の統合を無効化した場合でも、コントロール機能のみを利用することが可能です。
これは以前から要望の多かった変更となります。
なお、AWS Config を無効化すると、AWS Control Tower に統合されている IAM Identity Center および AWS Backup も利用できなくなる点には注意が必要です。
では、ここからは、管理アカウントのみで構成された AWS Control Tower の設定および動作と、バージョン 3.3 から 4.0 へアップグレードする際の注意点を見ていきたいと思います。
2. スタンドアローン構成のControl Tower
先述のとおり、バージョン 4.0 からは Audit アカウントおよび LogArchive アカウントを使用しない、スタンドアローン構成で AWS Control Tower を構成できるようになりました。
これにより、コントロール機能のみを利用する Control Tower の構成が可能となっています。
ここでは、実際にセットアップおよびコントロールの設定を行ってみたいと思います。
スタンドアローン構成で利用する場合は、Control Tower の有効化を開始した際に表示される設定画面にて、「既存の環境があり、AWS が管理するコントロールを有効化したい」を選択し、そのまま設定を完了させるだけです。
すると下記の通り、AWS Config/CloudTrail/IAM Identity Center/BackupというこれまでControl Towerに統合されていた機能を使用しない構成にすることができます。
それでは、この状態でコントロール機能を有効化してみたいと思います。
コントロールの有効化は、左側メニューから 「Control Catalog」 を選択し、有効化したいコントロールを選んだうえで 「コントロールを有効化する」 ボタンをクリックすることで実施できます。今回は、root アカウントでの Access Key の作成を禁止するコントロール を選択してみました。
あとはこのコントロールを適用するOUを選択して、設定を完了すれば、対象のOUに対して、コントロールによる制御が実行されます。
実際にコントロールを適用したOU（Sandbox）を確認してみると、コントロールが適用されていることが確認できます。
3. バージョン4.0へのアップグレード
続いて、バージョン 3.x から 4.0 へアップグレードした際に生じる違いについて見ていきたいと思います。
バージョン 3.x と 4.0 の大きな違いは、これまでにも触れてきたとおり AWS Config の扱いにあります。AWS Config を任意で選択できるようになった点はもちろんですが、それ以上に、Control Tower を構成する各コンポーネントを個別に選択できるようになったことで、全体の構成自体が大きく変わっています。
その結果、比較表に記載しているとおり、ログの管理方法にも変更が生じました。実際にバージョンアップ前の構成では、CloudTrail のログおよび AWS Config のログは、すべて LogArchive アカウント内の 1 つの S3 バケット（aws-controltower-logs-xxx）に保存されていました。
これに対して、バージョンアップ後は AWS Config のログが Audit アカウント内に新たに作成される S3 バケット（aws-controltower-config-logs-xxx）に保存されるようになります。
また、通知に使用される SNS Topic の設定にも変更がありました。具体的には、バージョン 3.x までは CloudTrail と AWS Config の両方に、同一の SNS Topic（aws-controltower-AllConfigNotifications）が設定されていました。そのため、両サービスのイベントはすべてこの SNS Topic を通じて通知されていました。
一方、バージョンアップ後は AWS Config に設定されている SNS Topic に変更はありませんでしたが、CloudTrail の SNS Topic は aws-controltower-CentralizedLoggingNotifications に変更されていました。
そのため、このままにしておくと SNS の通知が途切れてしまう事象が発生します。通知による監視を行っている場合は、バージョンアップ後に新しい SNS Topic に対して、あらためて通知設定を行う必要があります。
4. さいごに
今回は、久しぶりにリリースされた AWS Control Tower のランディングゾーン新バージョンについてまとめました。新しいバージョンでは必須コンポーネントが廃止され、構成の自由度が向上したことで、より使い勝手のよいサービスとなっています。
一方で、その影響により、バージョンアップを行うと従来の構成が変更されます。そのため、Control Tower のログ管理や通知による監視を行っている場合は、新しい構成に合わせた設定変更が必要となります。
これらの点を十分に理解したうえで、新しいバージョンを活用していただければと思います。
