Cloud Landing Zones: Getting the Foundation Right

Key takeaways

A landing zone is the pre-configured foundation that every workload inherits.
Identity, account structure and network topology are the hardest decisions to change later.
Guardrails should be enforced as code, not documented as guidance.
A production-ready landing zone is usually a six-to-eight-week engagement.

What a landing zone is

A landing zone is the foundation of a cloud environment: the account or subscription structure, identity, networking, security baseline, logging and governance controls that are in place before workloads arrive. Every application deployed afterwards inherits these decisions.

Each major provider publishes a reference approach — the Azure landing zone within Microsoft's Cloud Adoption Framework, AWS Control Tower and the Landing Zone Accelerator, and Google Cloud's enterprise foundations blueprint. They are good starting points, not finished designs. Your regulatory obligations, existing identity estate and operating model determine how they should be adapted.

The eight design areas

Identity and access. Federate with your existing directory, enforce MFA, eliminate standing administrative privilege and separate break-glass accounts.
Resource hierarchy. Design the management group, organisational unit or folder structure around how you govern — by environment, business unit or data sensitivity — not around today's org chart.
Network topology. Choose hub-and-spoke or a managed virtual WAN, plan IP address space for growth, and define how on-premise and internet traffic is inspected.
Security baseline. Enable native threat detection, posture management and encryption defaults across every account from day one.
Logging and monitoring. Centralise activity and security logs into accounts that workload teams cannot alter, with retention aligned to your obligations.
Governance and guardrails. Enforce policies as code: permitted regions, required tags, blocked public exposure, mandatory encryption.
Cost management. Budgets, alerts, tagging for allocation and a named owner for every account.
Platform automation. Deliver the whole landing zone through infrastructure as code so that new accounts are consistent and changes are reviewable.

Decisions that are expensive to reverse

Some choices can be adjusted cheaply later. These cannot, so give them the most attention:

IP address planning. Overlapping ranges block future connectivity between environments and back to your data centre.
Hierarchy design. Moving hundreds of accounts or subscriptions between branches is disruptive and affects inherited policy.
Identity model. Changing identity providers after workloads are live touches every user and every application.
Region strategy. Data residency requirements should determine permitted regions before data lands anywhere.

Guardrails: preventive and detective

Good landing zones combine preventive guardrails, which stop non-compliant actions — for example, blocking resources in unapproved regions — with detective guardrails, which flag drift for remediation. Start with a small set of preventive rules that everyone agrees on, and expand detective coverage over time. Too many preventive rules on day one simply push teams to request exceptions.

Common mistakes we see

Building workloads first and retrofitting the landing zone afterwards.
Treating the landing zone as a one-off project with no owner once it goes live.
Allowing manual changes in the console, so the code no longer describes reality.
Logging everything but monitoring nothing.
Ignoring cost allocation until the first large invoice arrives.

What a good outcome looks like

A new workload team should be able to request an account, receive it within hours with networking, identity, logging and guardrails already in place, and deploy without asking the platform team for permission on every change. That is the real test of a landing zone: it makes the secure path the easy path.

Operating the landing zone after go-live

A landing zone is a product, not a project. Once workloads arrive, it needs an owner and a rhythm:

A named platform team responsible for the foundation, its backlog and its service levels.
Version-controlled changes reviewed and deployed through the same pipeline that built it.
Regular drift and compliance reports showing which accounts deviate from guardrails and why.
A clear exception process so teams can request deviations that are recorded, time-limited and reviewed.
Quarterly reviews of cost, security findings and new provider capabilities worth adopting.
Documentation that stays current — onboarding guides, network diagrams and decision records.

Organisations that treat the landing zone this way find that security and cost improve over time. Those that treat it as finished find that drift, exceptions and shadow accounts slowly undo the original design.

Frequently asked questions

How long does it take to build a landing zone?

A production-ready landing zone on a single provider typically takes six to eight weeks, including identity integration, networking, guardrails, logging and a migration runway. Multi-cloud or sovereign requirements extend this.

Can we fix an existing environment instead of starting again?

Usually, yes. A landing zone assessment identifies gaps, and many can be remediated in place. Some issues, such as overlapping address space, may justify building a new foundation and migrating workloads into it.

Should we use the provider's reference architecture as-is?

Use it as a starting point. Reference architectures are generic by design; they need adapting to your regulatory, identity and operating requirements.