Field guide · AWS and Azure
Cloud infrastructure: the landing zone, layer by layer
Every workload in the cloud lands somewhere: in an account or subscription, behind an identity provider, on a network, with its logs kept or lost. A landing zone is that place, built on purpose before the first workload arrives. Here are its six layers, the AWS and Azure building blocks for each, and the decisions that are expensive to undo.
Definition
What is a landing zone?
NIST defines cloud infrastructure as “the collection of hardware and software that enables the five essential characteristics of cloud computing”. In its infrastructure-as-a-service model, the provider runs that layer and you control what sits on top.
That still leaves a lot to design: how your share is divided, who can reach it, how it connects and what it records. Settle those once, for every workload, and you have a landing zone. AWS calls it “a well-architected, multi-account environment that’s based on security and compliance best practices”. Microsoft describes “a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment”. Google Cloud calls it a cloud foundation.
With a landing zone, a new team gets an account that is already connected, logged and governed. Without one, it gets an empty account and a queue of tickets. What Is Cloud Computing? What Senior Engineers Actually Need to Know makes the wider point: the value is in the operating model, not the venue.
Field terms
- Account or subscription
- The boundary for access, cost and quotas. AWS allocates costs per account by default. Microsoft calls subscriptions policy and management boundaries.
- Organizational unit or management group
- A group of accounts or subscriptions that policies attach to.
- Guardrail
- A rule enforced from above. An AWS service control policy restricts permissions but never grants them. Azure Policy assignments are inherited by every child scope.
- Vending
- Creating an account or subscription from a request, in code, with the baseline applied.
- Break-glass access
- An approved emergency route into an account for someone who normally has no access.
Layer by layer
What are the components of a landing zone?
Six layers, built from the bottom up. For each: what lives there, what to settle early, and what to watch for.
-
Layer 01
Organization and guardrails
The root, the groups of accounts or subscriptions under it, and the policies on each group.
- Decide early
- The first groups. AWS recommends grouping by function, compliance needs or common controls, not reporting lines. Microsoft advises three or four levels at most.
- Watch for
- Workloads in the AWS management account. Service control policies don’t apply there, so keep it nearly empty.
-
Layer 02
Identity
One identity provider, single sign-on into every account or subscription, roles per job function, and a break-glass route.
- Decide early
- The source of truth for people, and how pipelines sign in. Secrets Management in 2026: Sprawl, Non-Human Identities, and the Vault vs Workload Identity Decision explains workload identity: short-lived tokens instead of stored keys.
- Watch for
- Shared admin users, and long-lived cloud keys in CI variables.
-
Layer 03
Network
The address plan, a hub for shared links and inspection, spokes for workloads, the on-premises link, egress and DNS.
-
Layer 04
Logging and security
An audit trail from every account into a log archive, and security tooling that watches all accounts from one place.
- Decide early
- Retention, who reads the archive, and where findings go. An AWS organization trail covers every member account, and member accounts can’t change or delete it.
- Watch for
- Logs kept only where they were produced. Azure deletes activity log events after 90 days unless you export them, for example to a Log Analytics workspace.
-
Layer 05
Shared services
What every team uses and no team should run alone: CI/CD runners, artifact registries, golden images, DNS and monitoring.
- Decide early
- What counts as shared, who owns each service, and how spokes reach it.
- Watch for
- A shared account that fills up with workloads nobody placed. AWS guidance keeps application workloads out of the Infrastructure OU.
-
Layer 06
Workloads
An account or subscription per workload and environment, vended with network, roles, budget and tags in place.
- Decide early
- What a team asks for, what it gets, and how long that takes.
- Watch for
- Vending that is slower than the workaround. Teams share accounts, and the boundary this layer exists for disappears.
AWS and Azure
How do AWS and Azure landing zones compare?
Same layers, different names. Every name links to the provider’s documentation.
| Layer | AWS | Azure |
|---|---|---|
| 01 Organization | AWS Organizations, with organizational units and service control policies | Management groups and subscriptions, with Azure Policy |
| 02 Identity | IAM Identity Center, federated once to your identity provider, with permission sets across accounts | Microsoft Entra ID, Azure RBAC, and Privileged Identity Management for just-in-time admin roles |
| 03 Network | A Network account with Transit Gateway, Direct Connect or Site-to-Site VPN, and VPC IPAM | A connectivity subscription with a hub-and-spoke network or Azure Virtual WAN |
| 04 Logging and security | Log Archive and Security Tooling accounts, an organization trail in CloudTrail, and GuardDuty for threat detection | A management subscription with a central Log Analytics workspace, and Microsoft Defender for Cloud |
| 05 Shared services | Shared Services and Operations Tooling accounts in the Infrastructure OU | Platform subscriptions, with gateways, firewall and DNS in the hub network |
| 06 Workloads | Account Factory in AWS Control Tower | Subscription vending |
| Build it with | AWS Control Tower, optionally with Customizations for AWS Control Tower or Landing Zone Accelerator, or a custom build | The platform landing zone accelerator, with Azure Verified Modules for Bicep or Terraform |
Early decisions
Which landing zone decisions are hard to change later?
Most landing zone settings are cheap to change. These four are not, because everything built afterward depends on them.
How many accounts or subscriptions do you need?
- Default
- One per workload per environment, with production apart from non-production. AWS recommends both, and Microsoft uses subscriptions to separate environments.
- Change it when
- A few closely related services always ship together and share an owner.
- Cost to change later
- High. Moving a live workload means moving its data, identities and network links.
Hub-and-spoke, or a managed hub?
- Default
- Hub-and-spoke you route yourself. Microsoft suggests it for one or a few regions, fewer than 30 site-to-site tunnels, and full control of routing.
- Change it when
- You need many regions and sites, SD-WAN, or transit between VPN and ExpressRoute: then Microsoft points to Virtual WAN. On AWS, the recommended hub is a Transit Gateway in the Network account.
- Cost to change later
- High. The address plan and routing model are built into every spoke.
Who owns which layer?
- Default
- A platform team runs layers 01 to 05 as a product. Workload teams manage their own subscriptions inside the guardrails, which Microsoft calls subscription democratization.
- Change it when
- There are only one or two teams. One team can own it all, if the layers stay separate in code. Platform Engineering vs DevOps: What an Internal Developer Platform Actually Buys You covers when a platform team pays off.
- Cost to change later
- Medium. Access, on-call and budgets move with the people.
Use the provider’s accelerator, or build your own?
- Default
- Start from the provider’s. AWS recommends that all users start with Control Tower. Microsoft recommends its infrastructure-as-code accelerator. Keep the result in infrastructure and policy as code.
- Change it when
- Only a custom solution can meet your requirements, and you have the expertise to run it, as AWS puts it.
- Cost to change later
- Medium. Switching means re-enrolling accounts and reconciling the policies you have.
Field note from Nike
Guardrails don’t have to slow teams down. At Nike, the work was guardrailed self-service tooling that made the fastest path the safest path, with cloud automation across AWS and Azure. Bot provisioning went from a 45-minute manual flow to about 3 minutes. Vending works the same way: if the front door is slower than the side door, teams use the side door. Read the Nike case
Failure patterns
Why do landing zones go wrong?
The symptoms show up in delivery long before anyone calls them a landing zone problem.
| What the team sees | Usual cause | Fix |
|---|---|---|
| A new team waits weeks for an account. | Vending is a ticket someone works by hand. | Vend from code, with network, roles, budget and tags applied on creation. |
| Two networks can’t be connected. | Their address ranges overlap, because nobody planned them. | Allocate every range from one plan, with room for regions you don’t use yet. |
| Nobody knows who opened a firewall rule. | Console changes, with logs kept only in the account. | Network changes through code review, and every account’s audit trail in the log archive. |
| A test job changed production data. | Production and test share an account or subscription. | Split them at the account or subscription boundary. |
| Teams ask for a guardrail exception every week. | Policies written without the teams that live with them. | Policies in code, reviewed with those teams, with exclusions scoped to one subscription or group. |
Row three is configuration drift. Infrastructure as Code in 2026: Drift, Policy, and the Terraform vs OpenTofu Decision covers how to detect it, and why a drift alert should be treated as a defect.
Readiness
Is your landing zone ready for production workloads?
Check every line before the first production workload lands. A line that is only mostly true counts as not done.
Before the first production workload
01Organization
02Identity
03Network
04Logging and security
05Shared services
06Workloads
Where to start
Start small. AWS advises beginning with a subset of its recommended structure and growing it as needs arise. A workable order:
- Organization, guardrails, log archive and identity.
- The address plan and the network hub.
- One real workload, vended the way every later one will be.
- Shared services, as more teams arrive.
Pick a first workload with a clear reason to be in the cloud. At ASML, we initiated offloading selected production machine tests to Google Cloud to increase throughput and shorten feedback cycles. Read the ASML case
Where the time goes
See where your last release waited
Waiting for an account, an environment or a firewall change shows up as release time. The free Release Check shows where your last release spent its time and what that costs a year, in under 5 minutes and without a call.