Skip to content

AWS Updated 2026-07-04

AWS landing zone setup: the clean multi-account foundation before growth gets messy

An AWS landing zone setup gives you the account structure, logging, identity, and guardrails that every workload after it inherits. Here is what a landing zone actually contains and how to stand one up with Control Tower.

A landing zone is the part of an AWS environment you build before the workloads: the account structure, centralized logging, identity, and guardrails that everything deployed afterwards inherits automatically. Set it up early and every new project lands in a governed account with CloudTrail, SSO, and budget alarms already in place. Skip it, and eighteen months later you are retrofitting governance onto accounts that grew wild — which costs far more than the two or three days the landing zone would have taken. AWS Control Tower is the managed way to stand one up; the decision is mostly about timing and how much customization you need.

What’s happening

A landing zone is not a product, it is a bundle of decisions made once and enforced automatically. Concretely: an AWS Organization with a deliberately empty management account; a Log Archive account where CloudTrail and AWS Config history from every account accumulate, immutable and out of reach of workload credentials; an Audit account for security tooling with cross-account read access; an OU structure that separates production from sandbox; SCP guardrails that set hard permission ceilings; IAM Identity Center so humans get short-lived SSO sessions instead of long-lived IAM users; and a repeatable way to create new accounts that come out governed by default.

Control Tower assembles all of this for you. It creates the Security OU with the Log Archive and Audit accounts, enables an organization trail, applies a starting set of controls — preventive ones implemented as SCPs, detective ones as AWS Config rules, proactive ones that check CloudFormation resources before provisioning — and gives you Account Factory for vending new accounts. What Control Tower is not: a migration tool (existing accounts must be enrolled deliberately), a security product (it enforces structure, not workload security), or optional infrastructure you can turn off casually once adopted.

What to check first

  • Whether an Organization already exists and what state it is in. Control Tower can set up in an existing Organization, but conflicting SCPs and existing Config recorders in member accounts are the classic sources of setup friction.
  • Your home region. Control Tower is set up in one home region and governs a region list you choose; pick where your workloads actually run — for Canadian data-residency requirements that usually means ca-central-1 — because changing it later is painful.
  • Email addresses for the new shared accounts. Log Archive and Audit each need a unique root email; have role-based addresses ready rather than inventing them mid-wizard.
  • Existing IAM Identity Center configuration. Control Tower integrates with it; an instance already configured in a different region is a common blocker.
  • Who currently has admin everywhere. The landing zone will change how humans access accounts; know whose workflow you are about to alter.

How to verify

If you are inheriting an environment and unsure whether a landing zone exists or has drifted:

# Is there an Organization, and which accounts are in it?
aws organizations describe-organization
aws organizations list-accounts \
  --query 'Accounts[].[Id,Name,Email,Status]' --output table

# What controls does Control Tower actually enforce on an OU?
aws controltower list-enabled-controls \
  --target-identifier arn:aws:organizations::111122223333:ou/o-exampleorgid/ou-exampleouid

# Is the organization trail alive and logging?
aws cloudtrail describe-trails --query 'trailList[].[Name,IsOrganizationTrail,HomeRegion]'
aws cloudtrail get-trail-status --name aws-controltower-BaselineCloudTrail

In the console, Control Tower > Landing zone settings shows the landing zone version and whether it needs an update, and the dashboard flags drift — accounts or policies changed outside Control Tower’s knowledge. Drift is not cosmetic; unresolved drift blocks landing zone updates.

The runbook

  1. Decide the OU skeleton before the wizard. Control Tower creates a Security OU; you add the rest. Workloads/Prod, Workloads/NonProd, and Sandbox is a proven start. OUs exist to hold policies — create them for policy differences, not for departments.
  2. Run Control Tower setup from the management account. Choose home region, governed regions (enable the region deny control if residency matters), and provide the Log Archive and Audit account emails. Setup takes under an hour of wall-clock time.
  3. Enroll existing accounts one at a time. Enrollment applies baselines and requires the AWSControlTowerExecution role in the target account. Test on the least critical account first: pre-existing Config recorders are the usual enrollment failure and must be removed or reconciled first.
  4. Layer your own SCPs on top of the managed controls. Control Tower’s mandatory controls protect its own plumbing; your policy needs — deny CloudTrail tampering, region restrictions, blocking services you never use — go in additional SCPs, kept in version control. A working set is in the Organizations SCP baseline.
  5. Wire identity. Define permission sets in IAM Identity Center (admin, power-user, read-only), map groups from your identity provider, and start retiring per-account IAM users for humans.
  6. Standardize account vending. New accounts come from Account Factory with baselines applied at birth — the checklist that makes each vended account production-ready is in Control Tower Account Factory.
  7. Schedule landing zone updates. Control Tower versions advance; staying multiple versions behind makes each update riskier. Put a quarterly check on the calendar — this is the recurring ownership work that separates a maintained landing zone from an abandoned one.

When this is the wrong move

A solo founder with one account and one workload does not need Control Tower this quarter — a well-kept single account with CloudTrail, MFA, and budgets is defensible until the second team or the first compliance requirement arrives. At the other end, organizations with heavy customization needs (custom networking baked into every account, unusual region topologies) sometimes outgrow Account Factory’s defaults and pair Control Tower with infrastructure-as-code customizations, or run a Terraform-built landing zone instead — more control, and materially more engineering to maintain. And if your accounts are already deep in an un-governed sprawl, consolidation under Organizations comes first; a landing zone assumes the accounts answer to one management account.

Common mistakes

  • Workloads in the management account. SCPs do not apply there, and Control Tower assumes it stays clean. This mistake is expensive to reverse.
  • Choosing a home region casually. The home region hosts the landing zone’s own resources; treating it as an afterthought creates residency and latency questions later.
  • Ignoring drift warnings. Manual changes to managed SCPs or shared accounts put the landing zone in drift, and drift compounds until updates fail.
  • Treating setup as the finish line. A landing zone that never gets its versions updated, controls reviewed, or vended accounts audited is decaying from day one.

Keeping it under control

  • Review the Control Tower dashboard for drift and non-compliant resources monthly.
  • Keep custom SCPs and permission sets in version control with a review step.
  • Update the landing zone within a quarter of a new version, in a maintenance window.
  • Audit the account list quarterly: every account has an owner, a purpose, and lives in the right OU.
  • Re-check the governed-region list yearly against where your data is actually allowed to live.

The landing zone is a two-day build that pays back for years, but only if someone owns its upkeep. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.