Sovereign Cloud on Azure: Landing Zones and Azure Local

Almost every customer conversation I have lately opens with the same question: "What is sovereign cloud, and do we need it?" Usually followed by a second one: "How much control do we actually have over our own data in Azure?" Those are fair questions. Between NIS2, DORA, the EU Data Act and the public debate about where data lives and who can access it, sovereignty has moved from a nice-to-have to a board-level topic for a lot of European organizations.

The good news is that this is not a story about leaving the public cloud. It is a story about staying in control — of where your data lives, who can operate it, and how you can prove it. In this blog I want to zoom out from my previous posts on Infrastructure-as-Code and Terraform, and talk about the platform itself: how do you build an Azure environment that is sovereign and still feels like Azure? To do that, Microsoft has introduced two important building blocks: the Sovereign Landing Zone and Azure Local.

So what is "sovereign cloud", really?

When a customer asks me what sovereign cloud means, I try to avoid the marketing definition and reduce it to one sentence: sovereign cloud is about being able to prove, at any moment, that you are in control of your own data. That control has a technical side (where is the data, who holds the keys, who can read the logs) and a legal side (which laws apply, which support engineer can touch what).

Sovereign cloud is often reduced to "my data stays in Europe", but in practice it is broader than that. Microsoft describes it around four pillars, and that model works well to structure the conversation:

• Data sovereignty – where data is stored and processed, how it is encrypted, and who holds the keys.
• Operational sovereignty – who can operate the platform, from what location, and under which legal framework.
• Software sovereignty – can you run the same workloads somewhere else if you have to? Portability, open-source and hybrid runtimes.
• Assurance and compliance – proving all of the above against frameworks like GDPR, NIS2, DORA, ISO 27001, C5 or BIO.

The point is that sovereignty is not a single Azure feature you can switch on. It is a combination of region choice, identity, key management, policy, monitoring and the way you operate the platform.

The Sovereign Landing Zone (SLZ)

If you have worked with Azure Landing Zones before, the Sovereign Landing Zone will look familiar. It builds on the same Azure Landing Zone (ALZ) accelerator, but adds an extra management group with a sovereign policy initiative, sovereign guardrails and a set of reference landing zones.

What you get on top of a "regular" landing zone:

• A Sovereign Root management group that carries the sovereign policy initiative, so every subscription underneath inherits the same controls.
• A policy baseline that enforces things like: allowed regions, customer-managed keys, private endpoints only, no unmanaged disks, and Customer Lockbox enabled.
• Reference landing zones for Corp, Confidential, Online and – this is the new one – Azure Local at the edge.
• Bicep and Terraform templates in the Azure/sovereign-landing-zone repository, so you can deploy it as code (which fits nicely with what I wrote in my previous blog).

A concrete example of a sovereign guardrail in Bicep looks like this:

targetScope = 'managementGroup'

resource allowedLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'sovereign-allowed-locations'
  properties: {
    displayName: 'Sovereign - Allowed locations'
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c'
    parameters: {
      listOfAllowedLocations: {
        value: [
          'westeurope'
          'northeurope'
        ]
      }
    }
    enforcementMode: 'Default'
  }
}

Nothing exotic – it is a normal policy assignment. The value of the SLZ is that dozens of these controls are already bundled, tested and mapped to compliance frameworks, so you do not have to build the wheel yourself.

Where the Confidential landing zone fits in

The Confidential landing zone is specifically for workloads that need extra protection while the data is being processed. It defaults to Confidential VMs and Confidential AKS nodes based on AMD SEV-SNP or Intel TDX, keys in Key Vault Managed HSM, and remote attestation before a workload is allowed to start. This is the pattern I would use for workloads that fall under DORA or that process special categories of personal data.

Azure Local: sovereign compute in your own datacenter

Even with all the sovereign controls in the cloud, there are still workloads that simply cannot leave a specific building. Think of a hospital, a factory floor, a government site, or a location with limited connectivity. This is where Azure Local comes in – the product formerly known as Azure Stack HCI, rebranded and repositioned as the on-premises extension of the Azure platform.

The important thing to understand is that Azure Local is not a separate cloud. It is a validated Hyper-V based cluster (2–16 nodes on OEM-validated hardware) that is projected into Azure through Azure Arc. That means:

• The control plane is the Azure Resource Manager. You use the same RBAC, the same Policy, the same Bicep or Terraform to deploy VMs and AKS clusters – they just land on hardware in your own datacenter.
• Monitoring, Defender for Cloud and Sentinel treat the workloads like any other Azure resource.
• The data plane stays on-premises. VM disks, container volumes, and (as they become GA on Azure Local) services like SQL MI or Event Hubs never leave the building.
• You can run in disconnected mode for a limited time, which is useful for sites with intermittent connectivity or for scenarios where a temporary air-gap is required.

If you combine this with the Sovereign Landing Zone, Azure Local becomes just another landing zone under your Sovereign Root MG. The same policy initiative applies, the same tagging model applies, and the same operational model applies – only the physical location of the compute changes.

How the three pieces fit together

To me, the interesting part is not any of these building blocks on their own, but the fact that they finally fit together into one consistent story:

• Sovereign Cloud defines the why and the controls – regions, keys, operations, compliance.
• Sovereign Landing Zone delivers the how on the platform side – a repeatable, policy-driven Azure foundation.
• Azure Local extends that foundation to where the data has to physically live – on-premises or at the edge, without giving up the Azure operating model.

For most organizations I talk to, the practical path looks something like this:

1. Start with a normal Azure Landing Zone in a European region.
2. Layer the Sovereign policy initiative on top and pick your allowed regions and key strategy.
3. Add a Confidential landing zone for the workloads that need in-use protection.
4. Add an Azure Local landing zone for the workloads that genuinely cannot leave your datacenter.

That way you are not building "yet another private cloud" next to Azure – you are extending the same platform, with the same code, into the places where sovereignty demands it.

Which approach is best for you?

As with the IaC languages I wrote about earlier, there is no single right answer. If your workloads can run in a European Azure region and your legal team is comfortable with the sovereign controls in the SLZ, that is by far the simplest and cheapest path. If you have workloads that must physically stay on-premises, Azure Local is a much better option than building a separate stack, because you keep the same tooling, the same skills and the same governance.

In my next blog I want to go one level deeper and walk through deploying the Sovereign Landing Zone with Terraform, including the sovereign policy initiative and an Azure Local landing zone. If you want to already dive into the material, the best starting point is the official Microsoft Learn overview: Sovereign landing zone on Microsoft Learn.