What is an Azure landing zone? The governed foundation, explained

Before a single workload ships, someone has to decide where it lands — and whether that place is already secure, networked and governed, or a bare field where every team reinvents the basics. A landing zone is the prepared runway. Here is what that means, where the Cloud Adoption Framework fits around it, and how to answer the question everyone hits in week one: Corp or Online?

New to cloud? CAMPUX is a free, build-first course. Start here →

The name is the whole metaphor. A plane does not touch down in a random field; it lands on a prepared strip with lights, air-traffic control and fuel already in place. An Azure landing zone is the same idea for cloud workloads: a pre-built, governed environment your applications land into, so they inherit security, networking, identity and policy from day one instead of each team bolting those on — differently, and usually worse — every time.

The definition

Microsoft's Cloud Adoption Framework puts it directly: "An Azure landing zone is the standardized and recommended approach for all organizations utilizing Azure. It provides a consistent way to set up and manage your Azure environment at scale." It gives you a "well-architected foundation aligned with core design principles across eight design areas."

Unpack that and the point is consistency at scale. One workload on Azure is easy. Fifty workloads across a dozen teams, all needing to be secure, compliant, monitored and connected — that is where things rot without a shared foundation. A landing zone is that foundation, expressed as repeatable, modular infrastructure-as-code so every subscription gets the same controls applied the same way.

Where it comes from: the Cloud Adoption Framework

The landing zone is the most concrete output of a larger body of guidance. The Cloud Adoption Framework is Microsoft's opinionated set of guidance, reference architectures and tooling for taking an organization from "we want to use Azure" to a governed, secure, well-run estate. It is not a product you buy and not a certification. It is a way of not making the expensive mistakes in a predictable order.

Here is the honest version of why it exists. It stops the thing I have watched happen at three different companies: someone spins up a subscription, deploys fast, wins a demo, and eighteen months later there are forty ungoverned subscriptions, nobody knows what is public, and the security team is finding storage accounts by accident.

One distinction to clear up first, because two Microsoft frameworks get confused constantly. The Cloud Adoption Framework is organization-scoped: it answers how a whole company gets onto Azure cleanly. The Well-Architected Framework is workload-scoped: it grades one specific application against five pillars — reliability, security, cost, operational excellence, performance. The first builds the neighbourhood; the second inspects one house. They are complementary.

The phases are not a strict waterfall. Strategy and Plan happen once up front; Ready and Adopt are where you build; Govern and Manage run forever from the day the first workload goes live. Two setup steps, two build steps, and two things that never stop. Adopt is the loud phase. Govern and Manage are the phases that keep you employed.

The eight design areas

A landing zone is not one setting; it is a set of decisions the framework groups into eight design areas you resolve up front: Azure billing and Microsoft Entra tenant; identity and access management; management group and subscription organization; network topology and connectivity; security; management, meaning monitoring and operations; governance, meaning policy and compliance; and platform automation and DevOps.

You do not have to invent these categories or wonder what you forgot — the framework hands you the checklist. Answer all eight deliberately and you have a foundation that holds up as the estate grows.

Platform vs application landing zones

This is the distinction that makes the concept click. A full landing zone is made of two kinds of zone.

• The platform landing zone holds the shared services every workload depends on — identity, connectivity and management — run by one or more central teams. In the reference architecture these are the identity, management and connectivity subscriptions. Build it once; everyone benefits.
• Application landing zones are where individual workloads live, one or more per application per environment. They are nested under management groups so they inherit Azure Policy from above. A workload team deploys into its application landing zone but cannot escape the guardrails the platform team set higher in the hierarchy.

That inheritance is the quiet magic: a new application subscription arrives already governed. It cannot be created untagged, in a forbidden region, or without logging, because policy flows down the management-group tree automatically.

A landing zone means the guardrails exist before the workload does — not as an audit finding after.

Corp vs Online: the fork everyone hits in week one

Adopt the reference architecture and you immediately meet two management groups called Corp and Online sitting under Landing Zones, with docs that assume you already know why, and a first real workload that does not obviously belong in either.

Corp and Online separate workloads by connectivity intent, not importance: Corp holds workloads that need private corporate connectivity through the hub network, Online holds internet-facing workloads that do not. Azure Policy enforces the difference. The exact policy assignments shift between releases of the reference implementation, so always check the current reference before you build.

That sentence took me an embarrassingly long time to arrive at, because the names actively mislead. "Corp" sounds like serious, business-critical, grown-up workloads, and "Online" sounds like the fun stuff, or the less important stuff. Neither is what the split means. Both groups can hold your most critical production systems. The only question the hierarchy asks is: how is this workload reached, and what does it need to reach?

• Corp means "this workload is part of the corporate network." Its virtual network peers to the hub. It resolves names through hybrid DNS. Users and systems reach it privately, over ExpressRoute or VPN from the office, or from other hub-connected workloads. It should not have public endpoints, because nothing about it is meant to be reachable from the internet. The internal ERP, the HR system, the finance data warehouse.
• Online means "this workload faces the internet and does not need the corporate network." Public endpoints are allowed because they are the whole point. No dependency on the hub, no ExpressRoute, no hybrid DNS to integrate with. The public marketing site, the customer-facing API with its own data store, the mobile-app backend.

Notice what is absent from both definitions: any statement about how much the workload matters. The public commerce API in Online might be the single most revenue-critical system the company owns. The dusty internal timesheet app in Corp might be the least. The management groups do not care. They care whether the network posture is private-and-hub-connected or public-and-standalone, because that is the axis along which the guardrails have to differ.

Corp and Online are not tiers of importance. They are two answers to the question "does this workload belong to the corporate network?"

What the policies do differently

The split is only real because policy makes it real. If Corp and Online had identical assignments they would be decorative folders. In the reference implementation the differences cluster around three network behaviours, and the policy set genuinely evolves release to release, so treat this as the shape of the difference and verify current assignments against the official documentation and the reference implementation on GitHub.

Under Corp, assignments lean toward denying public exposure — blocking public IP addresses and public endpoints on PaaS services, so the accidental exception is stopped before it ships. They require private endpoints and private DNS zones, so a Corp workload consuming a database, storage account or key vault does it privately, with records landing in the centrally managed zones that hub-connected clients resolve against. And they expect traffic to route through the hub, so egress is inspected by the central firewall and the corporate network can reach the workload.

Under Online, the shared baseline still applies in full. What it drops is the deny-public-exposure layer, because an internet-facing workload without a public endpoint is a paperweight, and there is no requirement to peer with the hub or integrate with hybrid DNS. The workload stands alone, protected by its own perimeter — a web application firewall, a front door, its own network security groups — rather than by the corporate one.

One clarification worth making loudly, because it confuses people in reviews: Online does not mean less secure. It means more exposed by design, with the exposure managed at the workload edge instead of denied by policy. An Online workload still inherits every identity, logging and security guardrail the hierarchy applies. What it must not do is quietly hold data that only ever should have been reachable privately. That is a placement error.

The decision table: where does my workload go?

When a team asks where their subscription belongs, I ask one question — who reaches this, and what does it reach? — and the answer usually falls out.

The honest row is the fifth. Plenty of real systems are consumed from both sides, and anyone who gives you a clean answer without asking follow-up questions is guessing. The pattern I reach for is to place the workload by its primary audience and then bridge the secondary audience explicitly. A public-first API lives in Online, and the internal consumer reaches it either over the public endpoint like any other client or, if the traffic must stay private, through a private endpoint projected into the corporate network. A private-first service lives in Corp, and if part of it must be public you front that specific slice with a separately placed public-facing component rather than punching a public hole in a Corp subscription. The point is not that one placement is right; it is that the cross-boundary path is designed rather than discovered.

Two mis-placements and their symptoms

You usually find out a workload is in the wrong group not from an architecture review but from a strange failure.

The Corp app that cannot reach its public dependency. A team lands an internal app in Corp, correctly it seems, and then the app needs to call an external service, pull packages, or use a PaaS service in a mode that requires a public endpoint. Policy says no. The symptom is a deployment failing with a policy-deny error, or an integration that silently cannot connect, and a team concluding "Azure is broken" when the guardrail is doing exactly what Corp promised. The fix is rarely an exemption sprayed on in a panic. It is routing egress properly through the hub firewall, using the private-endpoint version of the dependency, or admitting the component is internet-facing and belongs elsewhere.

The Online app that later needs a Corp database. The reverse is sneakier. A public app ships happily in Online, standalone as designed. Six months later a feature needs data from a system in Corp. Now you are in the cross-boundary conversation nobody planned: the Online network has no hub peering, the Corp database rightly has no public endpoint, and the quick hacks on offer — open the database publicly, or peer Online into the hub ad hoc — each quietly break the promise one of the two groups was making. The workable answers, a private endpoint projected to where the Online app can reach it, or an internal API layer in Corp called through a controlled path, all take design time. Have this conversation at placement, while it is a whiteboard exercise instead of a blocked release.

When to add your own archetypes, and when to stop

Corp and Online are archetypes, not commandments, and the reference expects you to extend them when a genuinely different policy posture appears. Sandbox already exists for that reason: experiments need looser rules and hard cost limits, and mixing them with governed workloads ruins both. The other extension that holds up in practice is a regulated archetype — a PCI or similar group for workloads carrying compliance requirements that would be oppressive applied to everything and negligent applied to nothing.

The test for adding an archetype is always the same: does this group need policy that materially differs from its siblings? If yes, it earns a box. If you are creating groups to mirror the org chart, or departments, or team names, you are building a filing cabinet rather than a governance hierarchy, and that is the most common hierarchy mistake across all three major clouds.

The honest gap: small organizations over-build this

Now the part the reference architecture will not tell you, because it was written for enterprises. The full hierarchy — Platform with three children, Landing Zones with Corp and Online, Sandbox, Decommissioned, the works — assumes an organization with a platform team, hybrid connectivity, dozens to hundreds of subscriptions, and application teams that need governing at arm's length. If that is you, the structure pays for itself.

If you are a startup or a small shop with six subscriptions, no ExpressRoute and one team that does everything, standing up the full tree is mostly ceremony. You will create a Corp group that stays empty because nothing you run is hub-connected, a hub that exists to justify the Corp group, and a review process for a boundary no workload ever crosses.

The simple version is legitimate architecture rather than a compromise to feel bad about: one Landing Zones group, a sensible policy baseline on it, maybe a Sandbox beside it. Management groups are cheap to add later, and a subscription can move into a Corp group on the day you actually acquire a corporate network for it to connect to. The skill worth practising is not reproducing the diagram; it is knowing which question each box answers, so you can tell which boxes your organization is actually asking. The hedge, stated plainly: the moment you add hybrid connectivity or a second posture of workload, revisit this. Under-building has a cost too, it just arrives later and announces itself more politely.

Why it matters for your career

"Landing zone" is one of those phrases that separates people who have only used Azure from people who have run it. Anyone can create a resource group. Understanding that workloads should drop into a pre-governed environment — with a management-group hierarchy, inherited policy, centralized identity and networking, and logging by default — is the language of platform and cloud engineering teams. When an interviewer asks how you would set up Azure for an organization rather than a hobby project, "I would start from a landing zone: a platform landing zone for shared identity, connectivity and management, and application landing zones under governing management groups so every workload inherits policy" is the answer that lands.

Do not let the enterprise-scale diagrams intimidate you. The core idea is small and durable: prepare the runway, then let workloads land on it. Everything else is the disciplined way to build and keep that runway.

Questions people also ask

What is the difference between a landing zone and a subscription?

A subscription is a billing and access boundary. A landing zone is the governed environment built on top of one or more subscriptions: management-group placement, inherited policy, identity, networking and logging already wired in. In the common reference pattern one landing zone maps to one subscription, but the landing zone is the governance, not the subscription itself.

What is the difference between a platform landing zone and an application landing zone?

The platform landing zone holds shared services every workload depends on: identity, connectivity and management, run by a central team and built once. Application landing zones are where individual workloads run, one or more per application and environment, nested under management groups so they inherit the platform team's policy automatically.

What is the difference between Corp and Online in Azure landing zones?

They are the two default workload management groups under Landing Zones, and they differ by connectivity intent. Corp is for workloads needing private corporate connectivity — networks peered to the hub, hybrid DNS, no public endpoints, reached over ExpressRoute or VPN. Online is for internet-facing workloads that do not need that connectivity: public endpoints are allowed and there is no dependency on the hub. The names describe how a workload is reached, not how much it matters to the business.

Which management group should my workload go in, Corp or Online?

Ask one question: does this workload need to be reached privately from the corporate network, or does it need private access to systems that live there? If yes — an internal ERP, an HR system, anything users hit over VPN or ExpressRoute — it goes in Corp. If it only serves the public internet and has no dependency on corporate systems, it goes in Online. If it is both, decide by primary audience and bridge the gap deliberately, usually with private endpoints, rather than letting the placement happen by accident.

Is Online less secure than Corp in an Azure landing zone?

No. Online workloads inherit the same baseline guardrails as everything else under Landing Zones. What Online relaxes is the network posture: public endpoints are permitted because the workload is meant to face the internet, so it carries fewer of the deny-public-access restrictions Corp enforces. That makes an Online workload more exposed by design, which is exactly why it should not hold private corporate data. Exposure and security level are different things.

Can I move a subscription from Online to Corp later?

Technically yes, since moving a subscription between management groups is one operation. Practically it is disruptive, because the workload immediately inherits Corp's policy set: existing public IPs and endpoints may land in non-compliance, DNS expectations change to the hub's private zones, and the app may need a peering and re-architecture of how it is reached. Treat a move as a small migration project with a compliance review first, not a drag and drop.

Do small organizations need Corp and Online management groups?

Often not. They earn their keep when you have enough subscriptions that the two connectivity postures genuinely need different policy, typically once a platform team runs a hub and multiple application teams land workloads against it. With half a dozen subscriptions, no hybrid connectivity and one team, a single Landing Zones group with a sensible policy baseline is honest architecture, and you can introduce the split later when a real second posture appears.

What is the Azure Cloud Adoption Framework?

It is Microsoft's organization-scoped guidance, reference architectures and tooling for getting a company from "we want Azure" to a governed estate, organized around six phases: Strategy, Plan, Ready, Adopt, Govern and Manage. Its most concrete output is the landing zone. It differs from the Well-Architected Framework, which is workload-scoped and grades a single application against reliability, security, cost, operational excellence and performance.

What are the design areas of an Azure landing zone?

The Cloud Adoption Framework groups landing zone decisions into eight design areas: Azure billing and Microsoft Entra tenant, identity and access management, management group and subscription organization, network topology and connectivity, security, management, governance, and platform automation and DevOps.

Is an Azure landing zone free?

The pattern itself costs nothing, and the accelerators Microsoft ships — Bicep or Terraform templates, or the portal-based option — are free to deploy. You pay only for the Azure resources the landing zone provisions, such as networking, logging and identity components, at normal Azure pricing.