Set Up an AWS Landing Zone with Control Tower

A Control Tower landing zone is the account structure AWS itself recommends you have before workloads exist: a dedicated account for aggregated CloudTrail/Config logs, a dedicated account for security tooling, a directory for federated sign-in, and a set of guardrails applied to every account that joins later. If you want the conceptual version of this — why landing zones exist and how AWS's approach compares to Azure and GCP — read What Is a Cloud Landing Zone? first. This tutorial is the AWS-specific, hands-on setup.

AWS's own estimate for this flow is about half an hour end to end. Budget closer to 40 minutes the first time, since account creation and guardrail application run in the background and you'll want to actually verify each step rather than click through.

Step 1: Decide your home Region and gather two email addresses

Control Tower's home Region is where its underlying resources (the shared accounts, the dashboard, CloudTrail aggregation) live. You can govern accounts and enable guardrails in other Regions afterward, but the home Region itself is not casually changeable — AWS requires decommissioning the landing zone and involving AWS Support to move it. Pick deliberately; don't default to us-east-1 out of habit if your workloads and compliance requirements point elsewhere.

You also need two email addresses that have never been used to sign up for any AWS account, one each for:

• Log Archive — the account that receives aggregated AWS CloudTrail and AWS Config logs from every account in the landing zone (on landing zone version 4.0+, Control Tower's console labels this account's role "CloudTrail Administrator")
• Audit — the account used for cross-account security/audit tooling access (on landing zone version 4.0+, labeled "Config aggregator")

A shared mailbox with a + alias (e.g. [email protected]) works fine and is the common pattern — you don't need two entirely separate inboxes, just two addresses AWS has never seen.

Step 2: Launch Control Tower from the console

1. Sign in to the account you want as your management account and open the AWS Control Tower console.
2. Confirm the Region selector in the top-right matches the home Region you decided on in Step 1 — this choice is what you're locking in.
3. Choose Set up your landing zone.

Step 3: Configure and launch

Work through the configuration screens:

• Log Archive and Audit account emails — enter the two addresses from Step 1.
• Additional Regions to govern — beyond the home Region, pick which Regions Control Tower should apply guardrails to. You can add more later, so don't feel pressure to enumerate every Region you might ever use.
• Organizational Unit structure — on landing zone version 3.3 and earlier, Control Tower creates a Security OU (holding the Log Archive and Audit accounts) automatically, and an optional Sandbox OU if you enable it. On landing zone version 4.0 and later, AWS no longer requires the Security OU specifically and lets you define your own top-level structure — if your console shows this option, decide your OU layout deliberately rather than accepting whatever's pre-filled, since restructuring OUs later is more disruptive than getting it right now.
• IAM Identity Center — Control Tower's default configuration creates an IAM Identity Center directory with preconfigured permission sets and groups for federated sign-in. This replaced the older "AWS SSO" branding; if you're reading documentation or blog posts that mention AWS SSO, they're describing the same service under its previous name. Unless you already run an external identity provider you specifically want to keep using instead, accept the default — self-managing identity from day one is extra setup for a benefit you probably don't need yet.

Review the summary screen — it lists every resource Control Tower is about to create — then choose Set up landing zone.

Step 4: Wait for setup to complete

This step runs entirely in the background and, per AWS's own documentation, typically takes about thirty minutes. Control Tower is:

• Creating the Log Archive and Audit accounts under your Security OU (or your custom OU structure)
• Deploying CloudFormation StackSets that apply mandatory guardrails across every governed Region
• Setting up the IAM Identity Center directory, default groups, and permission sets
• Configuring AWS Config and AWS CloudTrail aggregation into the Log Archive account

Do not modify or delete any resource Control Tower creates during this step, even ones that look redundant — Control Tower manages these directly, and manual changes can push the landing zone into an inconsistent state that's harder to fix than the change was worth.

Step 5: Verify the landing zone

Once setup reports complete:

Control Tower console → Landing zone → Overview

Confirm:

• Organizational units shows your Security OU (or custom structure) and Sandbox OU if enabled, each with the expected accounts nested underneath.
• Accounts shows the Log Archive and Audit accounts with status Active.
• Controls (formerly labeled "Guardrails" in older Control Tower versions) shows the mandatory controls enforced, with no accounts flagged non-compliant.
• In IAM Identity Center, confirm the default permission sets (e.g. AWSAdministratorAccess) exist and you can assign a test user to them.

If any account shows a non-Active or Drifted status, resolve it before vending real workload accounts on top of the landing zone — a drifted foundation means every account built on it inherits the same drift.

Step 6: Enable additional guardrails (optional but recommended)

Control Tower ships more optional controls than are enabled by default — things like requiring MFA for root user activity, restricting specific EC2 instance types, or enforcing tagging standards. From Controls → Add controls, review the strongly recommended and elective controls and enable the ones matching your actual compliance requirements. Don't enable every optional control reflexively; each one is a real constraint your teams work under, and a control nobody can explain the purpose of just becomes friction.

What you built

You now have a governed multi-account foundation: a Log Archive account collecting logs from everything that joins later, an Audit account for security tooling, federated access through IAM Identity Center instead of per-account IAM users, and guardrails that apply automatically to any account you add. This is the base every subsequent workload account inherits — you haven't vended a single workload account yet, and that's the point: the governance exists before the first one shows up.

For actually creating workload accounts going forward, Control Tower's built-in Account Factory handles one-at-a-time creation through the console — fine at low volume. Once you're vending accounts often enough that console clicking becomes the bottleneck, our AWS Account Factory for Terraform (AFT) guide covers turning that into a pull-request-driven pipeline. And if your requirements go beyond what Control Tower's console configuration supports — deeper network topology, more extensive compliance controls across 35+ services — AWS explicitly recommends layering Landing Zone Accelerator on AWS (LZA) on top of this exact Control Tower foundation rather than replacing it; LZA is an open-source, CDK-based solution for that next tier of customization, not a competing landing zone.

Frequently Asked Questions

Do I need a Sandbox OU?

Only if you want a low-stakes area for experimentation that's still inside your governed landing zone. Teams that already have a separate, fully isolated non-production AWS Organization for this purpose can skip it; teams without one benefit from having somewhere to test changes that isn't a real workload account.

Can I change my home Region later?

Technically yes, but AWS is explicit that it requires decommissioning your landing zone and working with AWS Support — this is not a config toggle. Treat the home Region choice as effectively permanent and decide it before you click "Set up your landing zone," not after.

What happens to accounts I already have outside Control Tower?

You can enroll existing AWS accounts into your landing zone rather than only creating new ones through Account Factory. Enrollment brings the account under Control Tower's guardrails and OU structure, but plan for it deliberately — an account with existing resources and IAM configuration can surface compliance violations against controls you just enabled, which is useful information but not always immediate.

Is AWS Landing Zone (the older solution) still relevant?

If you're setting up fresh today, no — Control Tower is the current foundation AWS builds on, and its own documentation for what used to be a standalone "AWS Landing Zone" product now routes to Control Tower customization guidance instead. If you inherit an environment built on the older solution, treat migrating it to Control Tower as its own project rather than assuming they're interchangeable.

Official References

• Get started with AWS Control Tower from the console — the exact current setup flow
• How AWS Control Tower works — landing zone structure, OU behavior across versions, IAM Identity Center integration
• Landing Zone Accelerator on AWS — Solution overview — its relationship to Control Tower
• Customize your AWS Control Tower landing zone — Customizations for AWS Control Tower (CfCT), a CloudFormation-based alternative to LZA for narrower customization needs