AWS Landing Zone Best Practices for Enterprises

An AWS landing zone is a pre-configured, multi-account environment with governance, identity, networking and logging established before workloads arrive. It is the difference between accounts that are provisioned and accounts that are merely created.

This guide covers when you actually need one, how the three build paths differ, how to structure organisational units so you are not migrating accounts in eighteen months, and how to plan address space before the first VPC exists.

What an AWS Landing Zone Is and When You Need One

A landing zone is not a product you buy. It is a set of foundational decisions, implemented consistently, that every subsequent account inherits.

The components that make it a landing zone rather than a collection of accounts:

• An AWS Organization with a deliberate OU hierarchy
• Centralised identity, usually IAM Identity Center federated to your IdP
• Centralised, immutable logging — CloudTrail and Config aggregated into a dedicated account nobody can write to
• Preventive and detective controls applied at OU level rather than per account
• A network foundation with non-overlapping address space and a connectivity model
• Automated account provisioning so account fifty is identical to account five

The signals that you need one now

When you genuinely do not need one

A single team running one product in two accounts does not need a landing zone. It needs CloudTrail on, MFA enforced, an IaC pipeline and a billing alarm. Building a full multi-account foundation for that workload is an expensive way to add friction.

The honest threshold: build a landing zone when the cost of inconsistency exceeds the cost of the platform. For most organisations that is somewhere between five and fifteen accounts, and it arrives sooner if you are regulated.

One naming decision worth getting right early

"AWS Landing Zone" was also the name of an older AWS solution, now superseded by Control Tower. If you find documentation referencing the ALZ solution and CloudFormation StackSets as the primary mechanism, you are reading something outdated. The current baseline is Control Tower, or a Terraform-native build on AWS Organizations directly.

Control Tower vs Custom vs Terraform-Native Builds

Three viable paths. The choice depends far more on how your team already works than on technical capability.

The comparison

When Control Tower is the right answer

For most enterprises starting from a handful of accounts, it is. It sets up the Organization, creates the Log Archive and Audit accounts, configures aggregated CloudTrail and Config, applies a baseline set of controls, and gives you Account Factory for provisioning.

Control Tower's controls come in three types, and the distinction matters when you plan a rollout:

• Preventive — implemented as service control policies (SCPs) or resource control policies (RCPs). They stop the action.
• Detective — AWS Config rules. They report non-compliance after the fact.
• Proactive — CloudFormation hooks. They block non-compliant resources before deployment.

The service itself carries no charge; you pay for what it turns on — CloudTrail, Config, S3 and KMS. In a large organisation, Config recording is usually the line item that surprises people, and it is worth reviewing alongside broader cloud cost management.

When a Terraform-native build makes sense

Choose this when you have a requirement Control Tower cannot express, or a platform team that already runs Terraform at scale and wants no console-driven state.

Common reasons teams take this path:

• Regions or partitions Control Tower does not support
• An existing organisation with a structure that would need dismantling to enrol
• A requirement that 100% of configuration lives in version control with no exceptions
• Very specific logging or encryption architecture that conflicts with the prescribed layout

The cost is real: you own the baseline forever, including the parts AWS would otherwise update for you. Budget for that as ongoing platform work, not a one-time project. Our Terraform consulting practice covers the module structure and state layout this needs.

The hybrid most enterprises end up with

Control Tower for the landing zone, Account Factory for Terraform (AFT) for account vending, and Terraform for everything inside the accounts.

AFT runs from its own management account and turns account requests into pull requests. A team submits a Terraform file describing the account; a pipeline provisions it through Control Tower, then applies global customisations, per-OU customisations and account-specific customisations in sequence. AFT requires Terraform 1.6.1 or later and works in the regions Control Tower supports, with a few exceptions.

This gives you AWS-maintained guardrails and a fully code-driven account lifecycle, which is usually the right trade.

A note on sequencing: pick the build path before you create any accounts you care about. Enrolling existing accounts into Control Tower is possible but constrained, and restructuring an organisation with live workloads is significantly harder than it sounds.

Organization, OU Design and Automated Account Vending

This is where landing zones are won or lost. The structure is cheap to change on day one and expensive to change on day four hundred.

The governing principle

An OU is a policy boundary, not an org chart. Group accounts by the controls they need, not by which team owns them.

The test: if two accounts would have identical SCPs, they belong in the same OU regardless of who owns them. If two accounts in the same OU need different policies, you have found the boundary and need to split.

Teams that structure OUs by business unit end up attaching SCPs to individual accounts to handle exceptions, which defeats the purpose and quickly becomes unmanageable.

The baseline structure

AWS's multiple-accounts whitepaper sets out a recommended set of OUs. In practice most enterprises need these five to start:

• Security — Log Archive and Audit accounts. Control Tower creates these. Logs are write-once and readable by nobody outside the security function.
• Infrastructure — Network, Shared Services, Backup. Platform-team owned. Never hosts a workload.
• Workloads — contains nested OUs, not accounts directly. Prod and Non-Prod at minimum, because they need different SCPs.
• Sandbox — one account per engineer or small team, budget-capped, disconnected from corporate networks. Sandbox accounts are never promoted to production.
• Suspended — where decommissioned accounts sit with a deny-all SCP while the 90-day closure window runs.

As you grow, AWS's prescriptive guidance on account structure adds useful ones: Policy Staging (test SCP changes before they reach production), Exceptions (accounts that legitimately need different rules, kept deliberately small), Deployments, and Transitional (a holding area for acquired accounts).

Rules worth treating as non-negotiable

• No accounts directly under root. There is nowhere to attach policy, and it becomes the default dumping ground.
• Nothing runs in the management account. It cannot be restricted by SCPs, which makes it the single highest-value target in the organisation. Billing and Organizations only.
• Nest no more than three levels deep. SCP evaluation is cumulative, and deep hierarchies become impossible to reason about during an incident.
• Roll out detective controls before preventive ones. Find out what an SCP would have blocked before it blocks it in production.
• Test SCPs in a Policy Staging OU. An SCP that denies more than intended fails in ways that are hard to diagnose, because the error surfaces as a generic access denial.

Account vending: the part that makes it scale

A landing zone that requires a human to configure each new account has not solved the problem — it has centralised it.

A complete vending process produces an account that already has: the right OU placement, IAM Identity Center permission sets assigned, a VPC with CIDR allocated from your IPAM pool (or deliberately no VPC), default VPC deleted, CloudTrail and Config inherited, budget alerts configured, tags applied, and an entry in whatever inventory your platform team maintains.

Track two numbers to know whether it works:

The second number is the more revealing one. If engineers are creating accounts by hand, the vending process is missing something they need.

Identity, in one paragraph

Federate IAM Identity Center to your existing identity provider and define permission sets centrally. No IAM users in member accounts, no long-lived access keys, break-glass credentials in a sealed envelope with alerting on use. This is usually the fastest security win available in a landing zone build and it is worth doing before workloads land — retrofitting is painful. It pairs directly with broader cloud security controls.

Network Topology and IP Allocation at Scale

Network design is the decision with the worst reversal cost in the entire landing zone. Re-IPing a live production VPC means downtime, and there is no shortcut.

Allocate address space before account one

Decide your overall private address space, then subdivide it deliberately — by region first, then environment, then account.

A workable scheme:

10.0.0.0/8              Organisation total
  10.0.0.0/12           ap-south-1
    10.0.0.0/16         Production
    10.16.0.0/16        Non-production
    10.32.0.0/16        Shared infrastructure
  10.16.0.0/12          us-east-1
    ...

Use AWS VPC IPAM to manage this. Create pools per region and environment, and have your account vending process allocate from IPAM rather than letting anyone pick a range. IPAM prevents the overlap problem structurally rather than by convention, and convention always fails eventually.

Two practical points teams learn late:

• Size VPCs larger than you think. A /16 per production VPC feels wasteful until you add EKS with the VPC CNI, where every pod consumes an IP address. Running out of addresses in a live cluster is a genuinely bad day.
• Reserve space for what you do not run yet. A second region, a VPN range, an acquisition. Leaving gaps costs nothing; filling them later costs a migration.

Connectivity: pick a model and stick to it

For most enterprises the answer is Transit Gateway with a hub in each active region, TGW peering between regions, and centralised egress. Attach the TGW from the Network account in the Infrastructure OU and share it via Resource Access Manager, so workload accounts consume connectivity without owning it.

Centralise egress and inspection

Route outbound traffic through a shared egress VPC with NAT gateways and a firewall, in the Network account. This gives you one place to apply inspection and one set of NAT gateways rather than a pair per VPC — which matters, because NAT gateways are among the most reliably underestimated costs in a multi-account environment.

The same logic applies to DNS: Route 53 Resolver endpoints in the Network account with rules shared out, rather than resolver configuration duplicated per VPC.

Where Kubernetes changes the calculation

If EKS is part of the plan, network design needs to account for it explicitly. Pod-per-IP consumption, subnet sizing per availability zone, and whether you run one large cluster per environment or a cluster per team all affect address space materially. Our EKS, GKE and AKS comparison covers the networking differences, and managed Kubernetes work usually starts from these landing zone decisions rather than the other way around.

Operating the Landing Zone After Launch

The build is a project. The landing zone is a product, and one that decays without ownership.

What that means in practice:

• A named owning team. Usually platform engineering. An unowned landing zone drifts within two quarters.
• Quarterly control review. Which SCPs fire, which exceptions were granted, which are still needed.
• Drift detection actually watched. Control Tower detects drift and supports re-baselining; the detection is only useful if someone acts on it.
• A landing zone version upgrade path. AWS releases new landing zone versions with architectural changes. Plan upgrades rather than deferring them until a required update forces one.
• Cost attribution that works. Tag policies enforced at the organisation level, checked at vending time, not reconciled at month end.

If you are migrating existing workloads onto the foundation once it exists, our cloud migration services cover the sequencing — landing zone first, then migration waves, not both at once.

Conclusion

A landing zone is mostly a set of decisions, and a handful of them are effectively permanent: your IP allocation scheme, your OU boundaries, whether the management account stays empty, and whether accounts are vended or clicked. Everything else can be adjusted later without a migration.

The recurring pattern in enterprise builds is teams reaching for the tooling before settling the structure. Control Tower will happily create an organisation with a poorly designed OU tree, and AFT will vend accounts into it perfectly consistently. Decide the shape first, then automate it.

If you are planning a foundation, inherited one that has drifted, or need existing accounts brought under governance without disrupting production, our cloud migration services and Terraform consulting cover exactly this work — OU design, control rollout, account vending and the network foundation underneath.

Talk to our team → We will start with your account inventory and address space, because that is where the expensive surprises live.