Azure landing zones: Corp vs Online, explained with intent

Everyone who adopts the Azure Landing Zone reference hits the same wall in week one: there are two management groups called Corp and Online sitting under Landing Zones, the docs assume you already know why, and your first real workload does not obviously belong in either. Here is the mental model that makes the split obvious — and an honest look at when you should skip it.

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

Corp and Online in an Azure landing zone 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. That said, the exact policy assignments shift between ALZ releases, so always check the current reference.

That one sentence took me an embarrassing amount of time to arrive at when I first stood up a landing zone, because the names actively mislead you. "Corp" sounds like serious, business-critical, grown-up workloads, and "Online" sounds like the fun stuff, or the less important stuff, or maybe the stuff that is merely turned on. None of that is what the split means. Both groups can hold your most critical production systems. The only question the hierarchy is asking is: how is this workload reached, and what does it need to reach?

Where Corp and Online sit, and what they inherit

Quick orientation, because the split only makes sense in context. The Azure Landing Zone reference architecture — the Cloud Adoption Framework's opinionated management-group hierarchy — puts an intermediate root group at the top, then Platform (identity, management, connectivity subscriptions run by the platform team) alongside Landing Zones (where application workloads live), plus Sandbox and Decommissioned off to the side. If that paragraph read like alphabet soup, start with management groups explained and the broader what an Azure landing zone actually is first — this article assumes the hierarchy and picks up at the fork underneath it.

Under Landing Zones, the reference ships two child groups: Corp and Online. Every subscription you place under either one inherits the full baseline that applies at Landing Zones and above — the security defaults, the monitoring and identity guardrails, the deny-the-obviously-dangerous-things policies. That part is shared. The Corp/Online split exists for the policies that cannot be shared, because they encode two opposite answers to one question about networking.

The distinction is connectivity intent, not importance

Here is the model I teach, and the one that survives contact with real workloads:

• Corp = "this workload is part of the corporate network." Its VNet 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. Think of the internal ERP, the HR system, the finance data warehouse, the line-of-business app that only employees use.
• Online = "this workload faces the internet and does not need the corporate network." Public endpoints are allowed, because they are the whole point. There is no dependency on the hub, no ExpressRoute in the picture, no hybrid DNS to integrate with. Think of 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 e-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 about one thing — whether the workload's 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 actually do differently

The split is only real because policy makes it real. If Corp and Online had identical policy assignments they would be decorative folders. In the reference implementation, the differences cluster around three network behaviors — with the caveat, which I mean sincerely, that the ALZ policy set evolves release to release. Treat the following as the shape of the difference and verify the current assignments against the official Azure Landing Zone documentation and the ALZ reference implementation on GitHub before you build.

Corp: keep it private, keep it on the hub

• Deny public network exposure where practicable. Corp assignments lean toward blocking public IP addresses and denying public endpoints on PaaS services — the intent is that nothing under Corp is reachable from the internet, and policy stops the accidental exception before it ships.
• Require private endpoints and private DNS zones. When a Corp workload consumes PaaS — a database, a storage account, a key vault — the expectation is a private endpoint, with DNS records landing in the centrally managed private DNS zones so hub-connected clients resolve the private address.
• Route through the hub. Corp VNets are expected to peer to the hub and send traffic through the central firewall or network virtual appliance, so egress is inspected and the corporate network can reach the workload.

Online: lighter network restrictions

Online is not a policy-free zone — the shared baseline still applies in full. What it drops is the deny-public-exposure layer: public IPs and public endpoints are permitted, 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 — WAF, front door, its own NSGs — rather than by the corporate one.

One clarification worth making loudly, because I have watched it confuse 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-center 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, and the next section is about those.

The decision table: where does my workload go?

When a team asks me where their subscription belongs, I ask one question — "who reaches this, and what does it reach?" — and the answer usually falls out. Here is that conversation as a table.

The honest row is the fifth one. Plenty of real systems are consumed from both sides — a product API that customers hit publicly and an internal fulfillment system also calls. There is no clean answer, and anyone who gives you one without asking follow-up questions is guessing. The pattern I reach for: place the workload by its primary audience, 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; the point is that the cross-boundary path is designed, not discovered.

Common mis-placements and their symptoms

You usually find out a workload is in the wrong group not from an architecture review but from a weird failure. Two I have seen enough times to name:

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 some external SaaS, or pull packages, or use a PaaS service in a mode that requires a public endpoint. Policy says no. The symptom is a deployment that fails with a policy-deny error, or an integration that silently cannot connect, and a team that concludes "Azure is broken" when the truth is the guardrail is doing exactly what Corp promised. The fix is rarely an exemption sprayed on in a panic; it is either routing the egress properly through the hub firewall, using the private-endpoint version of the dependency, or admitting the component is actually 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 — customer records, inventory, something private. Now you are in the cross-management-group connectivity conversation nobody planned: the Online VNet 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 for the database projected to where the Online app can reach it, or an internal API layer in Corp that the Online app calls through a controlled path — all take design time. If you can, have this conversation at placement, when 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 shows up. Sandbox already exists for exactly this reason: experiments need looser rules and hard cost limits, and mixing them in with governed workloads ruins both. The other extension I see hold up in practice is a regulated archetype — some organizations add a PCI or similarly regulated group when a set of workloads carries compliance requirements (stricter logging, tighter encryption mandates, narrower allowed regions) 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, not a governance hierarchy — the same trap exists in AWS Organizations and GCP folders, and it is the most common hierarchy mistake across all three clouds.

The honest gap: small orgs over-build this

Now the part the reference architecture will not tell you, because it was written for enterprises. The full ALZ 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 to be governed 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, not a compromise you should 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 be moved into a Corp group on the day you actually acquire a corporate network for it to connect to. The skill worth practicing is not reproducing the diagram — it is knowing which question each box answers, so you can tell which boxes your organization is actually asking. My 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.

Practice it, do not just read it

This topic rewards building more than reading. The management-group hierarchy, subscriptions, and how policy inheritance actually behaves are covered in the free class on Entra, subscriptions and management groups, and if you want to stand up the real thing, the Terraform landing zone lab has you build a scaled-honest hierarchy with your own hands — which is where the Corp/Online question stops being abstract. Both are free, as is the exam practice bank if you are pointing this at AZ-104 or AZ-305. And if you want to build it live with an instructor in the room when the policy denies something you did not expect, that is the kind of wall the live cohort exists to get you over.

Questions people also ask

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

Corp and Online are the two default workload management groups under Landing Zones in the Azure Landing Zone reference architecture, and they differ by connectivity intent. Corp is for workloads that need private corporate connectivity — VNets peered to the hub, hybrid DNS, no public endpoints, reached over ExpressRoute or VPN from the corporate network. Online is for internet-facing workloads that do not need that corporate 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 — a marketing site, a public API with its own data — it goes in Online. If it is both, decide by its 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 — the security, monitoring and identity policies apply to both. 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 that 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; Online is differently constrained, not unguarded.

Can I move a subscription from Online to Corp later?

Technically yes — 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 public endpoints may land in non-compliance, DNS expectations change to the hub's private zones, and the app may need a VNet 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. It is usually cheaper to think about connectivity intent honestly at placement time than to relocate under pressure later.

Do small organizations need Corp and Online management groups?

Often not. Corp and Online earn their keep when you have enough subscriptions that the two connectivity postures genuinely need different policy — typically at the point where a platform team runs a hub and multiple application teams land workloads against it. If you have 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. The full reference hierarchy is designed for enterprises; copying it at small scale adds ceremony, not safety.