AWS Control Tower Landing Zoneとは？4.0の構成要素と3.3からの更新手順・ドリフト通知

AWS Control TowerのLanding Zone（ランディングゾーン）は、AWS Organizations上に「最初から統制が効いたマルチアカウント環境」を組み上げたものです。AWSの機能ページは、セキュリティとコンプライアンスのベストプラクティスに基づく、適切に設計されたマルチアカウント環境と定義しています。最新のランディングゾーンは4.0（2025年11月17日公開、2026年10月31日時点で後続版なし）で、ログの置き場所・組織構造の要件・ドリフト通知の経路が3.3以前から変わりました。

本記事は、Landing Zoneが何を作るのかを4.0の呼び名で整理し、3.3から4.0へ更新するときに壊れやすい箇所と確認コマンドをまとめます。Control Tower全体の定義・料金・導入判断はAWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断で扱っています。

まとめ

• Landing Zoneは、Control TowerがOrganizations上に展開するアカウント・OU・コントロール・集中ログの一式。1つの組織に作れるのは1つだけ。
• 4.0では、AWS Config・CloudTrail・Security Roles・AWS Backupの統合を個別に有効化・無効化できる。ただしConfigを外すとSecurity Roles・IAM Identity Center・Backupも外す必要がある。
• 4.0のログアーカイブ（CloudTrail administrator）アカウントのバケットはCloudTrail専用になり、AWS ConfigのログはConfig aggregator（旧監査）アカウントの aws-controltower-config-logs- バケットへ移る。
• 3.3から更新した後は、OUの再登録かConfigBaselineの有効化を済ませるまで、Configのスナップショットと設定履歴がS3へ配信されない。
• 4.0以降、ドリフト通知はSNSに届かない。管理アカウントのEventBridgeで aws.controltower の Drift Detected を拾うルールを作る。

AWS Landing Zoneの定義とControl Tower・Organizationsとの関係

Landing Zoneは単体のサービス名ではありません。一般にはAWSのマルチアカウント基盤を指し、Control Towerによる構築と独自構築の両方があります。本記事ではControl Towerが展開・管理する環境を扱います。役割で切ると、AWS Organizationsが複数アカウントを束ねる構造を提供し、AWS Control Towerがその上でコントロールの適用やアカウントの払い出しを自動化し、Control Towerが実際に展開した環境そのものがLanding Zoneです。Organizations側の仕組み（SCP・RCP・一括請求）はAWS Organizationsの解説記事、コントロール・ドリフト・OUといった用語はAWS Control Towerの基本用語の解説で整理しています。

Control Tower自体に追加料金はかからず、Landing Zoneが使うAWS Config・CloudTrail・S3などの利用量に応じて課金されます（AWS Control Towerの料金ページ）。月額の目安は前掲のControl Tower記事で試算しています。

「AWS Landing Zone」と呼ばれる4つのものの違い

「aws landing zone」で検索すると、Control Towerのランディングゾーン以外のものが混ざります。名前が近い4つを、2026年10月31日時点の状態で並べます。

旧ソリューションの製品ページ（aws.amazon.com/solutions/implementations/aws-landing-zone/）は、現在Control Towerのランディングゾーンをカスタマイズする方法（CfCT）のページへ転送されます。新規に旧ソリューションを選ぶ理由はありません。旧ソリューションを運用中の組織でControl Towerを有効化する場合、Control Towerは既存のランディングゾーンとの干渉を事前チェックできないため、計画のページはAWSのソリューションアーキテクトへの事前相談を求めています。LZAについては、AWSがソリューションページで「Control Towerを基盤のランディングゾーンとして展開し、LZAで機能を足す」構成を推奨しています。ただし併用は必須ではなく、LZAのアーキテクチャ概要はControl Towerを使わずAWS Organizationsを基盤に導入する方法も案内しています。

Landing Zoneが作る構成要素（4.0の呼び名で整理）

4.0では共有アカウントの呼び名が変わりました。公式の共有アカウントの説明は、管理アカウント・Config aggregatorアカウント（旧称：監査アカウント）・CloudTrail administratorアカウント（旧称：ログアーカイブアカウント）の3つを挙げ、後の2つを「サービス統合アカウント」と呼びます。ページによって旧称のままの箇所もあるため、同じアカウントを指していると読み替えてください。

管理アカウントとサービス統合アカウントに置かれるもの

3.3以前は、ログアーカイブアカウントの1つのバケットにCloudTrailとAWS Configの両方のログが入っていました。4.0のspecial-accountsページは「このバケットはCloudTrailのログだけを保存し、AWS ConfigはConfig aggregatorアカウントの専用バケットに保存する」と明記しています。Athenaや外部のSIEMでConfigのログを読んでいる場合、参照先のアカウントごと変わる点に注意してください。

OUとコントロール3種、OUに付けるベースライン

アカウントはOUにまとめられ、コントロール（旧称ガードレール）はOU単位で効きます。SCP・RCP・宣言型ポリシーで操作や設定を制限する予防的、AWS Configルールで逸脱を見つける検出的、CloudFormationフックで作成前に止めるプロアクティブの3種類です。2025年6月以降、新たに展開するConfigベースの検出的コントロールはサービスリンクルールになります。ランディングゾーンが3.2以上なら、既存ルールの移行には対象コントロールのリセットまたはOU再登録が必要で（3.1以下の既存ルールは移行されません）、既存の修復設定などのカスタマイズは移行時に削除されます。

OUを統制下に入れる単位が「ベースライン」です。ベースラインの種類によると、OUに付けられるのは次の3つです。

• AWSControlTowerBaseline：OU登録で有効になる標準の一式。ランディングゾーンのリージョン拒否設定も引き継ぐ。
• ConfigBaseline：4.0で追加。検出的コントロールに必要なConfig関連リソースだけを入れる。リージョン拒否は引き継がない。AWSControlTowerBaselineと同じOUには付けられない。
• BackupBaseline：AWS Backup連携用。対象OUでAWSControlTowerBaselineが有効であることが前提。

集中型ロギングとIAM Identity Center

Landing Zoneの「集中型ロギング」は、組織全体のAPI操作をCloudTrailの組織証跡で、リソース設定の変更履歴をAWS Configで記録し、それぞれ専用のS3バケットへ集める構成です。3.3以降、このバケットへの書き込みには aws:SourceOrgID 条件が付き、組織外のアカウントの証跡は書き込めません。保持期間はマニフェストの retentionDays（最小1日）で、ログ用とアクセスログ用のバケットを別々に指定します。証跡の設計はCloudTrailの解説記事、Configのルール評価と料金はAWS Configの解説記事で扱っています。

サインインはIAM Identity Centerで一元化できます。4.0でControl Towerが権限セットを用意するのはログ用アカウントとSecurity Rolesのアカウントだけで、ConfigアカウントとBackupアカウントの権限セットは自分で作る必要があります（4.0の主な変更点）。

Landing Zone 4.0で変わった点

4.0は3.3から約2年ぶりのバージョン更新で、それまで必須だったConfigとSecurity Rolesの統合も無効化できるようになりました。影響の大きい順に整理します。

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

AWS Config・CloudTrail・Security Roles・AWS Backupの統合を個別に有効化・無効化できるようになりました。3.3以前はConfigとSecurity Rolesが暗黙的に常時有効で、4.0のマニフェストで初めて必須の enabled フラグとして表に出ています。統合を無効化すると、その統合のために作られたリソースが管理対象アカウントとサービス統合アカウントから削除されます。ベースラインの間には依存関係があり、外す順番が決まっています。

Configを外したいなら、Identity Center、Backupの2種、Security Rolesの順に外してからConfigを外します。設定変更の計画にこの順序を入れておかないと、途中で操作が失敗します。

Config統合を外すと使えなくなる機能

Configを外した最小構成（コントロールだけを使う構成）は、既存の組織にリージョン制限などの予防的コントロールだけを足したいときに向きます。ただし失う機能が多く、Config統合の有無による機能比較では次のとおりです。

AFTでアカウントを払い出している組織は、Configを外せません。Configの課金を減らしたい理由だけで統合を外すと、払い出しのパイプラインごと止まります。Configの請求が膨らむ条件と抑え方はControl Towerの料金を試算した記事で扱っています。

Security OUの自動作成廃止と「同じ親OU」の要件

3.3以前はセットアップ時に「Security」OUが自動で作られ、監査とログアーカイブのアカウントがそこに固定されていました。4.0ではSecurity OUを作らず、既存のOU構成をそのまま使えます。残る要件は1つで、各サービス統合のアカウントをルート直下の同じOUに置くことです。そのOUが「designated Security OU」として扱われ、AWSControlTowerBaselineとConfigのベースラインの状態は「Not Applicable」と表示されます（正常な表示です）。

このOUへ一般のメンバーアカウントを移すと、自動登録のオン・オフに関係なく、OUで有効なコントロールがドリフトになります。また、このOUにいてもサービス統合アカウントとして指定されていないアカウントにはベースラインのリソースが入らないため、統制したいなら管理対象のOUへ移します。

ログの専用バケット化とサービスリンクのConfigアグリゲーター

3.3から更新した場合、既存のデータとバケットは移動しません。AWS Configの変更点のページによると、動きは次のとおりです。

• CloudTrailは、既存の aws-controltower-logs で始まるバケットに書き続ける。
• Configの新しいデータは、Config統合のアカウントに作られる aws-controltower-config で始まる新しいバケットに入る。
• 4.0でCloudTrail統合を新たに有効化すると、そのたびに aws-controltower-cloudtrail で始まる新しいバケットが作られる。
• 管理アカウントの組織アグリゲーターと監査アカウントのアカウントアグリゲーターは削除され、監査アカウントに置かれるサービスリンクのConfigアグリゲーターに置き換わる。監査アカウントはAWS Configの委任管理者になる。

ログを1つのバケットにまとめたい場合は、S3のバケット間レプリケーションで寄せます。Control Tower以外で作ったConfigの配信チャネルがあるアカウントは、配信先のバケット名を aws-controltower-config-logs- の新バケットへ書き換えておきます。

「統制下」の定義とサービスリンクロールの扱い

4.0では、アカウントやOUにControl Towerのリソース（コントロールやベースライン）が1つでも有効なら「統制下」とみなされます。3.3以前のように AWSControlTowerBaseline の有無で決まるわけではありません。また、サービスリンクロールはOUの登録を解除しても削除されず、ランディングゾーンを廃止した後に手動で消す必要があります。

3.3から4.0へ更新する手順と更新後にやること

公式の更新のベストプラクティスは最新版への更新を勧めており、更新が変更するのは共有アカウントと基盤OUだけで、ワークロードのアカウントやOUには手を入れません。更新はコンソールの「ランディングゾーン設定」から実行でき、公式の手順では30分を少し超える時間がかかります。更新前の確認、実行、更新後の作業の順に並べます。

CLIによる現在のバージョンとドリフト状態の確認

GetLandingZone は、現在の版（version）、更新できる最新版（latestAvailableVersion）、ドリフト状態（DRIFTED または IN_SYNC）を返します。管理アカウントの認証情報を使い、AWS CLIの実行リージョンをControl Towerのホームリージョンに設定してから次を実行します。

LZ_ARN=$(aws controltower list-landing-zones --query 'landingZones[0].arn' --output text)
aws controltower get-landing-zone --landing-zone-identifier "$LZ_ARN" \
  --query 'landingZone.{version:version,latest:latestAvailableVersion,status:status,drift:driftStatus.status}'

version と latest が異なれば更新できます。drift が DRIFTED の場合は種類を確認し、更新・リセットで解消できるものと、ロール復元などの事前対応が必要なものを分けて処理します。

更新前に点検する4項目

• CloudTrailロールのポリシー（APIで更新する場合）：AWSControlTowerCloudTrailRole からインラインポリシーを外し、マネージドポリシー AWSControlTowerCloudTrailRolePolicy をアタッチしておく。
• 統合の無効化は更新と同時にしない：ConfigやSecurity Rolesは、4.0への更新が終わってから個別に外す。
• 実行ユーザーの権限：Config統合を有効にしたまま更新するには organizations:ListDelegatedAdministrators が要る。厳しいSCPがサービスリンクロールの作成を止めていないかも確認する。SCPの書き方はAWS SCPの書き方と適用手順を参照。
• ログの読み手：Configログを読むSIEM・Athena・バックアップの参照先に、Config aggregatorアカウントの新バケットを足す準備をする。

APIで4.0へ更新するときのマニフェスト

4.0のマニフェストでは organizationStructure が削除され、config 節が追加されました。accessManagement・backup・centralizedLogging・config・securityRoles の enabled はすべて必須で、既定値はありません（ランディングゾーンをAPIで起動する手順）。3.3のマニフェストをそのまま渡さず、現在の設定を取り出して書き換えます。

aws controltower get-landing-zone --landing-zone-identifier "$LZ_ARN" \
  --query 'landingZone.manifest' --output json > manifest.json
# organizationStructure を削除し、config 節と各統合の enabled を追記してから実行
aws controltower update-landing-zone --landing-zone-identifier "$LZ_ARN" \
  --landing-zone-version 4.0 --manifest file://manifest.json
aws controltower get-landing-zone-operation --operation-identifier "<返ってきたoperationIdentifier>"

次は構造を示す例です。アカウントIDだけでなく、対象リージョン、保持日数、既存のKMSキー指定、Backupなどの統合設定も取得済みマニフェストと照合し、意図しない変更を避けてください。3.3から更新する場合、Config aggregatorには既存の監査アカウントが入ります。

{
  "governedRegions": ["ap-northeast-1", "ap-northeast-3"],
  "accessManagement": { "enabled": true },
  "backup": { "enabled": false },
  "centralizedLogging": {
    "accountId": "111122225555",
    "enabled": true,
    "configurations": {
      "loggingBucket": { "retentionDays": 365 },
      "accessLoggingBucket": { "retentionDays": 365 }
    }
  },
  "config": {
    "accountId": "111122226666",
    "enabled": true,
    "configurations": {
      "loggingBucket": { "retentionDays": 365 },
      "accessLoggingBucket": { "retentionDays": 365 }
    }
  },
  "securityRoles": { "accountId": "111122226666", "enabled": true }
}

get-landing-zone-operation の status が SUCCEEDED になれば完了です。FAILED の場合は、上の4項目のどれが満たされていないかから確認します。

更新後のOU再登録またはConfigBaselineの有効化

ここを飛ばすと、ログが静かに欠けます。AWS Configの変更点のページは、4.0への更新で旧バケットのポリシーからConfigの配信権限が外れる一方、配信チャネルが新バケットへ向き直るのはOUの再登録が終わってからだと説明しています。それまでの間、設定スナップショットと設定履歴はS3へ配信されず、アグリゲーターにもデータが届きません。

• 1,000アカウント以下のOUは、コンソールのOUページで「OUを再登録」を選ぶ。1,000アカウントを超えるOUは、アカウントごとに更新する。
• Configを使う全OUで、AWSControlTowerBaseline の再登録か ConfigBaseline の有効化を済ませる。終わるとアグリゲーターへのデータは自動で埋め戻される。
• 再登録が遅れてS3に届かなかった期間のデータは、保持期間内であれば config:GetResourceConfigHistory で取り出せる。

4.0でランディングゾーン単位のConfig統合を有効にしても、Configのレコーダーと配信チャネルが入るのはサービス統合アカウントだけです。メンバーアカウントに入れるには、OUごとにConfigのベースラインを有効化します。

CentralizedLogging無効化時のリソース削除

3.3以前は、CentralizedLoggingを無効化しても組織の証跡を止めるだけで、リソースは残っていました。4.0で無効化すると、ログ用アカウントからConfigレコーダー・配信チャネル・CloudTrail関連のスタックインスタンスが削除され、Control Towerはそのアカウントを管理しなくなります。監査証跡を残す必要がある組織は、別管理のCloudTrail証跡と保存先への記録を確認するまで、CentralizedLoggingを無効化しないでください。戻すには再度有効化するか、アカウントを管理対象のOUへ移して統制を広げます。

ドリフト通知をEventBridgeで受ける設定

ドリフトは、Control Towerが適用したOU・SCP・アカウント配置などが、コンソール外の変更で想定からずれた状態です。ガバナンスドリフトの種類のページは、4.0以降のランディングゾーンではSNSトピックへのドリフト通知を止め、管理アカウントのEventBridgeへ送ると明記しています。3.3まで監査アカウントのSNSトピック aws-controltower-AggregateSecurityNotifications でメールやSlackへ流していた場合、更新後はルールを作るまで通知が届きません。

CLIによるEventBridgeルール作成とSNSターゲット設定

公式のサンプルイベントは "source": "aws.controltower"、"detail-type": "Drift Detected" です。管理アカウントに通知先のSNSトピックをあらかじめ用意し、以下のARNを実在するトピックのARNに置き換えます。そのうえで、このイベントに一致するルールとSNSターゲットを設定します。

cat > drift-pattern.json <<'EOF'
{
  "source": ["aws.controltower"],
  "detail-type": ["Drift Detected"]
}
EOF
aws events put-rule --name controltower-drift \
  --event-pattern file://drift-pattern.json
aws events put-targets --rule controltower-drift \
  --targets 'Id=drift-sns,Arn=arn:aws:sns:<region>:<管理アカウントID>:controltower-drift'

SNSトピックのアクセスポリシーで events.amazonaws.com からの sns:Publish を許可しないと、ルールは一致してもメッセージが届きません。トピックポリシーの書き方はEventBridge SNSの連携手順で解説しています。イベントの detail には driftType（例：ACCOUNT_MOVED_BETWEEN_OUS）と remediationStep（解消手順の文）が入るため、Lambdaを挟めば種類ごとに通知先を分けられます。

検出されるドリフトと報告されない範囲

このほか、必須のIAMロールが消える「ロールドリフト」は、解消するまでランディングゾーン自体が使えなくなるため、最優先でロールを戻します。一方、管理アカウントで動くCloudTrail・CloudWatch・IAM Identity Center・CloudFormation・AWS Configの設定変更や、ベースラインに含まれるリソースの変更は、ドリフトとして報告されません。これらはAWS ConfigのルールやCloudTrailのイベントで別途見張ります。

2025年10月に追加された自動登録（APIでは remediationTypes に INHERITANCE_DRIFT を指定）を有効にすると、登録済みOUの間でアカウントを移したとき、移動先OUのベースラインとコントロールが自動で適用され、移動元のものは外れます。多くの場合ドリフトは出ません。ただし、有効化する前に起きた継承ドリフトはさかのぼって解消されません。

Landing Zoneを使う判断とConfig統合を外す判断

判断は「これからアカウントを増やす組織か」と「Configの記録を他で持っているか」の2点で分かれます。

• フル構成（Config統合あり）を選ぶ：アカウントを継続的に払い出し、AFTやCfCTで設定を配る組織。検出的コントロールとAccount Factoryの両方が要るなら、こちら以外の選択肢はありません。
• Config統合なしを選ぶ：既存の組織でConfigとSecurity Hubを自前で運用しており、Control TowerにはリージョンやSCPの予防的コントロールだけを任せたい場合。
• Control Towerを導入しない：単一アカウント、または数アカウントでOrganizationsのSCPだけで統制が足りる場合。TerraformやCloudFormationで自前のランディングゾーンを作り込んでいる組織が後から合わせると、既存のConfigレコーダーやCloudTrail証跡と衝突する作業が便益を上回ることがあります。

既存Organizationsへの登録手順と料金の実額はControl Towerの導入判断の記事にまとめています。OU設計から3.3環境の4.0更新までを外部に任せる場合は、AWSのインフラ構築支援で相談を受け付けています。

よくある質問

AWS Landing Zoneとは何ですか？

一般には、セキュリティとコンプライアンスのベストプラクティスに沿って設計したAWSのマルチアカウント基盤を指し、Control Towerで構築する方法と自前で構築する方法があります。Control Towerで作る場合は、AWS Organizations上に共有アカウント・OU・コントロール・集中ログを備えた環境が展開され、1つの組織に1つだけ作れます。Control Tower以前に提供されていた「AWS Landing Zone」ソリューションとは別物で、旧ソリューションのページは現在Control Towerのカスタマイズの解説へ転送されています。

Control Towerのランディングゾーンの最新バージョンは何ですか？

4.0です。2025年11月17日に公開され、2026年10月31日時点のリリースノートに後続の版はありません。手元の版は aws controltower get-landing-zone の version と latestAvailableVersion で確認できます。

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

Control Towerはマルチアカウントの統制を自動化するサービスで、Landing ZoneはControl Towerが作った環境そのものです。Organizationsが構造を、Control Towerが統制の仕組みを提供し、その結果としてできるのがLanding Zoneです。

4.0へ更新すると既存のCloudTrailログは消えますか？

消えません。CloudTrailは既存の aws-controltower-logs で始まるバケットに書き続けます。AWS Configの新しいデータだけが、Config aggregator（旧監査）アカウントの新しいバケットへ入ります。ただし更新後にOUを再登録するまで、Configのスナップショットと設定履歴はS3へ配信されません。

4.0でドリフト通知が届かなくなったのはなぜですか？

4.0以降、Control TowerはSNSトピックへのドリフト通知を止め、管理アカウントのEventBridgeへイベントを送るようになったためです。source が aws.controltower、detail-type が Drift Detected に一致するルールを作り、SNSやLambdaへ流してください。

関連記事

• AWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断をCLI例つきで解説
• AWS Control Towerの基本用語｜コントロール・ドリフト・OUの意味を整理
• AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説
• AWS Configとは？設定変更の記録・ルール評価・料金の実額と導入判断をCLI設定例つきで解説【2026年時点】
• CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説