---
title: "What Actually Belongs in a Landing Zone — and What Gets Pushed Into One for No Reason"
description: "A landing zone is not a list of services — it is the set of decisions you cannot reverse later. Azure, AWS and Google describe theirs in different words and converge on the same core, and everything else vendors bundle into the term can be added after your first workload is already running."
author: Aleksei Aleinikov
date: 2026-08-25
lang: en
tags: [landing-zone, azure-landing-zone, aws-landing-zone, cloud-landing-zone, gcp-landing-zone, aws-control-tower, cloud-adoption-framework]
canonical: https://www.alekseialeinikov.com/en/blog/topics/cloud/what-belongs-in-a-cloud-landing-zone-2026
source: alekseialeinikov.com
---
# What Actually Belongs in a Landing Zone — and What Gets Pushed Into One for No Reason
Ask five engineers what a landing zone is and you will get five inventories. Someone will include the CI/CD pipeline. Someone will include the monitoring stack. Someone will insist it is not done until the FinOps dashboards are live.
The vendors are not much help either. Azure documents eight design areas, Google names four core elements, and AWS defines the term in a single sentence that leaves out networking entirely.
They are all describing something real. They are not describing the same thing.
The useful definition is not a list of components. It is this: **a landing zone is the set of decisions you cannot reverse once workloads are running on top of them.** Everything else is a roadmap item that got promoted into a blocker.
## Azure, AWS and Google Landing Zones Agree on the Core
The interesting evidence is that frameworks built independently, with different terminology and different products, land on the same substance.
**Google** names four core elements you must design for a landing zone: identity provisioning, resource hierarchy, network, and security controls.
**Microsoft's Cloud Adoption Framework** splits Azure landing zones into eight design areas across two groups. The environment areas: Azure billing and tenant, identity and access management, resource organisation, network topology and connectivity. The compliance areas: security, management, governance, and platform automation and DevOps.
**AWS** defines a landing zone as a well-architected, multi-account environment based on security and compliance best practices — the enterprise-wide container that holds your organizational units, accounts, users and other resources.
Eight versus four versus one sentence looks like disagreement. Line them up and it is not:
| Substance | Google | Microsoft | AWS |
| --- | --- | --- | --- |
| Who you are | Identity provisioning | Identity and access management | IAM Identity Center directory |
| How resources are arranged | Resource hierarchy | Resource organisation | Organizations OUs, Account Factory |
| How packets move | Network | Network topology and connectivity | *Outside the definition* |
| What is enforced | Security controls | Security, Governance | Controls: preventive, detective, proactive |
| How it gets deployed | (Best practice: IaC + GitOps) | Platform automation and DevOps | Account Factory, CloudFormation StackSets |
| How it is run | (Additional element) | Management | Dashboard, drift detection |
| Commercial setup | (Prerequisite: org + billing account) | Billing and tenant | Management account, Organizations |
Microsoft promotes to first-class status what Google files under prerequisites and best practices. That is a documentation choice, not an architectural disagreement.
AWS is the genuinely different one, and it is worth pausing on.
## The AWS Landing Zone Is a Different Shape
AWS scopes the word more narrowly than the other two. A Control Tower landing zone gives you a root, a Security OU containing Log Archive and Audit accounts, an optional Sandbox OU, an IAM Identity Center directory, and a set of controls applied across the organisation. Networking is not in that list. There is no address plan, no connectivity design, no segmentation model — those remain your problem, handled separately.
That asymmetry has a practical consequence: **a landing zone checklist copied from one cloud to another will mislead you.** An Azure architect handing an AWS team "the landing zone requirements" will over-specify accounts and under-specify VPCs. It runs the other way too.
The second difference is the timeline claim. AWS says Control Tower builds a landing zone in less than an hour. Google says designing and deploying one can take multiple weeks. Both are accurate, because they are measuring different things: Control Tower *deploys a pre-made opinion*, while Google's guidance describes *the process of forming your own*. If AWS's opinion fits your organisation, you have skipped the expensive part legitimately. If it does not, the hour you saved is not the relevant number.
And speed does not buy reversibility. AWS's own documentation is refreshingly blunt about it:
> these cannot be renamed later, and existing accounts cannot be added for security and logging after initial launch
That is a shared-account naming and enrolment decision, made in the first hour, that you live with permanently. The reversibility test does not care how fast the deployment was.
Four decisions you make once, and a layer you can keep adding to for years.
## There Is No Standard Landing Zone, and Google Says So
Before accepting anyone's landing zone checklist, read this line from Google's architecture centre:
> The diagram above is only an example, because there is no single or standard implementation of a landing zone.
The design depends on your industry, your organisational structure, your security and compliance requirements, the workloads you are moving, your existing infrastructure and where your business and customers are.
This matters commercially. If a partner or a blog post presents *the* landing zone as a fixed deliverable, what you are being sold is an opinion with a price attached. Sometimes that opinion is excellent and buying it is the right call. But you should know you are buying an opinion, not a specification.
## The Real Test: Can You Change It Later?
Here is the filter that sorts the argument. For each candidate element, ask: **if we get this wrong, what does fixing it cost after workloads are live?**
### Fails the test — decide before the first workload
**Resource hierarchy.** Your organisation, folder and project structure determines where policy attaches and where budgets aggregate. Moving projects between folders is possible; rebuilding a hierarchy under running workloads while IAM and org policies inherit from it is a project nobody volunteers for.
**Network address space.** CIDR allocation is the classic irreversible decision. Overlapping ranges surface years later when you acquire a company or connect a partner network, and the fix is re-addressing production. Decide the plan even for regions you have not opened yet.
**Identity domain and federation.** Which directory is authoritative, how it synchronises, what the trust path looks like. Everything else in your security model inherits from this.
**Security perimeters.** Where the boundaries actually sit — VPC Service Controls perimeters in Google's example architecture, network segmentation, the shape of your Shared VPC. These define what is even expressible later.
### Passes the test — add it when you need it
Google lists these explicitly as elements beyond the core, to be added according to business requirements:
- Monitoring and logging
- Backup and disaster recovery
- Compliance tooling
- Cost efficiency and control
- API management
- Cluster management
None of these require you to rebuild anything to introduce. You will want most of them, some of them urgently. That is a different statement from "the foundation is not finished without them."
## The Most Over-Scoped Item on Every Foundation Project
This one deserves its own section, because Google's documentation says something most foundation projects refuse to believe:
> if your first workload does not require access to on-premises network resources, you could build connectivity to your on-premises environment later.
Hybrid connectivity — Interconnect, Direct Connect, ExpressRoute, the VPN fallback, the routing design, the firewall change requests, the network team's queue — is routinely the longest pole in the tent. It is also frequently unnecessary for the first workload, which is often a new, cloud-native, internet-facing service that talks to nothing in the data centre.
Sequencing it after the first deployment does not make it optional. It makes it parallel instead of blocking.
The order matters more than the inventory. Blocking on the wrong item costs months.
## Modular Means Your First Version Is Wrong on Purpose
Google's guidance contains an admission worth quoting because it contradicts how these projects are usually run:
> because a landing zone is modular, your first iteration of a landing zone is often not your final version.
And the practical instruction that follows: centre the initial design on the elements required to migrate your first workloads, and plan to add other elements later.
Compare that with the typical foundation programme, which sets out to be complete before anything runs. Those programmes overrun — Google notes deployment "can take multiple weeks" and that project management is essential, which is documentation-speak for *this slips* — and they are still wrong at the end, because every requirement in them was guessed at without a real workload to test against.
The teams that do this well ship a deliberately incomplete foundation, put one real workload on it, and let that workload tell them what the second iteration needs.
## When One Landing Zone Is Not Enough
Worth knowing before you contort a single design to satisfy one awkward workload: Google explicitly supports running **more than one landing zone** when some workloads have very different scalability or compliance requirements.
What can be shared across them: identities, billing, and the organisation resource.
What typically differs: network setup, deployment mechanisms, folder-level policies.
If you have one regulated workload bending the entire design out of shape, a second landing zone may be cheaper than the compromise. It is a real ongoing cost, so make it a decision rather than an accident.
## What Actually Goes Wrong
Patterns worth naming, because they cost quarters, not sprints:
- **Blocking on hybrid connectivity** that the first workload does not use. The single most common schedule killer.
- **Deferring address planning** because "we'll only use one region at first." The bill arrives at the acquisition, or the partner integration, or the second region.
- **Treating the pipeline as foundation.** IaC and GitOps are a technical best practice for deploying the landing zone — genuinely important, and not the same as a decision you cannot reverse.
- **Building for imagined workloads.** Requirements guessed without a real service are guesses with a Terraform module attached.
- **Copying a landing zone checklist between clouds.** Azure and Google put the network in the core; AWS leaves it out of the definition. A requirements document ported across vendors over-specifies one half and silently drops the other.
- **Confusing "we want this" with "we cannot start without this."** Monitoring is essential. It is also addable on a Tuesday.
- **Assembling the wrong team.** Google's guidance calls for security, identity, network and operations in one room with a lead who knows the platform. A landing zone designed only by the network team looks exactly like one.
## Landing Zone Checklist: Seven Questions Before You Build
1. Write down your four: identity source, resource hierarchy, address plan, security boundaries. If any is undecided, you do not have a foundation yet.
2. For every other proposed element, ask what it costs to add in six months. If the answer is "not much," take it off the critical path.
3. Check whether your first workload actually needs on-premises access. If not, decouple the connectivity project.
4. Plan address space for regions you have not opened. It is free now and expensive later.
5. If you are on AWS, decide the shared-account names and enrolment before launch — that one is documented as permanent — and plan the network separately, because Control Tower will not do it for you.
6. Deploy it as code with a pipeline — Google's own best practice — but do not let building the pipeline become the foundation project.
7. Pick a real first workload before finishing the design. It will find the gaps your document cannot.
8. If one workload is distorting everything, price a second landing zone instead.
## The Point
A landing zone is not a product, a checklist, or a partner engagement. Google's documentation says outright there is no standard implementation, and that the first version is not meant to be the last. AWS will build you one in an hour and still hand you decisions it tells you are permanent.
What it actually is: four decisions that are expensive to unwind, plus a modular layer you will extend for as long as the platform exists. Sorting your requirements into those two buckets is most of the architecture work — and the projects that fail are almost always the ones that put a deferrable item on the critical path and a permanent one in the backlog.
---
**Related reading:** for the layer that sits on top, see [platform engineering on Kubernetes](https://www.alekseialeinikov.com/en/blog/topics/devops/platform-engineering-on-kubernetes-2026) and the [secure-by-default GKE reference architecture](https://www.alekseialeinikov.com/en/blog/topics/architecture/secure-by-default-gke-reference-architecture-2026). For the identity decision in practice, see [killing service account keys with Workload Identity Federation](https://www.alekseialeinikov.com/en/blog/topics/security/kill-service-account-keys-workload-identity-federation-2026). For the resilience element, see [backups are not disaster recovery](https://www.alekseialeinikov.com/en/blog/topics/cloud/backups-are-not-disaster-recovery-2026).
**Sources:** [Landing zone design in Google Cloud](https://docs.cloud.google.com/architecture/landing-zones) (last reviewed 2 January 2026), [Azure landing zone design areas](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas) (Cloud Adoption Framework, updated December 2025), and [What is AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) plus [How AWS Control Tower works](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html).
