• Intro
• What Microsoft changed
• What this means for Azure Local
• The landing zone pattern I would use
• How I would apply this in practice
• Recommendation

Intro

Microsoft recently updated the Azure landing zone guidance with a new dedicated Local management group and refreshed sovereign policies. That is good news for Azure Local governance, but it also raises a practical question: how do I fit Azure Local into an Azure landing zone design without ending up with one giant subscription full of mixed tiers and Arc-enabled VMs?

I had the same question. In this article I will walk through what changed, what the new Local management group is for, and the landing zone pattern I would use for Azure Local clusters, cluster workloads, and separate trust boundaries.

HINT I am focusing here on Azure Local specifically, not on generic Arc-enabled servers in Azure public cloud. Microsoft’s new guidance makes a distinction between the two.

What Microsoft changed

The new Azure landing zone update does two important things:

1. It adds a dedicated Local management group beneath Landing Zones.
2. It refreshes the sovereign policies in SLZ so they align to sovereign control levels 1, 2, and 3.

That gives Azure Local a clearer home in the ALZ hierarchy, and it gives sovereign workloads a more explicit policy model.

The part that matters most for Azure Local is the new Local management group. Microsoft describes it as a place for:

• Azure Local clusters and the workloads that run on top of them
• Exit-ready workloads in Azure public cloud that may later need to move to Azure Local disconnected operations

Microsoft also states that Azure Arc-enabled resources such as servers should not be dumped into the Local management group as one central bucket. Their recommendation is to keep those resources with their existing application landing zones.

I think that distinction is important. The new group is a governance scope, not a magic placement layer for every Arc resource you own.

Related reading:

• New Local Management Group for ALZ & Updated Sovereign Policies for SLZ
• Azure Local - Design the infrastructure

What this means for Azure Local

Azure Local is managed through Azure Arc, so it is easy to assume that I can treat every VM like a normal Azure resource and move it around later. That is not technically possible at this time of writing.

In my Azure Local design article I already called out a few key constraints:

• Microsoft limits me to one custom location per subscription and one custom location per Azure Local cluster
• resources cannot be moved between subscriptions or resource groups after creation

That means I need to design the Azure-side structure up front.

For Azure Local, I would separate three things:

• Governance scope — where policy and guardrails live
• Cluster boundary — where a specific Azure Local cluster is represented
• Application scope — where I place the workloads that run on the cluster

The new Local management group helps with the first point. It does not replace the other two, and it does not create a hidden tier boundary inside one Azure Local cluster.

HINT If you need hard separation between tier 0 and tier 1 workloads, do not assume one Azure Local cluster plus one management group will solve it. The subscription and cluster design still matter.

The landing zone pattern I would use

This is the pattern I would use when Azure Local must stay in a single subscription:

That gives me:

1. A shared Local governance scope for Azure Local-related policy.
2. One Azure Local subscription for the cluster and its workloads.
3. One Azure Local resource group for the cluster and workloads, which means I need to use other controls for any isolation.

If I need a hard separation boundary, I would prefer a separate Azure Local cluster rather than trying to force everything into one cluster and then split it across subscriptions or resource groups later (because it is not technically possible at this time of writing). That is the cleanest way to keep ownership, policy, and blast radius under control.

How I would apply this in practice

If I had to implement this from scratch, I would do it in this order:

1. Create or reuse the Local management group.
2. Create child management group for each Azure Local cluster and add 1 subscription beneath that scope.
3. Assign Azure Policy, RBAC, and Defender for Cloud settings at the management group level.
4. Keep the Azure Local cluster resources and workloads in the Azure Local resource group that the platform uses.
5. Use network segmentation, PIM/RBAC (ensure access is granted via PIM approval), and application-level controls to reduce lateral movement.

That pattern gives me a consistent governance layer without pretending that Azure Local is just another moveable Azure VM host.

For a single Azure Local cluster, I have not found a supported way to place tier 0 and tier 1 Azure Local VMs into different subscriptions after deployment. I would therefore treat subscription separation as off the table for this design and focus on RBAC, and network segmentation instead.

I also do not see a supported way to split those tiers into separate resource groups on the same Azure Local cluster in a way that changes the fundamental control-plane boundary. So if the design requires true separation, I would not try to solve it with RGs alone.

Recommendation

My recommendation is simple:

• use Local as the Azure Local governance anchor
• use separate clusters when the trust boundary must be hard
• use network segmentation, PIM, RBAC, and application-level controls if you must keep everything on one cluster

That keeps the design aligned with the new ALZ guidance while still respecting the practical limits of Azure Local and Azure Arc.

Final remark: The new Local management group is useful, but only if I treat it as a governance boundary and not as a place to dump all Arc-enabled resources. For Azure Local, I want my hierarchy and subscriptions designed before I deploy the cluster, not after I discover I need to separate tiers.