What Is a Cloud Landing Zone?

A cloud landing zone is a pre-configured, well-governed starting environment for an organization’s cloud footprint — a baseline of accounts, networking, identity, logging, and security controls that gets applied automatically whenever a new project, team, or workload needs its own space in the cloud. Instead of every new account or subscription starting from a blank slate and being configured by hand, a landing zone gives it a consistent, secure foundation from the moment it’s created.

The problem it solves

A single cloud account works fine for a small team. But as an organization grows, it typically ends up with many accounts or subscriptions — one per team, per environment, per business unit, or per compliance boundary — and manually configuring each one identically is where things go wrong. Networking gets set up slightly differently each time. One team forgets to enable centralized logging. Another sets overly permissive IAM policies because nobody remembered the org-wide standard. Multiply this by dozens or hundreds of accounts, and inconsistency becomes the norm rather than the exception — which is exactly the condition that leads to security gaps and compliance failures.

A landing zone addresses this by codifying the baseline once, as infrastructure as code, and applying it automatically to every new account. The goal isn’t to lock teams into a single rigid setup for everything they build — it’s to guarantee that certain non-negotiable things (network segmentation, centralized logging, identity federation, baseline security controls) are correct and consistent by default, everywhere, before a team even starts building on top of it.

What a landing zone typically includes

While specifics vary by cloud provider and organization, a landing zone generally standardizes:

• Account or subscription structure — a hierarchy that separates production from non-production, and often separates by business unit or team, each with its own account boundary rather than everything living in one shared account.
• Network topology — a standard VPC layout, connectivity back to shared services or on-premises networks, and defined availability zone usage for resilience.
• Identity and access management — centralized identity federation so users and roles are managed in one place rather than duplicated per account, plus a baseline of least-privilege roles new accounts inherit automatically.
• Logging and monitoring — centralized, tamper-resistant audit logs and metrics shipped to a security or observability account, so nobody has to remember to wire this up per project.
• Guardrails — automated policy checks (sometimes called service control policies or policy-as-code) that prevent certain actions outright, like disabling logging or opening a database to the public internet, rather than relying on manual review to catch them after the fact.

Landing zones and infrastructure as code

Landing zones are almost always implemented through infrastructure as code, because the entire point is repeatability: the baseline has to be provisioned identically every time, and it has to be auditable and versioned like any other code. Major cloud providers ship opinionated starting points for this — reference architectures and automation that stand up the standard structure — but most organizations customize them to their own compliance and organizational requirements rather than using them unmodified.

This is also why landing zones pair naturally with GitOps workflows: changes to the baseline itself go through the same review and deployment pipeline as application code, so a change to a core security control is visible, reviewed, and traceable rather than made by hand in a console.

Landing zone vs a single shared account

	Single shared account	Landing zone (multi-account)
Isolation between teams/workloads	Weak — shared blast radius	Strong — account boundary limits impact
Consistency of security baseline	Manual, drifts over time	Automated and enforced on every new account
Onboarding a new team or project	Ad hoc configuration each time	New account provisioned from a known-good template
Auditability	Mixed logs, hard to separate by team	Centralized logging with clear account-level attribution
Initial setup effort	Low	Higher upfront investment

The tradeoff is upfront complexity: setting up a proper landing zone takes real design and engineering effort before any application workload is deployed. For a small startup running everything in one account, that investment often isn’t worth it yet. It starts paying off once an organization has enough accounts, teams, or compliance requirements that manual consistency becomes unreliable — which, in practice, tends to happen sooner than most teams expect.

Landing zones and multi-cloud

A landing zone is usually built for a single cloud provider’s account model, since the constructs — accounts, organizational units, IAM policies — are provider-specific. Organizations running on more than one provider typically build a separate landing zone per cloud, connected by shared identity and logging standards, rather than one landing zone that spans providers directly. This is one of the practical realities that makes multi-cloud strategies more operationally demanding than they sound: the governance layer has to be built and maintained twice, not shared.

The takeaway

A cloud landing zone is the automated, codified baseline that every new cloud account or subscription inherits — standard networking, identity, logging, and security guardrails applied consistently from day one, instead of configured by hand and drifting apart over time. It’s an upfront investment in infrastructure as code that pays off as an organization’s cloud footprint grows past the point where manual consistency across accounts is realistic, turning “did we remember to configure this correctly” into a solved problem rather than a recurring risk.