What Is a Cloud Landing Zone? Complete 2026 Guide
Cloud adoption rarely waits for governance to catch up. A single engineer can spin up a new account, a new virtual network, and a production workload before lunch, while identity rules, logging, and cost ownership are decided later, if at all. Multiply that by dozens of teams and hundreds of accounts, and an organization ends up with inconsistent permissions, invisible spending, and security gaps nobody chose on purpose. A cloud landing zone is the answer many enterprises reach for: a reusable, governed starting point that gives every new workload the same identity model, network pattern, security guardrails, and cost structure from day one, instead of leaving each team to reinvent the foundation.
TL;DR
A cloud landing zone is a pre-configured, governed multi-account or multi-project cloud environment that provides identity, networking, security, logging, and cost controls before any workload is deployed.
It solves account sprawl, inconsistent permissions, missing logs, and unclear cost ownership that show up once more than one team uses the cloud.
Core building blocks include the account or project hierarchy, identity and access management, networking, security guardrails, centralized logging, governance policy, FinOps tagging, and automation.
There is no single universal landing zone product. AWS, Microsoft Azure, and Google Cloud each provide their own guidance, services, and terminology for the same underlying idea.
A landing zone is not a one-time project. It needs ongoing ownership, automation through Infrastructure as Code, and revision as the organization and its workloads change.
Complexity should match organizational scale. A small team with one simple workload does not need the same landing zone as a regulated global enterprise.
What Is a Cloud Landing Zone? (Quick Answer)
A cloud landing zone is a pre-configured, governed cloud environment that gives an organization a secure starting point before it deploys workloads. It combines an account or project structure, identity and access management, networking, security guardrails, centralized logging, and cost controls into a repeatable foundation, so new applications inherit consistent governance instead of each team building it from scratch.
Table of Contents
What Is a Cloud Landing Zone?
A cloud landing zone is a pre-configured, governed cloud environment that an organization builds before it deploys production workloads. It bundles the account or project structure, identity and access management, network design, security guardrails, centralized logging, and cost controls into one repeatable foundation, so every new workload starts from the same secure baseline instead of a blank environment.
Technically, a landing zone is less a product and more an architectural pattern. It establishes a resource hierarchy, such as AWS Organizations with organizational units, Azure management groups with subscriptions, or Google Cloud folders with projects. Controls defined at the top of that hierarchy, such as a policy that blocks public storage buckets, are inherited automatically by everything created underneath it. This inheritance model is what lets a platform team set a rule once and have it apply consistently as the organization adds new teams and workloads.
A landing zone also standardizes shared services that every workload would otherwise have to build for itself: DNS, centralized logging pipelines, a place to store secrets, a pattern for connecting to on-premises networks, and a process for provisioning new environments. Because these pieces are already in place, a new workload can be onboarded in days rather than the weeks it would take to negotiate networking, identity, and security decisions from scratch. This is what makes a landing zone scalable and repeatable: the hard architectural decisions are made once, and every subsequent workload reuses them.
What a Landing Zone Is Not
A landing zone is not a single account or subscription, not a single virtual network, and not simply an Infrastructure as Code repository. It is also not a one-time deployment. It is an operating foundation that combines organizational structure, identity, networking, security, and automation, and it keeps evolving as the organization's requirements change.
Why Do Organizations Need Cloud Landing Zones?
Cloud problems that are invisible with one team and one account become unavoidable once an organization scales past that point. Without a shared foundation, every team makes its own decisions about identity, networking, and security, and those decisions rarely agree with each other.
Common symptoms of a missing foundation include:
Account, subscription, or project sprawl, where new environments are created ad hoc with no consistent naming, ownership, or lifecycle process.
Inconsistent identity and access management, including direct user permissions instead of role-based groups, and no consistent process for privileged access.
Inconsistent or absent network segmentation, so workloads that should never talk to each other technically can.
Missing or fragmented logging, which slows down incident response and makes audits difficult.
Security configuration drift, where each team applies its own interpretation of a baseline security policy, if any.
Manual, console-driven provisioning that does not scale and is hard to reproduce or audit.
Inconsistent or missing resource tagging, which makes it impossible to attribute cloud spend to the team or project responsible for it.
Unclear resource ownership, so nobody knows who to contact when something breaks or needs to be decommissioned.
Duplicated platform effort, where multiple teams independently solve the same identity, logging, or networking problem.
These problems compound cloud migration and compliance work: an auditor asking for evidence of least-privilege access, or a security team trying to prove that only approved regions are in use, has no consistent answer without a shared foundation. A landing zone addresses this by centralizing the decisions that apply to everyone and delegating the decisions that are specific to each workload.
That said, a landing zone is a matter of degree. A small team running one simple, low-risk application in a single account does not need enterprise multi-account governance with dedicated logging and security accounts. The investment should match the organization's scale, the number of teams and workloads, and its regulatory exposure.
What Problems Does a Cloud Landing Zone Solve?
A landing zone maps specific operational problems to specific architectural responses. The list below summarizes the most common ones; outcomes depend on how well the landing zone is designed and maintained, not on the existence of a landing zone alone.
Problem: Inconsistent account or project creation. Response: A standardized account or project vending process through automation. Result: New environments follow the same baseline every time.
Problem: Direct, ungoverned user permissions. Response: Federated identity, role-based access, and groups instead of individual grants. Result: Access is auditable and easier to review or revoke.
Problem: No visibility into security posture. Response: Centralized, aggregated logging and monitoring across accounts or projects. Result: Faster detection and simpler audits.
Problem: Inconsistent network segmentation. Response: A defined network topology, such as hub-and-spoke, with shared connectivity services. Result: Predictable traffic flow and a smaller blast radius per workload.
Problem: Unclear or missing cost ownership. Response: Mandatory tagging and a cost-allocation hierarchy tied to the account or project structure. Result: Spend can be attributed to a team, product, or cost center.
Problem: Slow, manual workload onboarding. Response: Automated, self-service environment provisioning through Infrastructure as Code. Result: New workloads launch in days instead of weeks.
Problem: Security policy drift between teams. Response: Policy as code enforced through preventive and detective guardrails. Result: A consistent baseline that is enforced rather than merely documented.
None of these responses is automatic. A landing zone creates the mechanism for consistency; an organization still has to define the right policies, maintain them, and hold teams accountable for using the guardrails correctly.
Core Components of a Cloud Landing Zone
A landing zone is made up of interdependent building blocks. The sections below describe each one at a conceptual level; specific services differ by cloud provider.
Organization, Accounts, Subscriptions, and Projects
Every major provider offers a hierarchy for grouping and isolating resources: AWS Organizations with member accounts and organizational units, Azure management groups with subscriptions, and Google Cloud folders with projects. This hierarchy is the isolation boundary a landing zone builds on. Separate accounts or projects for production, non-production, security tooling, and logging limit the blast radius of a misconfiguration or a compromised credential, and they let policy be applied at the right level rather than resource by resource.
Identity and Access Management
Identity is usually described as the most important layer of a landing zone, because nearly every other control depends on it. A landing zone typically federates identity from an existing enterprise identity provider rather than creating disconnected local accounts, enables single sign-on, and grants access through roles and groups instead of individual grants, following the principle of least privilege. It also separates human identities from workload or machine identities, defines how privileged administrative access is granted and reviewed, and plans for break-glass access: a documented emergency path for when normal federated access is unavailable.
Networking and Connectivity
The networking layer covers IP address planning, segmentation between environments, routing, DNS, ingress and egress traffic control, and connectivity back to on-premises data centers over VPN or dedicated circuits. Landing zones typically centralize shared network services, such as a hub network that inspects and routes traffic for multiple workload networks, rather than letting every team build its own internet gateway and DNS configuration.
Security and Compliance Guardrails
Guardrails are preventive controls that stop a non-compliant action before it happens, such as a policy blocking public storage buckets, and detective controls that flag a violation after the fact for remediation. A landing zone typically defines encryption expectations, may restrict which regions or services are approved for use, and includes a documented process for requesting an exception. Guardrails protect the shared foundation; they do not replace the security work an individual workload still owns, such as application-level authentication or dependency patching.
Logging, Monitoring, and Observability
A landing zone centralizes audit logs, security logs, and platform-level logs, typically in an account or project dedicated to logging that is separate from the workloads generating the logs. This separation limits the ability of a compromised workload to tamper with its own audit trail. On top of centralized logs, the platform layer typically adds monitoring, alerting, and a defined retention period that satisfies both operational and compliance needs.
Governance and Policy Management
Governance covers the policies, naming conventions, tagging standards, and lifecycle rules that keep the environment consistent as it grows. In a landing zone, policy is usually defined once near the top of the resource hierarchy and inherited by everything below it, which is what allows governance to scale without a person manually checking every new resource.
Cost Management and FinOps
The account or project hierarchy doubles as a cost-allocation structure. Combined with mandatory tagging for owner, cost center, and environment, it lets an organization see exactly which team or product is generating spend. A landing zone does not automatically reduce cloud cost; what it does is make cost visible and attributable early, which is a prerequisite for any later cost-optimization effort.
Automation and Infrastructure as Code
Rather than manually configuring the console, a mature landing zone is deployed and updated through Infrastructure as Code, using tools such as Terraform or a provider's native IaC service, version-controlled and deployed through a pipeline with review and testing. This is what makes new environments, sometimes called account or subscription vending, both fast and consistent, and it gives the organization a way to detect and correct configuration drift over time.
Shared Platform Services
Some services are genuinely foundational rather than workload-specific: centralized DNS, core network connectivity, a foundation for secrets and key management, and shared security tooling such as a central security information and event management pipeline. These belong in the platform layer so every workload can consume them rather than rebuilding them.
Backup, Resilience, and Recovery Foundations
The platform layer can provide baseline backup policies, cross-region replication options, and recovery tooling, but individual workload teams remain responsible for defining their own recovery time and recovery point objectives and testing that their specific application actually meets them. A landing zone provides the plumbing; it does not substitute for a workload's own resilience design.
How Does a Cloud Landing Zone Work?
A landing zone functions through inheritance and automation rather than manual, one-off configuration. In practice, most organizations build it in roughly this sequence:
Establish the organization and resource hierarchy, such as organizational units, management groups, or folders.
Connect enterprise identity through federation and single sign-on.
Define governance policy at the top of the hierarchy so it is inherited automatically.
Build shared networking and platform services, such as connectivity, DNS, and security tooling.
Configure security guardrails and centralized logging before any workload account exists.
Establish cost and metadata requirements, including mandatory tags.
Automate provisioning so new accounts, subscriptions, or projects deploy through Infrastructure as Code rather than the console.
Create workload environments that inherit the platform's guardrails automatically.
Continuously monitor, audit, and evolve the controls as requirements change.
The result is that a workload team requesting a new environment does not need to individually design identity, networking, and logging. They request an environment, automation provisions it already wired into the shared foundation, and the workload team focuses on the application itself.
Cloud Landing Zone Architecture
A landing zone is easiest to reason about as a set of layers, each depending on the ones below it:
Organization and resource layer: the account, subscription, or project hierarchy that everything else attaches to.
Identity layer: federated identity, roles, groups, and privileged access management.
Governance and policy layer: the rules inherited down the hierarchy.
Connectivity layer: networking, DNS, and hybrid connections to on-premises infrastructure.
Security layer: preventive and detective guardrails, encryption, and vulnerability management integration.
Management and observability layer: centralized logging, monitoring, and alerting.
Financial management layer: tagging, budgets, and cost allocation.
Automation and platform layer: the Infrastructure as Code and pipelines that deploy and maintain everything above.
Workload layer: the individual application environments that consume the platform's guardrails and shared services.
Conceptually, the flow of control runs top to bottom: an organization-wide policy set at the top layer is enforced automatically for every workload at the bottom, without the workload team needing to opt in. The flow of requests runs bottom to top: a workload team requests a new environment, automation provisions it, and it inherits every layer above it by construction rather than by manual configuration.
Platform Landing Zones vs. Workload Landing Zones
Microsoft's Cloud Adoption Framework makes this distinction the most explicit: an Azure landing zone is described as consisting of a platform landing zone, typically one per Microsoft Entra tenant, and multiple application, or workload, landing zones. The platform landing zone is the centralized foundation that establishes governance, security, and shared resources for every workload, while application landing zones are the environments where workload teams deploy and operate their own resources within the guardrails the platform sets.
This split is a useful mental model even outside Azure, because it clarifies where responsibility sits. The platform team owns identity, networking, logging, and policy at the foundation level. The workload team owns everything specific to their application, deployed inside the guardrails the platform provides, without needing platform-level access to do it. Getting this division of responsibility wrong is a common source of landing zone failure: too much centralization slows workload teams down, and too little leaves governance unenforced.
Cloud Landing Zone vs. Other Cloud Concepts
The term landing zone is often confused with related but narrower concepts. The distinctions matter because each of these is a component of a landing zone, not a substitute for one.
Cloud Landing Zone vs. VPC or VNet
A virtual private cloud or virtual network is a single networking construct, one piece of the connectivity layer. A landing zone includes networking but also identity, governance, logging, security, and cost management across potentially many networks.
Cloud Landing Zone vs. Cloud Account, Subscription, or Project
An account, subscription, or project is a single isolation boundary within the resource hierarchy. A landing zone defines how many of these exist, how they relate to each other, and what controls they inherit.
Cloud Landing Zone vs. Cloud Foundation
These terms largely overlap. Google Cloud's own documentation describes a landing zone as also called a cloud foundation, defining it as a modular and scalable configuration that enables an organization to adopt Google Cloud for its business needs. In practice, cloud foundation and landing zone are frequently used interchangeably across the industry.
Cloud Landing Zone vs. Cloud Migration Factory
A migration factory is a repeatable process and toolset for moving a large number of workloads into the cloud, typically in waves. It depends on a landing zone existing first, since the factory needs somewhere governed to land the migrated workloads. The factory is a process; the landing zone is the destination environment.
Cloud Landing Zone vs. Platform Engineering
Platform engineering is a broader discipline focused on building internal developer platforms, self-service tooling, and golden paths for developers. A landing zone is typically the foundational layer a platform engineering team builds on top of; platform engineering extends far beyond account structure into developer experience and internal tooling.
Cloud Landing Zone vs. Kubernetes Platform
A Kubernetes platform manages containerized workloads inside a cluster. A landing zone is provider-and-account-level; a Kubernetes platform typically runs as a workload inside a landing zone's workload layer, consuming the identity, networking, and logging the landing zone already provides.
AWS vs. Azure vs. Google Cloud Landing Zones
AWS, Microsoft Azure, and Google Cloud each describe the landing zone concept differently, and their terminology does not map one to one. Comparing the resource hierarchy, identity approach, and governance mechanism across the three shows both the shared principles and the real differences.
Resource hierarchy: AWS uses AWS Organizations with member accounts grouped into organizational units. Azure uses management groups containing subscriptions. Google Cloud uses an organization node containing folders and projects.
Primary landing zone guidance or service: AWS offers AWS Control Tower, a managed service that automates the setup of a landing zone. Azure offers Azure landing zones through the Cloud Adoption Framework, implemented via infrastructure-as-code or portal-based accelerators. Google Cloud offers landing zone design guidance and the Enterprise Foundations Blueprint, a Terraform-based reference implementation.
Governance mechanism: AWS enforces guardrails through AWS Config rules and service control policies. Azure enforces guardrails through Azure Policy applied at the management group level. Google Cloud enforces guardrails through organization policy constraints applied at the organization or folder level.
Identity approach: AWS typically federates through AWS IAM Identity Center. Azure is built around Microsoft Entra ID as the native identity provider. Google Cloud typically federates through Cloud Identity and workforce identity federation.
Logging and security foundation: AWS centralizes logs using a dedicated log archive account and an audit account, set up automatically by Control Tower. Azure centralizes logging and security through a management subscription within the platform landing zone. Google Cloud centralizes logging and security controls through the enterprise foundations blueprint's logging and security projects.
AWS
AWS documentation defines a landing zone as a well-architected, multi-account AWS environment that is a starting point for deploying workloads, built on AWS Organizations for account management, IAM Identity Center for federated access, and a defined logging and security account structure. AWS Control Tower is the AWS-managed service that automates the setup of this environment, orchestrating AWS Organizations, Config, CloudTrail, and Account Factory for standardized account provisioning. Control Tower automates a landing zone; it is the service, not a synonym for the abstract concept, and AWS also documents a path for a customized, self-built landing zone for organizations with more specific requirements.
Microsoft Azure
Microsoft's Cloud Adoption Framework defines an Azure landing zone as the proven architecture for governing and scaling a multi-subscription Azure environment, made up of a platform landing zone and one or more application landing zones. The platform landing zone is implemented either through an infrastructure-as-code accelerator using Azure Verified Modules for Terraform or Bicep, which Microsoft recommends, or through a portal-based accelerator for teams without infrastructure-as-code experience. Governance is enforced through Azure Policy applied at the management group level, and application landing zone accelerators help workload teams deploy compliant environments faster.
Google Cloud
Google Cloud's Architecture Center describes a landing zone, which it also calls a cloud foundation, as a modular and scalable configuration built on an organization resource containing folders and projects. Google Cloud offers several implementation paths: working with Google Cloud partners or professional services, the Customer Onboarding program, a generic landing zone setup guide in the console, or the Terraform-based example foundation for a more opinionated, highly automated deployment. The enterprise foundations blueprint documents the architecture, security controls, and organization policy constraints Google recommends, and organizations created after May 23, 2024 have a Google-defined security baseline enforced automatically at organization creation.
Despite the different names and services, the underlying architectural principles are consistent across all three providers: a resource hierarchy that inherits policy downward, centralized identity, centralized logging, network segmentation, and automated provisioning. An organization should choose the implementation path that matches its provider, its team's skills, and its regulatory requirements, rather than assuming any one provider's terminology applies unchanged to another.
Cloud Landing Zone Design Principles
Design for scale without needless complexity: build the hierarchy and controls the organization actually needs today, with room to grow, rather than every control a large enterprise might someday use.
Default-secure configurations: new resources should be secure by default, with insecure configurations requiring a deliberate exception rather than the reverse.
Least privilege: grant only the access a role genuinely needs, through groups rather than individual grants.
Separation of duties: no single identity should be able to both make and approve a high-risk change unchecked.
Clear workload isolation boundaries: define upfront what blast radius an account or project boundary is meant to contain.
Automation first: prefer Infrastructure as Code over console changes so environments are reproducible and auditable.
Policy as code where appropriate: express governance as enforceable rules rather than documentation alone.
Centralized visibility with delegated ownership: platform teams need cross-cutting visibility, but day-to-day workload decisions should stay with workload teams.
Auditable, traceable changes: every change to the platform should be reviewable after the fact.
Standardization with controlled exceptions: consistency is valuable, but a documented exception process keeps standardization from blocking legitimate needs.
Self-service within guardrails: workload teams should be able to provision what they need without waiting on a ticket, as long as it stays inside the guardrails.
Cost accountability from the start: tagging and ownership metadata belong in the initial design, not bolted on after spend becomes hard to explain.
Resilience: the platform layer should not itself be a single point of failure for every workload built on it.
Evolvability: the architecture should be able to absorb new technologies, such as new AI workload patterns, without a redesign.
These principles frequently trade off against each other. More centralization improves consistency but can slow workload teams down; more self-service improves speed but requires more mature automation and monitoring to stay safe. There is no universally correct balance; it depends on the organization's risk tolerance, team maturity, and regulatory context.
How to Build a Cloud Landing Zone Step by Step
Building a landing zone is a sequence of decisions, not a single deployment. The steps below describe the typical order; a specific organization may adapt or run several in parallel.
Define business and cloud-adoption objectives, including which workloads will move first and why.
Inventory regulatory, security, and operational requirements that the foundation must satisfy.
Define ownership and the operating model: who owns the platform, and who owns each workload.
Select the account, subscription, or project hierarchy that matches the organization's isolation needs.
Design identity and privileged access, including federation, roles, groups, and break-glass procedures.
Design networking and hybrid connectivity, including segmentation and on-premises connections.
Define security controls and compliance requirements, including encryption and approved regions or services.
Establish centralized logging and monitoring before any workload account is created.
Define tagging, ownership, and FinOps rules that every resource must follow.
Define shared platform services, such as DNS and secrets management foundations.
Codify the environment with Infrastructure as Code and version control.
Build automated workload onboarding so new environments are provisioned consistently.
Test controls and failure scenarios before enforcing them against real workloads.
Pilot with a small number of representative workloads before a broader rollout.
Establish an exception process for legitimate cases that fall outside the standard guardrails.
Measure outcomes and continuously improve the foundation as requirements change.
Two steps are worth emphasizing because they are the most commonly skipped: testing controls before they are enforced against production workloads, and establishing an exception process before teams start requesting exceptions informally through side channels.
Greenfield vs. Brownfield Landing Zones
Greenfield
A greenfield landing zone is built before any workload exists in the target environment. This is the easier case: the foundation can be fully standardized, controls can be enforced from day one without breaking anything already running, and there are no legacy exceptions to account for.
Brownfield
A brownfield landing zone has to accommodate an existing cloud estate. This requires a discovery phase to inventory what already exists, a policy impact analysis to understand what would break if a new guardrail were enforced immediately, and often a remediation phase before accounts or subscriptions can be restructured to fit the new hierarchy. Networking dependencies and IAM cleanup tend to be the most time-consuming parts, since existing workloads may depend on broad permissions or flat network access that a landing zone is specifically designed to eliminate.
For brownfield adoption, the practical guidance is to migrate in waves rather than attempt a disruptive, big-bang enforcement of every guardrail at once. Start by applying detective controls that surface violations without blocking anything, review what they find, remediate the highest-risk issues first, and only then move guardrails from detective to preventive enforcement.
Security and Zero Trust in a Cloud Landing Zone
NIST Special Publication 800-207 defines zero trust as a set of concepts and ideas designed to minimize uncertainty in enforcing accurate, least-privilege, per-request access decisions in information systems, on the assumption that the network cannot be treated as inherently trusted. This is a meaningfully different model from a traditional perimeter, where anything inside the corporate network was implicitly trusted.
Applied to a landing zone, zero trust principles show up as: access decisions based on identity rather than network location, explicit authentication and authorization for every request rather than an assumption of trust once inside a network boundary, least-privilege access enforced through roles rather than broad standing permissions, distinct identities for workloads and services rather than shared credentials, network segmentation that limits lateral movement, and continuous logging that supports ongoing evaluation of access rather than a one-time approval.
It is important to be precise here: deploying a landing zone does not automatically make an organization zero trust compliant. A landing zone provides the identity, network segmentation, and logging foundation that zero trust principles depend on, but zero trust also requires device posture checks, continuous policy evaluation, and application-level controls that a landing zone alone does not provide.
Networking and Connectivity in a Landing Zone
Networking decisions in a landing zone go well beyond a single virtual network. Common architectural choices include centralizing networking in a hub-and-spoke or transit design, where a central hub network handles shared connectivity, inspection, and routing, while spoke networks host individual workloads and route through the hub for anything leaving their own boundary.
IP address management: planning non-overlapping address ranges across accounts, projects, and on-premises networks before growth makes it a bigger problem.
Segmentation: separating production from non-production, and separating workloads from each other, so a compromise in one does not automatically expose another.
Ingress and egress: controlling what traffic can enter and leave the environment, often through a centralized inspection point.
DNS: providing consistent, centrally managed name resolution across every account or project.
Private connectivity: using private endpoints or private service connections instead of exposing services over the public internet where possible.
Hybrid connectivity: connecting to on-premises data centers through VPN or dedicated private connections, planned as part of the platform layer rather than per workload.
Region design: deciding which regions are approved, and planning connectivity and identity to support multi-region workloads even if none exist yet.
A centralized networking model, where the platform team owns shared connectivity and workload teams consume it, tends to give the most consistent security posture, but it can become a bottleneck if the platform team cannot keep pace with workload teams' requests. Some organizations decentralize parts of networking, such as letting workload teams manage their own subnet-level rules within a platform-provided network, as a middle ground.
Identity and Access Management in a Landing Zone
Identity is usually the layer that determines whether every other guardrail in a landing zone actually holds. The typical pattern federates identity from the organization's existing identity provider into the cloud environment, so people authenticate with the same credentials and multi-factor authentication they already use, and enables single sign-on across every account or project in the hierarchy.
Role-based access control: permissions are attached to roles and groups, not to individual users, so access can be reviewed and revoked by changing group membership.
Least privilege: roles grant only what a function needs, reducing the impact of a compromised credential.
Administrative boundaries: platform-level administrative access is separated from workload-level access, so a workload team cannot accidentally or deliberately change platform-wide policy.
Workload identities: applications and automated processes authenticate using service accounts or workload identities rather than embedded long-lived credentials, and ideally use short-lived, temporary credentials.
Privileged access management: highly sensitive administrative roles require additional approval, time-limited activation, or dedicated privileged access workflows.
Break-glass access: a documented, tightly controlled emergency access path for situations where normal federated access is unavailable.
Access reviews: periodic review of who has access to what, so permissions granted for a past project do not persist indefinitely.
Separation of human and machine identities: person accounts and service accounts follow different lifecycle and credential rules, since they have different risk profiles.
The right balance between centralizing identity administration and delegating it to workload teams varies by organization size, regulatory context, and how much the security team trusts individual workload teams to manage their own scoped permissions responsibly.
Governance, Compliance, and Policy as Code
Governance in a landing zone is built on a hierarchy: policies defined near the top of the organization structure are inherited automatically by every account, subscription, or project beneath them. This inheritance model is what allows a small platform team to govern an environment far larger than it could review manually.
Preventive controls stop a non-compliant action before it happens, such as a policy that blocks the creation of a publicly accessible storage bucket. Detective controls flag a violation after it occurs, so it can be reviewed and remediated. Mature landing zones use both: detective controls for the areas where blocking outright would be too disruptive, and preventive controls for the clearest, highest-confidence rules.
Policy as code expresses these rules as machine-readable definitions that can be version-controlled, tested, and deployed the same way application code is, rather than living only in a document nobody consistently checks. This also produces an audit trail: every change to policy is recorded, which supports compliance evidence collection.
A landing zone also typically defines naming and tagging standards, resource lifecycle rules, and a documented exception process for legitimate cases that fall outside the standard guardrails. It is worth stating directly: guardrails support compliance, they do not by themselves satisfy a framework such as ISO 27001, SOC 2, PCI DSS, or HIPAA. Those frameworks require organizational controls, evidence, and processes beyond infrastructure configuration, and confirming applicability to a specific organization is a legal and compliance question rather than an architectural one.
FinOps and Cost Governance in a Landing Zone
The FinOps Foundation defines FinOps as an operational framework and cultural practice that maximizes the business value of technology, enables timely data-driven decision-making, and creates financial accountability through collaboration between engineering, finance, and business teams. Its framework organizes the work into three continuous phases: Inform, which is about gaining visibility into who is spending what through tagging, cost allocation, and dashboards; Optimize, which uses that visibility to reduce waste and right-size resources; and Operate, which embeds cost accountability into ongoing operations.
A landing zone directly supports the Inform phase. Because the account, subscription, or project hierarchy already separates workloads and teams, and mandatory tagging requirements are enforced from the start, cost data can be allocated to the right owner without a retroactive tagging cleanup project. Budgets and alerts can be set at the account or project level, shared platform costs can be identified separately from workload costs, and an organization can move toward showback, where costs are reported to teams for visibility, or chargeback, where costs are billed to team budgets, once the underlying attribution is reliable.
A landing zone does not automatically reduce cloud spend, and this article will not attach an unsourced savings percentage to it. What it reliably does is remove the biggest obstacle to any cost optimization effort: not knowing which team, product, or workload a given dollar of spend belongs to.
Automation, DevSecOps, and Infrastructure as Code
A landing zone is meant to be operated, not just deployed once. Manual, console-driven configuration does not scale past a handful of accounts, is difficult to audit, and drifts from its intended state over time as individual changes accumulate. The alternative is declarative Infrastructure as Code: the environment's configuration is defined in version-controlled files, changes go through a pull request and review process, and a pipeline applies them consistently.
This operating model typically includes automated policy checks that run before a change is applied, reusable modules so common patterns are not rebuilt from scratch for every new environment, and a defined path for account, subscription, or project vending, where a new workload environment can be requested and provisioned automatically rather than manually. It is worth being explicit about a common point of confusion: Terraform, Bicep, or a provider's native IaC tooling can help implement a landing zone, but the tool is not the landing zone itself. The landing zone is the governed architecture; Infrastructure as Code is one of the ways that architecture gets deployed and kept consistent.
Configuration drift detection, controlled and reversible upgrades, and a clear rollback path are part of the same discipline. Without them, a landing zone can quietly diverge from its documented design until an incident or audit reveals the gap.
Hybrid and Multicloud Landing Zones
A hybrid landing zone extends the same identity, connectivity, DNS, security visibility, and logging principles across both cloud and on-premises infrastructure, so a workload does not lose governance simply because part of it runs in a data center. This typically means federating the same enterprise identity provider on both sides, extending network connectivity deliberately rather than opening broad access, and centralizing logs from both environments where practical.
A multicloud landing zone applies similar principles across more than one cloud provider, but it should not mean forcing every provider into an identical abstraction. AWS, Azure, and Google Cloud have different native constructs, different policy engines, and different identity models, described earlier in this article. Trying to make them look the same at the implementation level usually produces a lowest-common-denominator design that ignores each provider's native capabilities. A more realistic approach centralizes what is genuinely provider-agnostic, such as overarching governance principles, tagging standards, and centralized visibility through a cross-cloud monitoring tool, while letting each provider's landing zone use that provider's own native services and terminology underneath.
Multicloud also increases operational overhead. Each provider's landing zone needs its own ongoing maintenance, and the organization needs enough expertise in each provider to operate it correctly, not just to deploy it once.
Common Cloud Landing Zone Mistakes
Treating the landing zone as a one-time project instead of an operating foundation that needs ongoing ownership.
Designing excessive complexity too early, building enterprise-scale controls for an organization that does not yet need them.
Copying a vendor reference architecture without adapting it to the organization's actual requirements and risk tolerance.
Neglecting identity design, since weak identity undermines every other guardrail built on top of it.
Over-centralizing everything, which slows workload teams down and encourages them to route around the platform.
Under-governing workload teams, leaving guardrails so loose that the landing zone provides little real consistency.
Continuing manual, console-driven provisioning instead of automating environment creation.
Weak or unenforced tagging and ownership metadata, which undermines cost allocation before it starts.
Central logging that nobody actually reviews or alerts on, which provides an audit trail but no real detection capability.
Ignoring developer experience, so workload teams experience the landing zone as friction rather than a foundation that helps them move faster.
No defined exception process, which pushes legitimate exceptions into informal workarounds instead of a documented, auditable path.
Enforcing new policy against production workloads without testing it first in a detective, non-blocking mode.
Mixing platform and workload responsibilities, so it is unclear who owns a given decision.
Failing to plan for brownfield adoption, applying greenfield assumptions to an environment that already has real workloads running in it.
Assuming a landing zone automatically satisfies compliance requirements rather than supporting them.
Letting Infrastructure as Code and documentation fall out of date with what is actually deployed.
Building a landing zone with no FinOps model, so cost visibility has to be reconstructed later.
Ignoring the organization's actual operating model when designing centralization versus delegation.
How to Measure Landing Zone Maturity and Success
There is no universal, sourced benchmark for what a healthy landing zone metric looks like; the right target is organization-specific and depends on risk tolerance, regulatory context, and team size. What is useful is tracking the right qualitative and quantitative indicators over time and watching the trend rather than chasing a specific external number.
Share of environments provisioned through approved automation rather than manual console changes.
Policy compliance rate across accounts, subscriptions, or projects.
Percentage of cloud cost that is unallocated to a specific owner or cost center.
Lead time to onboard a new, approved workload environment.
Coverage of centralized logging across accounts, subscriptions, or projects.
Ownership and tagging coverage across deployed resources.
Number and age of open policy exceptions.
Coverage of privileged access reviews.
Configuration drift findings between the declared Infrastructure as Code state and the deployed environment.
Security findings that trace back to a missing or misconfigured foundational control, as opposed to an application-level issue.
A simple, practical maturity model for internal use, not an industry standard, is: Ad hoc, where environments are created manually with no consistency; Standardized, where a documented pattern exists but is not enforced; Automated, where environments are provisioned through Infrastructure as Code; Governed, where policy is enforced automatically through preventive and detective controls; and Optimized, where the organization actively measures and improves the foundation based on the indicators above.
Cloud Landing Zone Checklist
Strategy: business objectives, workload priorities, and the operating model are documented and agreed.
Organization and resource hierarchy: account, subscription, or project structure matches isolation requirements.
Identity: federation, single sign-on, role-based access, and break-glass procedures are defined.
Networking: segmentation, DNS, ingress and egress, and hybrid connectivity are designed.
Security: encryption expectations, approved regions or services, and guardrail enforcement are defined.
Governance: naming, tagging, and policy-as-code standards are documented and enforced.
Logging: centralized, access-controlled logging is in place before workload accounts are created.
Compliance: applicable frameworks and their evidence requirements are identified with legal or compliance input.
FinOps: mandatory tags, budgets, and cost-allocation ownership are defined.
Automation: Infrastructure as Code, version control, and pipelines are in place for platform changes.
Resilience: baseline backup and recovery expectations are defined at the platform level.
Operations: ownership, on-call responsibility, and change management are assigned.
Documentation: architecture decisions and their rationale are recorded and kept current.
Workload onboarding: a self-service or ticketed process exists for requesting a new environment.
Exception management: a documented, auditable process exists for requesting and approving exceptions.
When Do You Need a Cloud Landing Zone?
A landing zone earns its cost when an organization has more than one team building on the cloud, more than a handful of accounts or subscriptions, regulatory requirements that demand consistent, auditable controls, hybrid connectivity to on-premises systems, significant and growing cloud spend, or multiple business units that each need some autonomy within a shared governance model.
Indicators that the investment is justified include repeated requests to onboard new workloads, difficulty answering a basic audit question such as who has access to a given resource, and cloud spend that cannot be attributed to a specific team or product.
Conversely, a small startup running a single, low-risk workload in one account does not need enterprise-scale multi-account governance with dedicated logging and security accounts. A lightweight version, such as a single account with clear tagging, a defined identity approach, and basic centralized logging, may be entirely sufficient until the organization actually grows into a second team or a second major workload.
Example: How a Workload Uses a Landing Zone
The following is an illustrative, hypothetical scenario, not a real customer case study, meant to make the architecture concrete.
A development team needs to deploy a new customer-facing application. Instead of requesting a blank account and negotiating identity, networking, and security decisions from scratch, the team submits a request through the platform's workload onboarding process. Automation provisions a new account or project, already attached to the organization's resource hierarchy, so it inherits the platform's guardrails automatically.
Identity groups and roles for the application team are created automatically, scoped to only the new environment.
The environment is attached to the shared network according to the platform's segmentation design, with no manual firewall configuration required.
Security guardrails, such as encryption requirements and restrictions on public exposure, apply immediately without the team having to configure them.
Centralized logging begins capturing the environment's activity automatically, feeding into the platform's existing monitoring.
Required tags, including owner and cost center, are enforced as part of provisioning, so the workload's spend is attributable from day one.
The team deploys their application through their own pipeline, which deploys into the pre-provisioned environment.
The workload team owns their application's code, its specific security posture, and its reliability. The platform team owns the underlying guardrails and shared services the workload runs on top of.
The environment is continuously monitored against the platform's policies, and any drift or violation is surfaced through the existing detective controls.
The team is deploying an application, not designing a cloud foundation. That is the practical outcome a well-built landing zone is meant to produce.
The Future of Cloud Landing Zones
Landing zones are converging with the broader platform engineering movement: rather than a one-time foundational deployment, organizations increasingly treat the landing zone as the base layer of a self-service internal platform, with golden paths that let workload teams provision compliant environments without waiting on a ticket.
Policy as code and automated compliance evidence collection are becoming more central as organizations try to reduce the manual effort behind audits. Workload identity is displacing long-lived credentials as the default pattern for machine-to-machine authentication. FinOps practices are extending beyond public cloud infrastructure into software-as-a-service and, per the FinOps Foundation's own framework updates, an expanding set of technology categories. New workload types, including AI and machine learning workloads, are being folded into existing landing zone patterns rather than requiring an entirely separate foundation, which is a direct test of whether a landing zone's design was genuinely evolvable in the first place. Data residency and sovereignty requirements are also pushing some organizations toward landing zone designs that explicitly account for where data and processing must physically reside.
FAQ
The following questions cover the terms and comparisons readers most often search for alongside cloud landing zones.
What is a cloud landing zone in simple terms?
It is a ready-made, governed starting point in the cloud. Instead of every team building its own accounts, permissions, and networking from scratch, a landing zone gives everyone the same secure foundation to build on.
What is the purpose of a cloud landing zone?
Its purpose is to make cloud environments consistent, secure, and auditable from the start, so identity, networking, logging, and cost tracking do not have to be reinvented for every new workload.
What does a cloud landing zone include?
Typical components include the account or project hierarchy, identity and access management, networking, security guardrails, centralized logging, governance policy, cost and tagging rules, and the automation used to deploy and maintain all of it.
Is a landing zone the same as a VPC?
No. A VPC or VNet is a single networking construct and only one part of a landing zone's connectivity layer. A landing zone also includes identity, governance, logging, and cost management.
Is a cloud landing zone the same as a cloud foundation?
The terms largely overlap. Google Cloud explicitly describes a landing zone as also called a cloud foundation. Across the industry, the two terms are frequently used interchangeably.
What is the difference between a platform landing zone and an application landing zone?
A platform landing zone is the centralized foundation that provides governance, identity, and shared services. An application, or workload, landing zone is where a specific workload team deploys resources within the guardrails the platform provides. This split is most explicitly defined in Microsoft's Cloud Adoption Framework.
What is an AWS landing zone?
In AWS, a landing zone is a well-architected, multi-account environment built on AWS Organizations, identity federation, and a defined logging and security account structure. AWS Control Tower is the AWS-managed service that automates setting one up.
What is an Azure landing zone?
An Azure landing zone is Microsoft's proven architecture for governing and scaling a multi-subscription Azure environment, made up of a platform landing zone and one or more application landing zones, implemented through the Cloud Adoption Framework.
What is a Google Cloud landing zone?
Google Cloud describes a landing zone, also called a cloud foundation, as a modular, scalable configuration built on an organization, folders, and projects, with the enterprise foundations blueprint as a documented, Terraform-based reference implementation.
Do small companies need a cloud landing zone?
Not necessarily an enterprise-scale one. A small team with a single, low-risk workload can often start with a lightweight setup, such as one account with clear tagging and basic logging, and grow into a more formal landing zone as the number of teams and workloads increases.
Do you need a landing zone before migrating to the cloud?
It is strongly recommended for anything beyond a small, simple migration. Establishing identity, networking, and security guardrails before workloads land avoids having to retrofit governance onto an already-running environment.
Can a landing zone support multiple clouds?
Yes, but a multicloud landing zone should apply shared governance principles across providers rather than forcing every provider into an identical technical implementation, since AWS, Azure, and Google Cloud each have different native constructs.
Is Terraform a cloud landing zone?
No. Terraform is an Infrastructure as Code tool that can be used to deploy and maintain a landing zone. The landing zone is the governed architecture itself, not the tool used to build it.
How long does a cloud landing zone last?
A landing zone is not a one-time deployment with a fixed lifespan. It is meant to be maintained and evolved continuously as the organization, its workloads, and its regulatory requirements change.
Who owns a cloud landing zone?
Ownership is typically split: a platform or cloud engineering team owns the foundational guardrails, identity, and shared services, while individual workload teams own their own applications deployed within those guardrails.
Does a cloud landing zone guarantee compliance?
No. A landing zone provides security and governance guardrails that support compliance efforts, but frameworks such as ISO 27001, SOC 2, PCI DSS, or HIPAA require organizational controls and evidence beyond infrastructure configuration alone.
Key Takeaways
A cloud landing zone is a governed, repeatable cloud foundation, not a single account, network, or IaC repository.
It solves account sprawl, inconsistent identity, missing logs, and unclear cost ownership that appear once more than one team uses the cloud.
AWS, Azure, and Google Cloud each implement the same underlying idea differently: Control Tower, Azure landing zones through the Cloud Adoption Framework, and the enterprise foundations blueprint, respectively.
Identity is the layer nearly every other guardrail depends on, and it deserves the most design attention.
A landing zone does not automatically guarantee compliance or reduce cloud cost; it creates the visibility and consistency those outcomes depend on.
Brownfield adoption requires a phased, tested rollout rather than a disruptive, all-at-once enforcement of new policy.
Complexity should match organizational scale, risk, and regulatory exposure, not a generic reference architecture.
A landing zone is an operating foundation that needs continuous ownership, automation, and revision, not a one-time project.
Actionable Next Steps
Assess the current environment: inventory existing accounts, subscriptions, or projects, and the access, networking, and logging already in place.
Document requirements: gather regulatory, security, and operational needs before selecting an implementation path.
Define the operating model: decide what a platform team centralizes and what workload teams own.
Choose the resource hierarchy: design the account, subscription, or project structure that matches isolation needs.
Design identity first: federation, roles, groups, and privileged access before any other layer.
Select an implementation path for your provider, such as a managed service, an infrastructure-as-code accelerator, or a fully custom build.
Pilot with a small number of representative workloads before a broad rollout.
Automate from the start: deploy the foundation through version-controlled Infrastructure as Code rather than the console.
Establish measurement: pick a small set of maturity indicators and review them on a regular cadence.
Revisit the design periodically as the organization, its workloads, and its regulatory requirements change.
Glossary
Account — An isolation boundary for cloud resources, such as an AWS account, used to separate workloads, teams, or environments.
Application landing zone — In Azure terminology, the environment where a specific workload team deploys resources within the guardrails set by the platform landing zone.
Cloud foundation — A term, used notably by Google Cloud, that is largely synonymous with landing zone: a modular, scalable configuration that enables cloud adoption.
Cloud landing zone — A pre-configured, governed cloud environment that provides identity, networking, security, logging, and cost controls before workloads are deployed.
Control or guardrail — A preventive or detective policy that keeps resources within an approved configuration, such as blocking public storage or flagging non-compliant resources.
FinOps — An operational framework and cultural practice that creates financial accountability for cloud spend through collaboration between engineering, finance, and business teams.
Governance — The set of policies, standards, and processes that keep a cloud environment consistent and compliant as it grows.
IAM (Identity and Access Management) — The system of identities, roles, and permissions that controls who and what can access cloud resources.
Infrastructure as Code (IaC) — Defining and managing infrastructure through version-controlled configuration files instead of manual console changes.
Management group — In Azure, a container used to group subscriptions so policy and access can be managed at scale.
Organization — The top-level resource that groups accounts, subscriptions, or projects under a single administrative structure.
Organizational unit — In AWS Organizations, a grouping of accounts used to apply policy consistently to a set of accounts.
Platform landing zone — The centralized foundation that provides governance, security, identity, and shared services for every workload built on it.
Policy as code — Expressing governance rules as machine-readable, version-controlled, and enforceable definitions rather than documentation alone.
Project — In Google Cloud, the basic unit for organizing and isolating resources, billing, and permissions.
RBAC (Role-Based Access Control) — An access model that grants permissions to roles or groups rather than to individual users directly.
Shared services — Foundational capabilities, such as DNS or centralized logging, provided once at the platform level for every workload to use.
Subscription — In Azure, a billing and access-management boundary that contains resources and is grouped under a management group.
VPC (Virtual Private Cloud) — An isolated, software-defined network within a cloud provider, used to control IP addressing, routing, and segmentation.
VNet (Virtual Network) — Azure's term for a VPC: an isolated, software-defined network used to control connectivity and segmentation.
Workload — A collection of resources, code, and infrastructure that work together to deliver a specific business outcome.
Zero Trust — A security model, defined in NIST SP 800-207, that grants access based on continuous verification of identity and context rather than network location.
Sources & References
AWS Prescriptive Guidance. "Landing zone." Amazon Web Services. https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/aws-landing-zone.html
AWS Prescriptive Guidance. "Designing an AWS Control Tower landing zone," April 2025. Amazon Web Services. https://docs.aws.amazon.com/prescriptive-guidance/latest/designing-control-tower-landing-zone/introduction.html
AWS Control Tower documentation. "Plan your AWS Control Tower landing zone." Amazon Web Services. https://docs.aws.amazon.com/controltower/latest/userguide/planning-your-deployment.html
Microsoft Learn, Cloud Adoption Framework. "What is an Azure landing zone?" Microsoft. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/
Microsoft Learn, Cloud Adoption Framework. "Ready your Azure environment for workloads." Microsoft. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/
Microsoft Learn, Azure Architecture Center. "Deploy Azure Landing Zones." Microsoft. https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy
Google Cloud Architecture Center. "Landing zone design in Google Cloud." Google. https://docs.cloud.google.com/architecture/landing-zones
Google Cloud Architecture Center. "Enterprise foundations blueprint." Google. https://docs.cloud.google.com/architecture/blueprints/security-foundations
Google Cloud Architecture Center. "Decide the security for your Google Cloud landing zone." Google. https://docs.cloud.google.com/architecture/landing-zones/decide-security
National Institute of Standards and Technology. "SP 800-207, Zero Trust Architecture," 2020. NIST. https://doi.org/10.6028/NIST.SP.800-207
FinOps Foundation. "The FinOps Framework." https://www.finops.org/insights/2026-finops-framework/
