AWS Landing Zone: How to Build a Cloud Foundation That Scales

Most AWS estates start the same way: one account, a few developers, a proof of concept that works. Two years later, that single account runs production, test and a dozen side projects. Nobody knows which resource belongs to whom, and every security review starts with the same sentence: "it's complicated."

A landing zone prevents that. It is the foundation you build before workloads arrive: accounts, guardrails, identity, network and logging, set up once and applied everywhere. This guide explains how to build one that still holds when you reach a hundred accounts.

What an AWS landing zone is

A landing zone is a pre-configured, multi-account AWS environment that follows your security and compliance rules from day one. New teams get an account that is already connected to the network, already logged and already governed. They do not start from a blank page.

It rests on one principle: the AWS account is your strongest isolation boundary. Separate accounts separate permissions, billing, quotas and blast radius. A mistake in a test account cannot delete production.

Control Tower or a custom build?

You have three realistic options:

• AWS Control Tower. AWS's managed service sets up a landing zone with AWS Organizations, a Security organizational unit (OU) holding a Log Archive and an Audit account, centralized logging and a library of controls. It is the fastest path and the one we recommend for most organizations.
• Control Tower plus extensions. Account Factory for Terraform (AFT) lets you create and customize accounts as code. The Landing Zone Accelerator on AWS adds a broader set of security and network baselines, useful in regulated sectors.
• A fully custom build. Organizations, policies and baselines written entirely in Terraform. It gives full control, but you also own every upgrade. Choose it only if you have a platform team to run it.

Whatever you choose, manage it as code. A landing zone configured by hand in the console drifts within months.

Account and OU structure

Organize OUs by policy needs, not by org chart. Teams change; security requirements change much less often. A structure that works for most mid-size and large companies:

• Security: Log Archive and Audit accounts, plus your security tooling. Very few people have access.
• Infrastructure: shared services such as networking, DNS and CI/CD.
• Workloads: application accounts, split into nested Production and Non-Production OUs.
• Sandbox: experimentation, with budgets and strict limits, disconnected from production networks.
• Suspended: accounts being closed, with all access denied.

Plan for one account per application and environment. It feels like a lot of accounts. It is far easier to manage than shared accounts with tangled permissions.

Guardrails: preventive and detective

Guardrails are the rules every account inherits. There are two kinds:

• Preventive controls block actions before they happen. Service control policies (SCPs) limit what identities in an account can do. Resource control policies (RCPs), added by AWS in late 2024, limit what can be done to your resources, including by external identities.
• Detective controls flag non-compliant configurations after the fact, through AWS Config rules and Security Hub.

One detail matters: preventive controls are inherited by child OUs, detective controls are not. Apply preventive controls as high in the tree as possible, and enable detective controls on every OU you want to monitor.

Typical preventive guardrails we start with: deny use of regions you do not operate in, deny disabling CloudTrail or GuardDuty, deny leaving the organization and deny public S3 buckets in production.

Identity: one entry point

Do not create IAM users in each account. Connect AWS IAM Identity Center to your corporate identity provider, Microsoft Entra ID or Okta for example, and assign access through groups and permission sets.

The result: one place to grant access, one place to remove it when someone leaves, and multi-factor authentication enforced by your existing identity policies. Keep the management account for organization tasks only. Nobody should run workloads there.

Network: design it once

Network decisions are the hardest to change later. Settle three things early:

• IP address plan. Reserve non-overlapping ranges for every account and region, including your on-premises networks. Overlapping ranges are the most common blocker we see when connecting new accounts.
• Hub-and-spoke connectivity. A Transit Gateway in a network account connects workload VPCs to each other and to on-premises sites.
• Centralized inspection. Route internet egress and east-west traffic through one inspection point instead of opening internet access in every VPC.

Logging and security monitoring

Every account should send its activity to places its own administrators cannot touch:

• An organization-wide CloudTrail trail, stored in the Log Archive account.
• AWS Config recording in every account and region you use.
• GuardDuty and Security Hub enabled organization-wide, delegated to the Audit account.
• Findings forwarded to your SIEM, so your SOC sees AWS alongside the rest of your estate.

For organizations under NIS2 or DORA, this is also your evidence: you can show who did what, when, in which account.

Common mistakes we see in the field

• Running workloads in the management account. SCPs do not apply to it, so it escapes your guardrails.
• Building the landing zone after the workloads. Migrating running applications into a new account structure costs far more than starting right.
• Click-ops configuration. Console changes drift and cannot be reviewed. Keep everything in code and in version control.
• Overlapping IP ranges. They block connectivity and force painful renumbering.
• No owner. A landing zone is a product, not a project. Someone must maintain it, update controls and onboard new teams.

Next step

A good landing zone is invisible: teams get secure, connected accounts in minutes, and security gets one consistent view of the whole estate. A weak one shows up in every audit.

Planning a landing zone, or cleaning up an AWS organization that grew too fast? Talk to our cloud engineers, or see how we design, build and run cloud and infrastructure. If you manage it with Terraform, read our guide to Terraform at scale.