Landing Zone

A Landing Zone is a well-architected, multi-account AWS environment that serves as the starting point for deploying workloads. It establishes the foundational security, networking, and governance controls.

Core Components

• Account Structure: OUs for Security, Infrastructure, Workloads, Sandbox
• Identity: centralized access via IAM Identity Center, federated from a corporate IdP
• Networking: hub-and-spoke VPC architecture with Transit Gateway, shared services
• Logging: centralized CloudTrail, Config, VPC Flow Logs in a dedicated Log Archive account
• Security: GuardDuty, Security Hub, IAM Access Analyzer enabled in all accounts
• Guardrails: SCPs, Config Rules, and preventive controls

Implementation Options

• AWS Control Tower: managed landing zone setup with Account Factory
• Custom: Terraform or CDK-based landing zone for more control
• AWS Landing Zone Solution: legacy AWS-provided solution (superseded by Control Tower)

What Control Tower Actually Creates

If you use Control Tower, the landing zone is not an abstract idea, it is a specific set of resources created in your management account. Control Tower creates two OUs under the organization root: a Security OU and, optionally, a Sandbox OU. Inside the Security OU it creates or adopts two shared accounts, Log Archive and Audit. You can choose custom names for these shared accounts at launch, but you cannot rename them afterwards, and you cannot bring existing accounts in for the security and logging roles after the initial launch. It also creates a cloud-native IAM Identity Center directory with preconfigured groups and single sign-on access, unless you choose to self-manage identity.

It then applies all mandatory preventive controls (implemented as SCPs) and all mandatory detective controls (implemented as Config rules). Controls are applied to the organization as a whole, with one important exception: preventive controls are not applied to the management account. Under the hood, Control Tower uses CloudFormation StackSets, deploying one stack instance per account and Region, which is why stack instances sometimes show an Outdated status after partial updates. That status is expected and the stack remains usable.

One structural constraint worth knowing up front: an account can have at most one landing zone. There is no multi-landing-zone model to fall back on if you outgrow the first design, so the initial OU layout and shared account naming deserve real thought.

How It Goes Wrong in Practice

The most common landing zone failure is drift caused by editing Control Tower's resources by hand. Someone needs a quick exception, so they modify a Control Tower managed SCP, delete a stack instance, or change a resource in the Log Archive account. AWS is explicit that modifying or deleting Control Tower managed resources outside the supported methods puts the landing zone into an unknown state. What follows is a landing zone that reports drift, refuses to enroll new accounts cleanly, and needs a repair cycle at exactly the moment you wanted to move fast. Exceptions belong in a separate OU with its own controls, not in edits to the managed baseline.

The second pattern is the landing zone that stops at day one. Control Tower gives you a baseline, then a team enrolls twenty accounts over the following year without ever revisiting whether the guardrails still match reality: new Regions get used and are not covered by the region-restriction SCP, new services appear with no detective control, and the Audit account's cross-account role accumulates permissions. A landing zone is a living artifact. Schedule reviews of the control set and the OU placement of accounts.

Third, teams build a custom landing zone in Terraform because Control Tower felt restrictive, and then discover they have signed up to reimplement account vending, control deployment, drift detection, and the baseline for every new AWS service, forever. Custom is a legitimate choice when you have real constraints, but it is an ongoing engineering commitment, not a one-time build.

Checking Your Landing Zone From the CLI

To confirm whether a Control Tower landing zone exists and get its ARN:

aws controltower list-landing-zones

The command takes no required parameters. The output is a landingZones list where each entry has an arn, plus a nextToken for pagination. The documented constraint on that list is a minimum of 0 and a maximum of 1, which is the API confirming the one-landing-zone-per-account rule. Follow up with aws controltower get-landing-zone --landing-zone-identifier <arn> to retrieve the landing zone version and its current status, which is the fastest way to spot a landing zone that needs an update or is showing drift.

Frequently Asked Questions

Is a landing zone the same thing as Control Tower?

No. A landing zone is the architecture: a multi-account environment with baseline identity, logging, networking, and guardrails. Control Tower is one managed way to create and govern one. You can build a landing zone with Terraform or CDK and never touch Control Tower, and the result is still a landing zone.

Can I add Control Tower to an existing AWS Organization?

Yes. Control Tower can be launched on an existing organization and can enroll existing accounts and OUs. The constraint is at initial launch: you choose then whether to bring existing accounts in as the Log Archive and Audit accounts, and that choice cannot be revisited later.

What belongs in the Log Archive account?

Centralized, write-once log storage and nothing else. No workloads, no interactive access beyond what auditors need, and ideally S3 Object Lock or equivalent retention on the log buckets. The value of the account is that it survives a compromise of the accounts that produce the logs, which only holds if nobody has day-to-day credentials in it.