今回は、2025年11月17日に発表されたControl Towerの新たなLanding Zoneである4.0について説明します。4.0は、2023年12月14日に利用可能となった3.3から約2年ぶりの新たなバージョンです。ここ数年で、Control Towerはマルチアカウント環境のベストプラクティスとして広く認知されるようになりました。多くの利用者にとってControl Tower導入後の初めてのバージョンアップになるのではないでしょうか。
Landing Zone 4.0の概要
Landing Zone 4.0では、各種AWSとの統合の多くが選択制となり、これまでにControl Tower導入時に課題となることが多い制約事項の大幅な緩和がされています。個人的に特に注目しているのは以下の3点です。
- AWS Config統合の有効/無効が選択可能
- AWS CloudTrailの組織の証跡の作成有無が選択可能
- AuditアカウントおよびLog Archiveアカウントの作成が任意
Control Towerを導入しようと考えている場合、ほとんどのケースでマルチアカウント環境がすでに存在しており、AWS ConfigやCloudTrailの設定がすでにされていることが多いです。またログもすでに集約する構成をとっているケースがほとんどで、Control Tower導入時に設定/作成されてしまう点が障害となることが多々ありました。4.0ではこれらの設定を任意で選択できるようになったため、既存環境への導入が非常に容易になっています。これにより、既存のConfigルールやCloudTrail設定をそのまま生かしつつ、Control Towerの管理機能だけを追加することが可能になりました。統合機能を「無効」に設定すれば、Control Towerが既存のリソースを上書きしたり、重複したリソースを作成して意図しないコストが発生したりする心配もありません。
Landing Zone 4.0のセットアップ
それでは、早速Landing Zone 4.0のセットアップを行ってみましょう。今回はすでに複数のAWSアカウントが稼働中のOrganizationsでの導入を試してみます。本稿では、検証のため、あえて変則的な手順をとりますが、Landing Zone 3.3を構成していた環境で、Landing Zoneを無効化し、その後Landing Zone 4.0を導入することを試してみます。 セットアップ前の状態は以下となっています。
- IAM Identity Centerの組織インスタンスは有効化されている
- Landing Zone 3.3で作成済みのAuditアカウントおよびLog ArchiveアカウントはSecurity OUに存在している
- メンバーアカウントではCloudTrailおよびConfigは有効化済み
(1)まず、管理アカウントにログインし、Control Towerのメニューを開きます。
(2)以下の画面が表示されるので、「AWS Control Towerの有効化」ボタンをクリックします。
(3)今回発表された柔軟な設定オプションを試すため、「既存の環境があり、AWS が管理するコントロールを有効化したい」を選択し、適当な管理対象リージョンを選択します。「検出管理の AWS Config」についても「AWS Configの無効化」を選択します(下図参照)。最後に「AWS Control Towerの有効化」ボタンをクリックします。
(4)ランディングゾーンのセットアップが開始されます。
(5)少し待つとランディングゾーンのセットアップが無事に完了しました。
(6)この時点では管理アカウントのみがControl Towerに登録されています。
(7)AWS ConfigやCloudTrailなどの設定も無効化となっています。IAM Identity Centerも無効化となっていますが、組織インスタンスは継続して利用可能です。IAM Identity Centerの設定が無効化されるのではなく、IAM Identity Center内のControl Towerが管理する設定(アクセス許可セットなど)が作成されていない状態が『無効化』と表示される仕様のようです。
Landing Zone 4.0の各種サービス統合の動作確認
それでは、Landing Zone 4.0によってオプションとなった各AWSサービスとの統合を一つずつ確認していきましょう。
CloudTrailの統合機能確認
まずはCloudTrailの組織の証跡から確認していきます。 動作確認前では、Log Archiveアカウント内のS3バケットに以下のようにCloudTrailのログが保管されています。
また、メンバーアカウントではアカウントレベルのCloudTrailの証跡が作成されている状態です。
(1)この状態で、Control Towerの「Landing Zoneの設定」メニューで「設定を変更する」ボタンをクリックします。
(2)次の画面では何も変更せずに「次へ」ボタンをクリックします。
(3)管理対象リージョンやリージョン拒否に関しても何も変更せずに、「次へ」ボタンをクリックします。
(4)「AWS CloudTrail 集中型ロギング」セクションで「AWS CloudTrailを有効化する」を選択し、CloudTrail管理者として、既存のLog Archiveアカウントを指定します。そのほかは変更せずに、「次へ」ボタンをクリックします。
(5)確認画面で「ランディングゾーンの更新」ボタンをクリックします。
(6)ランディングゾーンの更新が完了するのを待ちます。
それでは、この状態で再度確認してみます。 まず、Log Archiveアカウントでは、新たにCloudTrailの組織の証跡用のS3バケットが作成され、そこに組織の証跡のイベントが保存されるようになっています。
また、メンバーアカウントではアカウントレベルの証跡に加えて、組織の証跡の作成もされています。 CloudTrailの証跡は2つ目から有料となるため、すでにアカウントレベルの証跡が設定されており、その集約の仕組みがある場合は、Control TowerによるCloudTrailの統合(組織の証跡の作成)は無効化しておくほうが良いかと思います。
Configの統合機能確認
次にConfigの統合を確認してみます。 動作確認前では、メンバーアカウントでConfigは有効化されていますが、どのアカウントでもアグリゲーターは作成されていない状態とします。
(1)この状態で、Control Towerの「Landing Zoneの設定」メニューで「設定を変更する」ボタンをクリックします。
(2)次の画面では何も変更せずに「次へ」ボタンをクリックします。
(3)管理対象リージョンやリージョン拒否に関しても何も変更せずに、「次へ」ボタンをクリックします。
(4)「検出管理の AWS Config」セクションで「AWS Config の有効化」を選択し、アグリゲーターアカウントとして既存のAuditアカウントを指定します(下図参照)。そのほかは変更せずに、「次へ」ボタンをクリックします。
(5)確認画面で「ランディングゾーンの更新」ボタンをクリックします。
(6)ランディングゾーンの更新が完了するのを待ちます。
それでは、この状態で再度確認してみます。 まず、Auditアカウントでは、新たにConfigのアグリゲーターが作成され、メンバーアカウントのConfigの設定が集約されるようになっています。
Landing Zone 4.0で述べられている改善内容のように、このアグリゲーターは変更や削除はできなくなっております。
また画面上では確認できませんでしたが、下記コマンドの実行結果のように「AWSServiceRoleForConfig」のサービスロールによって実行されていることが確認できました。
$ aws configservice describe-configuration-aggregators
{
"ConfigurationAggregators": [
{
"ConfigurationAggregatorName": "aws-controltower-ConfigAggregatorForOrganization",
"ConfigurationAggregatorArn": "arn:aws:config:ap-northeast-1:{AuditアカウントのAWSアカウントID}:config-aggregator/aws-service-config-aggregator/controltower.amazonaws.com/config-aggregator-4a08lzkg",
"OrganizationAggregationSource": {
"RoleArn": "arn:aws:iam::{AuditアカウントのAWSアカウントID}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
"AllAwsRegions": true
},
"CreationTime": "2026-02-04T12:35:57.490000+00:00",
"LastUpdatedTime": "2026-02-04T12:35:57.515000+00:00",
"CreatedBy": "controltower.amazonaws.com"
}
]
}
Configレコーダーの結果もAuditアカウントのS3バケットに保存されるように変更がされていることも確認できます。
Control Towerで用意されているコントロールには、予防管理、検出管理、プロアクティブ管理の3種類がありますが、検出管理のコントロールを利用したい場合は、Config統合が必須となります。
| # | コントロール種別 | 内容 | チェックタイミング | 実現する技術 |
| 1 | 予防管理 | アクションを禁止する | AWSリソースの操作時 | SCP/RCP |
| 2 | 検出管理 | 作成済みのAWSリソースの設定値をもとに検知する | 設定変更時や定期的な評価時 | AWS Config |
| 3 | プロアクティブ管理 | 禁止された設定でのAWSリソースが作成されていないかをチェックする | AWSリソースの作成直前 | CloudFormation hooks |
Control Towerを導入したいと考えるケースでは、Control Towerでの各種AWSサービスの集中管理が目的の一つとなることが多いと思われるため、Config統合はほぼ必須となるかと思います。Landing Zone 3.3ではAuditアカウントに加えて、管理アカウントでもConfigのアグリゲーターが作成されていましたが、Landing Zone 4.0ではAuditアカウント(アグリゲーターアカウント)のみに集約されるようになっているため、シンプルでわかりやすい構成となりました。
IAM Identity Centerの統合機能確認
最後にIAM Identity Centerの統合についても確認してみます。
(1)Control Towerの「Landing Zoneの設定」メニューで「設定を変更する」ボタンをクリックします。
(2)次の画面では何も変更せずに「次へ」ボタンをクリックします。
(3)管理対象リージョンやリージョン拒否に関しても何も変更せずに、「次へ」ボタンをクリックします。
(4)「AWS IAM アイデンティティセンターのアカウントアクセス」セクションで「AWS Control Tower は IAM Identity Center を使用して AWS アカウントアクセスを設定します。」を選択します。そのほかは変更せずに、「次へ」ボタンをクリックします。
(5)確認画面で「ランディングゾーンの更新」ボタンをクリックします。
(6)ランディングゾーンの更新が完了するのを待ちます。
(7)Control Towerの「ユーザーとアクセス」メニューを開くと、IAM Identity Centerとの連携が設定されていることが確認できます。Control Tower用のアクセス許可セットやグループが作成される挙動となります。
なお、この連携設定を行っても、既存のIAM Identity Centerで作成済みのユーザーやグループ、割り当て済みのアクセス権限には影響ありません。既存の運用を維持したまま、Control Tower用の権限セットを追加で管理できるようになります。
既存AWSアカウントにおける注意点
ここまで各AWSサービスとの統合について説明してきましたが、既存AWSアカウントをControl Towerで管理する際には注意点があります。ここまで説明してきたLanding Zoneのセットアップ手順を実施するだけでは、既存AWSアカウントにControl Towerのベースラインの適用がされません。ベースラインとはControl Towerの管理上必要なAWSリソースやSCPなどです。Landing Zone 4.0では、Control Towerの管理下に置くと、公式ドキュメントに記載の通り、下記のブループリント(実態はCloudFormation Stack)がメンバーアカウントに適用されます。Control Tower管理下に置かない場合は、メンバーアカウントに下記のAWSリソースが作成されない状態となり、Control Towerの一部機能が利用できない可能性があります。
| # | ブループリント | 内容 |
| 1 | BP_BASELINE_CLOUDWATCH | メンバーアカウントのConfig Ruleのコンプライアンスステータス変更をAuditアカウントのSNSへ転送するLambdaなどの作成 |
| 2 | BP_BASELINE_CONFIG | ConfigレコーダーおよびConfig配信チャネルの作成 |
| 3 | BP_BASELINE_ROLES | aws-controltower-AdministratorExecutionRoleなどのAuditアカウントからの操作用IAMロールの作成 |
| 4 | BP_BASELINE_SERVICE_LINKED_ROLE | Control Tower用のサービスリンクロールの作成(ただしメンバーアカウントに対するリソース作成はなし) |
| 5 | BP_BASELINE_SERVICE_ROLES | BP_BASELINE_CLOUDWATCHで作成されたLambdaを実行するIAMロールであるaws-controltower-ForwardSnsNotificationRoleの作成 |
| 6 | Config SLR | Config用のサービスリンクロールの作成 |
| 7 | IAM リソース | AWSControlTowerExecutionロールの作成 |
Config配信チャネルやレコーダーがセットアップ済みの既存アカウントをControl Tower管理下に登録しようとすると、BP_BASELINE_CONFIGが阻害要因となり、登録に失敗してしまいます。登録するためには、一度Config配信チャネルやレコーダーの削除が必要となりますので、この作業のハードルが高いケースも出てくるかと思います。Control Towerへ登録されていないAWSアカウントに対する検出管理コントロールでの設定チェックはできないため、注意ください。
まとめ
Landing Zone 4.0では、Control Tower導入時の制約事項が大幅に緩和され、既存環境への導入が非常に容易になりました。これまでControl Tower導入時に強制的に実施されてしまっていた設定の多くがオプション化されており、後からでも設定することが可能となっていることがおわかりいただけたかと思います。本稿がControl Tower導入の一助となれば幸いです。



























