aws

AWS Control Tower Landing Zoneとは?構成要素とv4.0の変更点を解説

AWS Control TowerのLanding Zone(ランディングゾーン)は、AWS Organizations上に複数アカウントの統制基盤を自動で組み上げる仕組みです。管理・ログ・監査のアカウントからガードレール、集中ログまでを一括で整えるため、マルチアカウント運用の「土台」として使われます。本記事では、Landing Zoneとは何かと自動構築される構成要素を押さえたうえで、2026年7月時点で最新のv4.0で変わった点――サービス統合の選択制、Security OUの自動作成廃止、ドリフト通知のEventBridge移行まで整理します。

Control Tower全体の定義や料金、導入すべきかどうかの判断基準は、上位概念をまとめたAWS Control Towerとは(定義・料金・導入判断)で解説しています。

まとめ

  • Landing Zoneは、AWS Control TowerがOrganizations上に自動構築する標準化されたマルチアカウント環境。管理アカウント・ログアーカイブアカウント・監査(Audit)アカウントに、OUとコントロール(ガードレール)、CloudTrail/AWS Configの集中ログを組み合わせる。
  • 最新バージョンはv4.0(2026年7月時点で4.1以降は未リリース)。最大の変更は、AWS Config・CloudTrail・SecurityRoles・Backupの統合を任意に有効化/無効化できる「選択制」の導入。
  • v4.0はSecurity OUの自動作成をやめ、既存の組織構造をそのまま活かせる。統合アカウントを収めるOUが「designated Security OU」になる。
  • ドリフト通知はSNSトピックから管理アカウントのEventBridgeへ移行した。
  • CloudTrailとAWS Configのログは、既定でログアーカイブアカウント内の別々の専用S3バケットに分離される。

以下で、構成要素とv4.0の変更点、アップデート時の実務ポイントを順に見ていきます。

AWS Control Tower Landing Zoneの定義と役割分担

Landing Zoneとは、AWS Control Towerが構築する「共通ルールが最初から効いたマルチアカウント環境」を指します。単体のサービス名ではなく、Control Towerを有効化したときに展開されるアカウント群・組織単位(OU)・コントロール・ログ収集の一式をまとめた呼び名です。企業がゼロからガバナンスを設計する代わりに、AWSのベストプラクティスに沿った初期状態をボタン操作で得られる点が価値になります。

役割の切り分けは押さえておくと理解が早くなります。AWS Organizationsが複数アカウントを束ねる「構造」を提供し、AWS Control Towerがその上でガードレール適用やアカウント払い出しを自動化する「統制の型」を提供します。そしてControl Towerが実際にデプロイする具体的な環境そのものがLanding Zoneです。Control Towerの基本用語やOrganizationsとの違いはAWS Control Towerにおける基本用語の解説と理解の重要性で整理しているため、前提を確認したい場合はあわせて参照してください。

Landing Zoneが自動構築する構成要素

Landing Zoneを有効化すると、ガバナンスに必要なアカウント・組織構造・統制・ログ基盤がまとめて作られます。何がどこに作られるかを構成要素ごとに分けて見ていきます。

共有アカウント(管理・ログアーカイブ・監査)

Landing Zoneは3種類の中核アカウントを前提にします。すべての起点となる管理アカウント、組織全体のログを集約するログアーカイブアカウント、セキュリティ監査用の監査(Audit)アカウントです。ログアーカイブアカウントにはCloudTrailやAWS Configのログが集められ、監査アカウントには組織横断でコンプライアンス状況を確認するための権限が集約されます。ワークロード用の各アカウントとログ・監査アカウントを分離することで、運用者が本番環境を触ってもログ保全と監査の独立性が保たれます。

組織単位(OU)とコントロール(ガードレール)

アカウントはOU(組織単位)でグループ化され、OU単位でコントロール(旧称ガードレール)が適用されます。コントロールには、禁止操作をSCPで止める予防的(Preventive)、逸脱をAWS Configで検知する検出的(Detective)、リソース作成前に評価するプロアクティブ(Proactive)の3種類があります。これにより「ルートユーザーのアクセスキー作成を禁止する」「暗号化されていないストレージを検知する」といった統制を、アカウントごとに手作業で設定せずOU単位で一括適用できます。

集中ログ基盤(CloudTrail・AWS Config)とIAM Identity Center

Landing Zoneは監査に必要なログ基盤も初期構築します。API操作の証跡は組織全体でAWS CloudTrailが記録し、リソース設定の変更履歴とコンプライアンス評価はAWS Configが担います。構成監査サービスとしての仕組み・ルール評価・料金の考え方と導入判断はAWS Configとは何かを実装者目線で解説した記事で確認できます。CloudTrailの仕組みはAWS CloudTrailとは?監査とセキュリティを強化する仕組みで詳しく解説しています。加えて、複数アカウントへのサインインはIAM Identity Center(旧AWS SSO)で一元化され、アカウントごとにIAMユーザーを作らずに権限セットで統合管理できます。「集中型ロギングソリューション」を自前で構築する代わりに、この一式がテンプレートとして手に入るのがLanding Zoneの実務的な利点です。

Landing Zone v4.0の主な変更点

v4.0は、従来「一括で必須」だった統合機能を選べるようにした大型アップデートです。v3.3以前との差分を、影響の大きい3点に絞って整理します。

サービス統合の選択制と有効化・無効化の依存順序

v4.0では、AWS Config・CloudTrail・SecurityRoles・AWS Backupの各統合を任意にON/OFFできるようになりました。v3.3以前はConfigとSecurityRolesが暗黙的に常時有効でしたが、v4.0でAPI上にenabledフラグを持つ設定として初めて表面化しています。「自社に集中バックアップ基盤があるためBackup統合は不要」といった構成が可能です。ただしベースライン間に依存関係があり、無効化は下から順に外す必要があります。

ベースライン 有効化の前提 無効化の前提
CentralConfigBaseline なし(独立) SecurityRoles・IdentityCenter・Backupを先に無効化
CentralSecurityRolesBaseline CentralConfigBaselineが有効 IdentityCenter・Backupを先に無効化
IdentityCenterBaseline CentralSecurityRolesBaselineが有効 単独で無効化可
BackupCentralVault/BackupAdmin CentralSecurityRolesBaselineが有効 単独で無効化可
LogArchiveBaseline なし(独立) 単独で無効化可

Configを外したい場合、SecurityRolesやBackupがConfigに依存しているため、先にそれらを無効化しないとConfigは無効化できません。設定を変更するときは、この順序をアップデート計画に組み込んでおくと途中失敗を避けられます。

Security OU自動作成の廃止と組織構造の柔軟化

v3.3以前は、Control Towerがセットアップ時に「Security」という専用OUを自動作成し、その配下に監査・ログアーカイブを固定配置していました。v4.0ではこの強制がなくなり、既存の組織構造をそのまま使えます。代わりに、統合アカウントを収めているOUが「designated Security OU」として扱われます。このOUにはAWS Control TowerベースラインとAWS Config Baselineは適用されず、ベースライン状態は「Not Applicable」と表示されます(正常な挙動)。要件として、各サービス統合の中核アカウントは同一の親OU配下に置く必要があります。加えて、この統合アカウントが在籍するOUへ通常のメンバーアカウントを移動させると、当該OUで有効なコントロールがドリフト扱いになる点にも注意します(自動登録のON/OFFにかかわらず発生)。

ログの専用バケット分離とConfig集約のサービスリンク化

v4.0では、CloudTrailとAWS Configのログがログアーカイブアカウント内の別々の専用S3バケットに分離されます(両者を同一バケットで共有していた構成からの変更)。サービスごとにライフサイクルやアクセス制御を個別に設定でき、統合を無効化する際も関連バケットだけを切り離せます(Config専用バケットは既定ではログアーカイブアカウントに、CentralConfigBaselineの指定先アカウントへ作成されます)。また、旧来は管理アカウントのOrganization Aggregatorと監査アカウントのAccount Aggregatorという二段構えだったConfig集約が、サービスリンク型のConfig Aggregatorによる集約に刷新され、組織全体のコンプライアンスデータをより単純な構成で一元把握できるようになりました。既存のSIEMやログ分析基盤が特定バケットを参照している場合は、新しいバケットも収集対象に追加する対応が必要です。

ドリフト検出と通知の変更(SNSから管理アカウントのEventBridgeへ)

ドリフトとは、Control Towerが適用したコントロールやベースラインの状態から、手動変更などによって環境が逸脱することを指します。例えばガードレールで禁止した設定が有効化された、共有アカウントの配置要件を満たさなくなった、といった状態です。「control tower ドリフト」で情報を探す運用者が多い領域で、v4.0では通知経路が大きく変わりました。

v3.3以前は、ドリフト検出時に監査アカウントのSNSトピックへ通知が発行されていました。v4.0では、AWSControlTowerBaselineを適用していない環境に対し、管理アカウントのEventBridgeへイベントが発行される方式へ移行し、SNS通知は停止します。通知を受け取るには、管理アカウントでイベントソースaws.controltowerのドリフトイベントに一致するEventBridgeルールを作成し、SNSメール・Lambdaによる自動修復・Slackへの転送などのターゲットへルーティングします。1つのイベントを複数ターゲットへ同時配信でき、インシデント対応の自動化に組み込みやすくなった一方、ルールを作らないと通知が届かなくなるため、アップデート時に必ず設定が必要です。あわせて、v4.0では「ガバナンス下」の定義が変わり、AWSControlTowerBaselineの有無ではなく、何らかのControl Towerリソースが有効なアカウント/OUが統制対象とみなされる点にも注意します。

v3.3からv4.0へアップデートする際の実務ポイント

アップデート自体はControl Towerのランディングゾーン更新操作で実行できますが、事前準備を誤ると途中で失敗します。既存環境からの移行で押さえるべき点を絞って挙げます。

  • CloudTrailロールの付け替え(API更新時):API経由でv4.0へ更新する場合、AWSControlTowerCloudTrailRoleのインラインポリシーをデタッチし、新しいマネージドポリシーAWSControlTowerCloudTrailRolePolicyをアタッチしておく必要があります。
  • 更新と同時に統合を無効化しない:AWS ConfigやSecurityRolesの統合は、更新の一部として無効化しないこと。v4.0へ更新が完了してから、必要に応じて個別に無効化します。
  • CentralizedLoggingの無効化は破壊的:v4.0でCentralizedLoggingを無効化すると、ログアーカイブアカウントのConfig Recorder・Delivery Channel・CloudTrail関連スタックが削除されます(v3.3以前は設定を保持していた挙動からの変更)。安易に無効化しないでください。
  • 権限の事前確認:更新実行ユーザーにorganizations:ListDelegatedAdministratorsなど必要な権限が揃っているか、厳格なSCPがサービスリンクロール作成を妨げないかを事前に点検します。
  • 更新後の確認:ダッシュボードでOU・アカウントが準拠状態か、新しい専用バケットにログが届いているか、ドリフト用のEventBridgeルールが機能するかを検証します。

Landing Zoneを使うべきケースと、あえて使わない判断

Landing Zoneは万能ではありません。導入判断は「これから統制を組む規模か」「すでに自前の基盤があるか」で分かれます。

採用が適するのは、複数アカウントをこれから増やす前提で、AWSのベストプラクティスに沿ったガバナンスを短期間で立ち上げたい場合です。アカウント払い出しとガードレール適用が自動化されるため、統制設計にかける工数を大きく削れます。

一方で、単一アカウント運用や小規模で、Organizations単体のSCPだけで統制が足りるケースでは過剰です。また、すでにTerraformやCloudFormationで自前のランディングゾーンを高度に運用している組織が、後からControl Towerの型に合わせ直すと、リソースの重複や既存構成との衝突というコストが便益を上回ることがあります。この場合はControl Towerを全面採用せず、既存構成を維持する判断が妥当です。v4.0の選択制によって「Organizations+必要な統合だけを有効化する」という中間解も取りやすくなったため、全部入りか自前かの二択で考えず、必要な統合機能だけを見極めて組み合わせる設計を勧めます。

よくある質問

AWS Landing Zoneとは何ですか?

AWS Control Towerが自動構築する、共通のセキュリティ設定・ログ集約・ガードレールが最初から効いた標準化マルチアカウント環境のことです。管理・ログアーカイブ・監査の各アカウントとOU、コントロール、集中ログ基盤の一式を指し、単体のサービス名ではありません。

Landing Zoneの最新バージョンは何ですか?

2026年7月時点の最新はv4.0です。後継の4.1以降は公開されていません。v4.0はサービス統合の選択制やSecurity OUの自動作成廃止などを導入した大型アップデートです。

Control TowerとLanding Zoneは何が違いますか?

AWS Control Towerはガバナンスを自動化するサービスの名前で、Landing ZoneはそのControl Towerが実際にデプロイする環境そのものを指します。Control Towerを有効化した結果として構築されるアカウント・OU・コントロール・ログ基盤の一式がLanding Zoneです。

v4.0でドリフト通知はどう変わりましたか?

AWSControlTowerBaselineを適用していない環境では、通知先が監査アカウントのSNSトピックから管理アカウントのEventBridgeに移行しました。SNS通知は停止するため、aws.controltowerのドリフトイベントに一致するEventBridgeルールを作成して通知先を設定する必要があります。

v4.0アップデートで既存のCloudTrailログは消えますか?

通常のアップグレードでCloudTrailログが消えることはなく、既存のログアーカイブ用バケットが引き続き利用されます。ただしCentralizedLoggingを無効化した場合は、v4.0ではConfig RecorderやCloudTrail関連スタックなどの関連リソースがログアーカイブアカウントから削除されるため注意が必要です。

関連記事

資料請求

RELATED POSTS 関連記事