AWS landing zones, explained

A typical landing zone. The management account runs the organization and nothing else. Each group of accounts (an organizational unit, or OU) gets its own rules, and every account's activity is recorded in one place.

What a landing zone is

A landing zone is a pre-built, governed Amazon Web Services (AWS) environment made of many accounts, with identity, security rules, logging, and networking set up before any real work goes in. Every account created inside it starts out compliant, instead of being locked down after the fact.

Think of an office building. Before the first tenant moves in, the owner installs the locks, badge readers, security cameras, fire code, and utilities. A new tenant doesn't wire their own electricity or decide whether cameras record. They sign a lease and move into a unit that is already safe. The landing zone is the building. Each AWS account is a unit.

The term covers the whole foundation, not one AWS service. AWS Control Tower is the most common way to build one, but a landing zone can also be built with the Landing Zone Accelerator or with your own Terraform.

Why one AWS account isn't enough

Small teams often start with a single account holding everything: dev, test, production, and the continuous integration (CI) pipeline. That works until it doesn't. An AWS account is the strongest isolation boundary AWS offers, so splitting work across accounts buys you three things.

A smaller blast radius. A leaked key in Dev can't touch Prod if Prod is a different account. A bad script can only delete what its account holds.
Clear bills. Each account's spend is reported separately, so you can see exactly what each team or environment costs.
Separate limits. Service quotas, like the number of instances you can run, apply per account. A runaway test can't exhaust capacity production needs.

One account is a house where everyone shares every room. Many accounts is an apartment building: each unit has its own door and meter, and a flood in 4B doesn't ruin 2A.

The catch is that twenty accounts are twenty places to misconfigure. The landing zone exists to keep all of them consistent.

The building blocks

Accounts, grouped into organizational units

AWS Organizations lets one management account create and own other accounts, grouped into organizational units (OUs). Rules attach to an OU and apply to every account in it, so you secure a group at once instead of one account at a time.

Most landing zones include a Security OU with a Log Archive account and an Audit account, a Workloads OU for dev, test, and production, and often an Infrastructure OU for shared networking and a Sandbox OU for experiments.

OUs are floors of the building. The research labs on floor 3 follow stricter rules than the break room on floor 1, and every unit on a floor inherits that floor's rules automatically.

One front door for people

IAM Identity Center (formerly AWS SSO, single sign-on) gives each person one login. From there they pick an account and a role, like read-only in Prod or administrator in Dev, defined once as a permission set. There are no long-lived Identity and Access Management (IAM) users with passwords in each account, which removes one of the most common causes of breaches.

Identity Center is the badge at the front desk. One badge, programmed for the floors you're allowed on, instead of a separate key for every door.

Guardrails

Guardrails are the rules no account can opt out of. Control Tower calls them controls, and they come in three kinds, which act at different moments in a resource's life.

Proactive

Before anything is created

CloudFormation Hooks check a template and reject it if, say, a bucket isn't encrypted.

Like an inspector reviewing blueprints.

Preventive

At the moment of the application programming interface (API) call

Service control policies (SCPs) deny actions outright, like turning off CloudTrail or using an unapproved region.

Like a locked door.

Detective

After the resource exists

AWS Config rules continuously check resources and flag anything out of policy, like a security group open to the whole internet.

Like a security camera.

Prevent what you can, detect what you can't. A good landing zone uses all three.

An SCP is a JavaScript Object Notation (JSON) policy attached to an OU. This one stops anyone in the OU, including account administrators, from disabling or deleting the audit trail:

JSON

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectCloudTrail",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "cloudtrail:UpdateTrail"
    ],
    "Resource": "*"
  }]
}

SCPs never grant permissions. They set the ceiling. Even an account's administrator can't go above it.

Central logging

An organization-wide CloudTrail trail records every API call in every account and ships it to the Log Archive account. AWS Config records how resources change over time and sends that there too. Workload teams can't reach into Log Archive, so an attacker who takes over the Dev account can't erase the evidence.

Log Archive is where the camera footage goes: a locked room in another building. Whoever breaks into a unit can't delete the recording of it.

Shared networking

Instead of every account building its own path to the internet and the corporate network, a dedicated Network account runs the shared pieces. The usual pattern is hub-and-spoke: a Transit Gateway in the middle, each account's VPC (virtual private cloud) connected as a spoke, and one central exit to the internet where traffic can be inspected.

Every VPC connects to one hub, and internet traffic leaves through one inspected exit. Adding an account means adding a spoke, not redesigning the network.

The Network account is the building's utility room. Tenants don't run their own power lines to the street; they plug into the building's supply, which is metered and inspected in one place.

Account vending

New accounts come from a template, not a checklist. In Control Tower this is Account Factory: request an account, pick its OU, and it arrives with the logging, guardrails, network connection, and access roles already applied. Account Factory for Terraform (AFT) does the same from a Git repository, so every account request is reviewed as code.

Account vending is the standard lease. Every new tenant signs the same terms and gets the same fixtures. No one negotiates their own fire code.

Ways to build one

Option	Best for	Trade-off
AWS Control Tower	Most organizations starting out. AWS sets up the accounts, controls, and logging for you.	Opinionated. Going beyond its model takes extra tooling.
Account Factory for Terraform	Teams already on Terraform who want account creation as code, with pull requests and review.	Runs on top of Control Tower, so there are more moving parts to maintain.
Landing Zone Accelerator	Regulated and public-sector workloads with heavy compliance requirements.	Heavier to deploy and operate. Driven by configuration files.
Custom Terraform or CloudFormation	Teams with unusual needs and strong platform engineering skills.	You own every piece, including upgrades and drift.

Control Tower itself has no separate charge. You pay for the services it turns on, mainly AWS Config and CloudTrail storage. Config recording in particular grows with the number of resources and accounts, so watch it as you scale.

Three examples

A small startup

Five accounts: management, Log Archive, Audit, Dev, and Prod, all through Control Tower. Engineers sign in through Identity Center with administrator access in Dev and read-only access in Prod. Production deploys come only from the CI pipeline. One SCP restricts all accounts to two regions, so no one accidentally launches servers in a region nobody watches.

A federal workload

Built with the Landing Zone Accelerator, often in AWS GovCloud (US). There are more OUs, split by data sensitivity as well as environment. SCPs are strict: approved regions only, encryption required, and no public Amazon Simple Storage Service (S3) buckets. Every change is logged centrally for the agency's assessors, and the landing zone's configuration maps directly to National Institute of Standards and Technology (NIST) 800-53 controls, so the environment's evidence is ready when it's time to get an authority to operate.

A lean personal setup: mine

My own landing zone runs on Control Tower. I write and test in the Dev account, but my own credentials never make the changes. Instead, Terraform assumes a deploy role in a dedicated automation account, which is where deployments run. The provider block is the whole trick:

HCL

provider "aws" {
  region = "us-east-1"

  assume_role {
    role_arn = "arn:aws:iam::<AUTOMATION_ACCOUNT_ID>:role/<deploy-role>"
  }
}

Write and test

Code is developed and tried out in the Dev account.

Assume the deploy role

Terraform assumes the deploy role in the automation account and gets short-lived credentials.

Deploy from Automation

The deployment runs as that deploy role, not as a person.

Change lands, logged

The change is applied, and CloudTrail records it in Log Archive under the deploy role's identity.

Every deployment runs under short-lived credentials and is traceable to one identity.

My own credentials don't make the changes. Terraform works with short-lived credentials from the deploy role, and every change is traceable in CloudTrail to that one deploy identity. The common multi-account pattern puts a deploy role in each target account, trusted only by the automation account, and that's the next step for my setup; replacing my remaining access keys with IAM Identity Center sign-in is also on my list.

Common mistakes

Running workloads in the management account. SCPs don't apply to the management account, so anything running there sits outside every guardrail. Keep it for billing and governance only.
Locking yourself out with an SCP. A deny policy on the wrong OU can block the roles you use to fix it. Test new SCPs on a sandbox OU first.
Treating Log Archive as optional. Logs kept only in the account that generated them can be deleted by whoever compromises that account.
Long-lived access keys. IAM users with static keys in each account are exactly what Identity Center and role assumption replace.
Ignoring the bill for guardrails. AWS Config charges per recorded change. Budget for it as accounts and resources grow.

Quick reference

Landing zone: A governed, multi-account AWS environment with identity, guardrails, logging, and networking built in from the start.
AWS Organizations: The service that lets a management account create and govern other accounts.
Organizational unit (OU): A group of accounts that share the same rules.
Service control policy (SCP): A deny-style policy on an OU or account that sets the maximum permissions anyone there can have.
AWS Config rule: A continuous check that flags resources that break a policy.
IAM Identity Center: Single sign-on for AWS: one login, with roles in each account defined by permission sets.
AWS Control Tower: AWS's managed service for building and running a landing zone.
Account Factory for Terraform (AFT): Account creation for Control Tower, driven by Terraform and a Git repository.
Landing Zone Accelerator (LZA): AWS's open-source landing zone solution aimed at regulated workloads.
Transit Gateway: A regional network hub that connects many VPCs and on-premises networks.

The short version

A landing zone is the building before the tenants: separate units, one front desk, locked doors, cameras that record somewhere safe, and shared utilities. Build it first, and every account you add later is safe from its first minute instead of secured as an afterthought.

Further reading from AWS: the Control Tower user guide (opens in a new tab), Account Factory for Terraform (opens in a new tab), and the Landing Zone Accelerator (opens in a new tab).