Corp, Online, and Now Local

Corp. Short for corporate. "Corporate" just reminds me of Michael Scott from The Office 😂. It's an Americanism, really, usually interchangeable with "company" or "organisation" depending on where you're from.

But here we are. Corp exists, it's staying, and as of April 2026 it has a new sibling: the Local management group. Microsoft added it to the ALZ conceptual architecture. Worth understanding what they actually mean.

The Management Group Hierarchy

The ALZ Landing Zones management group has always had two child groups: Corp and Online. The new architecture adds a third, sitting alongside them.

Each group has different policy assignments, which is what actually defines their behaviour. The structure itself is just a container. It's the policies applied at each scope that make Corp feel different from Online.

Azure Landing Zone hierarchy · click to zoom

Corp (Yes, That One)

"Corp" is short for corporate network connectivity. That's it. Nothing to do with your organisation structure, nothing to do with the word "corporate" in any cultural sense. It's the management group for workloads that require private connectivity back to on-premises or to other landing zones via the hub.

If your workload needs to talk to an on-premises SQL server, hit a shared service sitting in another subscription, or route through your hub firewall, Corp is the right home. In the standard ALZ vending model, a Corp subscription gets a spoke VNet pre-created and peered back to the hub. It's ready for private traffic from day one.

From a policy perspective, Corp gets two guardrails that Online doesn't:

• Public network access should be disabled for PaaS services
• Configure Azure PaaS services to use private DNS zones

Those two policies are the actual mechanical difference between Corp and Online. Everything else, RBAC, logging, tagging, security baselines, those are applied higher up the hierarchy and land on both.

Online

Online is for workloads without the private hub connectivity requirement. There's no pre-created spoke VNet, no peering to the hub, and the PaaS privacy policies don't apply. App teams have more freedom.

That doesn't mean Online subscriptions are a free-for-all. Teams can still deploy their own VNets, private endpoints, and service endpoints. They just own those themselves rather than inheriting them from the platform. Their private DNS zones are local to the app, not linked to the central zones in the hub.

Good candidates for Online: SaaS-style workloads accessible over the internet, dev/test environments with no on-prem access requirement, and anything where the team wants to own its own network controls end-to-end.

Local (The New One)

Microsoft has added a dedicated "Local" management group, and the name refers to Azure Local, not "local" in the general sense. It sits alongside Corp and Online under Landing Zones and is designed for two distinct scenarios.

Workloads running on Azure Local clusters

The first scenario is straightforward. If you're deploying workloads directly onto Azure Local clusters, Local gives you a consistent management group scope to apply governance and security guardrails. Policies from the Azure Local product group will land here over time. There's now a clear, opinionated home for them in the hierarchy.

Exit-ready workloads in the public cloud

This is the more interesting scenario. Some customers, particularly those with sovereignty or business continuity requirements, need to know their workloads could move to Azure Local disconnected operations (ALDO) if they ever needed to. Maybe it's a regulatory requirement. Maybe it's an insurance policy against connectivity loss. Either way, they need a credible exit story.

The new Local management group supports this through a new built-in policy: Restrict resource types to Azure services supported in Azure Local disconnected operations. Run it in Audit mode to get visibility on which resource types in your subscriptions aren't available in ALDO, without changing any developer behaviour. Run it in Deny mode to actively prevent deployment of anything that would break the exit story.

Already in the ALZ Accelerator

These changes shipped in platform/alz/2026.04.2 and are already reflected in the ALZ Accelerator. New deployments via aka.ms/alz/accelerator will get the Local management group out of the box.

If you're on an existing deployment, Microsoft has published upgrade guidance for both Terraform and Bicep. The Terraform path is at Azure-Landing-Zones/terraform/howtos/update and the Bicep equivalent at the Azure Landing Zones docs site.