Azure Local in 2026 and Which Tier Fits Which Workload
In this article
In short: Azure Local stopped being “Azure Stack HCI with a new name” somewhere in the past year. Microsoft now prices it in three levels: hyperconverged clusters with local storage (L1), connected datacenter platforms using external SAN or prescriptive multi-rack infrastructure (L2), and disconnected operations with a fully local control plane (L3), the foundation of Microsoft’s Sovereign Private Cloud since February 2026. L1 and L2 answer infrastructure questions about storage and scale. L3 answers a different one: whether the Azure control plane stays out of the operational dependency chain. Every level charges for what it adds in hardware, licensing, and operator time, and for most workloads the answer is still a standard Azure region.
Terms used in this article
- Hyperconverged: servers that provide compute and storage together as one cluster, with no separate storage array.
- Disaggregated: compute servers and a separate storage array, scaled independently of each other.
- SAN (storage area network): dedicated shared storage hardware, connected over Fibre Channel or iSCSI.
- Storage Spaces Direct: Microsoft's software storage layer that pools the local disks of a hyperconverged cluster.
- Multi-rack: an Azure Local architecture of several preintegrated racks (compute, storage, networking) operated as one instance.
- Control plane: the management layer used to deploy and operate the platform, distinct from where the workloads themselves run.
- Azure Arc: the Azure technology that projects machines outside Azure into Azure's management tooling.
- Management cluster: dedicated hardware in the disconnected tier that runs the local control plane and may not host business workloads.
- Air-gapped: operating with no network path to the public cloud at all.
- Azure Hybrid Benefit: using existing Windows Server licences with Software Assurance to reduce Azure charges.
Two years ago the Azure Local conversation was short. It was the successor to Azure Stack HCI, it ran VMs and AKS on validated hardware in your datacenter, it needed a regular connection to Azure, and it topped out at 16 machines per system. You considered it for branch offices and factory floors, and moved on.
That description is no longer wrong; it is incomplete. It still fits the classic product, but it misses the two directions in which Azure Local has expanded: outward into datacenter-scale, SAN-backed infrastructure, and inward into fully local control. Three changes carry most of that expansion. Disaggregated deployments lifted the old 16-machine ceiling to 64 machines per system, and multi-rack deployments push a single instance to hundreds of servers. Supported external SAN storage now attaches over Fibre Channel and iSCSI. And since February 2026, the platform can run from a locally hosted control plane inside your own boundary. Microsoft’s pricing page reflects the shift: one product has become three metering and operating levels, labelled L1, L2, and L3, and the workloads they target are the ones regulated European organisations are being asked hard questions about.
What Azure Local Became
The common thread is the Azure management model: familiar portal, CLI, ARM, RBAC, and policy experiences across the deployment types. Connected L1 and L2 systems are metered per physical core through Azure, while disconnected L3 pricing is agreed through Microsoft’s account team. In hyperconverged and disaggregated deployments, machines run a Microsoft-supplied OS from the Windows Server 2025 generation and receive a monthly solution release train (the July 2026 release is version 2607). The newer multi-rack architecture is different: its bare-metal compute machines run Azure Linux inside a prescriptive, preintegrated rack design. Hardware comes from a validated catalog of OEM solutions. Microsoft supplies the software platform and its release train, while the validated hardware, firmware, drivers, and part of the full-stack support chain remain OEM responsibilities.
A year of monthly releases turned that base into a much broader platform. Fibre Channel SAN support and disaggregated deployments, where compute and external storage scale independently, became generally available in April 2026; iSCSI followed in preview in May and reached GA with the July 2607 release. Together they lift the 16-machine ceiling to 64 machines per system, and they matter for organisations whose supported arrays were never going to be rebought as Storage Spaces Direct nodes. GPU support via full passthrough and partitioning went GA, confidential VMs on AMD SEV-SNP arrived in preview with the same July release, and Azure Migrate now moves VMware VMs to Azure Local as a GA scenario, with purpose-built RBAC roles and preview Terraform support for replication and migration. AKS runs on the platform at no extra licensing charge.
One more change is easy to miss and architecturally significant: local identity with Azure Key Vault went GA, so a cluster can be deployed and operated without an Active Directory dependency. Combined with the disconnected control plane below, the platform’s list of hard external dependencies is the shortest it has ever been.
The Three Tiers on Microsoft’s Price List
The pricing page’s tier labels are unglamorous but useful, because they map directly to architecture decisions. L1 and L2 settle infrastructure questions: local versus external storage, system scale, datacenter topology. L3 settles a different one: whether the Azure control plane itself may remain outside the operational dependency chain.
| Tier | What it is | Scale and storage | When it fits |
|---|---|---|---|
| L1 | Hyperconverged cluster, connected to Azure | Up to 16 machines, Storage Spaces Direct | Branch, factory, edge sites; the default tier |
| L2 | Disaggregated, SAN-attached, or multi-rack deployment, connected | 64 machines disaggregated; hundreds of servers multi-rack | Datacenter-scale private platforms, SAN reuse |
| L3 | Disconnected operations, local control plane | Premier Solution hardware plus a dedicated management cluster | Air-gapped, classified, and sovereign environments |
L1 is the continuation of the classic product and remains the right default for the classic scenarios: sites that need compute next to the process they serve, and workloads that must keep running when the WAN does not. That promise needs a boundary. A connected system tolerates an interruption, but it must successfully synchronise with Azure at least once every 30 consecutive days. L1 and L2 provide continuity through an outage; only L3 removes the public control plane as an ongoing dependency.
L2 now covers two quite different datacenter architectures. Disaggregated deployments separate compute from supported Fibre Channel or iSCSI storage and scale to 64 machines per system. Multi-rack deployments go further: Microsoft delivers them as prescriptive, preintegrated racks with compute, storage, and networking included, supporting hundreds of servers in one Azure Local instance. Both remain connected to Azure, both address a different class of platform than the traditional HCI cluster, and both make Azure Local a candidate for the “we are leaving VMware, but not for the public cloud” conversation that half the industry is having. The GA Azure Migrate path from VMware is aimed squarely at it.
One billing detail deserves attention before any storage design. Attaching external storage to an existing L1 cluster starts a 30-day trial and then moves the system to the L2 meter automatically. A storage architecture decision can change the software meter without anyone signing a new purchase.
L3 is the genuinely new tier. Disconnected operations puts a control plane appliance on a dedicated management cluster inside your boundary, and that appliance serves a local Azure portal, ARM, CLI, RBAC, Azure Policy, managed identities, Key Vault, and a container registry. It can operate without any dependency on the Azure public control plane, including in a fully air-gapped configuration where updates cross the boundary by manual import. Azure Local VMs are fully supported; AKS on the disconnected tier is still in preview, which is worth checking before you promise Kubernetes to an air-gapped programme. This is the infrastructure layer of Microsoft’s Sovereign Private Cloud, alongside Microsoft 365 Local for productivity and Foundry Local, a preview, by-request stack for running language models inside the same boundary.
L3 is also the only tier you cannot simply buy. Eligibility requires an approved Microsoft agreement (ordinary online pay-as-you-go subscriptions do not qualify), an active support plan, a stated business need for operating disconnected, hardware from the Premier Solutions category of the catalog, and an approval process that takes up to ten business days before you may procure it. Pricing is quoted through your account team. Microsoft is deliberately keeping this tier narrow. That gate is useful because it forces buyers to document the disconnected requirement before committing to the hardware and operating model.
The Licensing and Hardware Reality
Per-core host fees are the visible cost and the smallest surprise. Three other lines shape the real total.
Windows Server guest licensing is its own decision on top of the host fee: either bring Datacenter licences with Software Assurance through Azure Hybrid Benefit, or pay the per-core monthly subscription (currently $23.30 per physical core). On L1, Azure Hybrid Benefit can waive the host service fee entirely, which makes the software cost of a well-licensed hyperconverged cluster close to zero and explains why Microsoft can pitch it as the natural Hyper-V successor. That waiver applies to L1 only.
Hardware is CapEx from the validated catalog, and the tier choice constrains the shortlist. L3 also requires the dedicated management cluster for the control plane appliance, which is capacity you buy and operate but cannot schedule workloads on.
The minimum production footprint makes that overhead concrete. The local control plane needs a dedicated three-node cluster with at least 24 physical cores, 512 GB of RAM, and eight drives of 2 TB or more per node. Across the cluster that is 72 cores, 1.5 TB of memory, and 48 TB of raw flash before a single business workload is scheduled, and Microsoft explicitly prohibits running application workloads on that capacity. Any sizing exercise for a disconnected environment starts there, and the workload cluster comes on top.
The third line is operator time, and it dwarfs the other two in most business cases. A connected cluster consumes a monthly update train, hardware lifecycle work, and capacity management. A disconnected environment adds update imports across the boundary, certificate and PKI management, identity integration, and the full responsibility for everything a cloud provider’s operations team normally absorbs. Teams that run Azure Local well tend to already run virtualisation platforms well. Teams hoping the Azure branding means the platform runs itself are reading the label instead of the contents.
When Azure Local Earns Its Place
Workloads that belong on the platform have a shape: they need to be where the data or the process is, and they carry a reason connectivity or regulation rules out a region.
Latency-bound and continuity-bound site workloads are the L1 core. Manufacturing execution, warehouse logistics, retail systems that must sell groceries during a WAN outage, local AI inference on camera streams. These were always the honest scenarios and they still are.
VMware refresh projects are the L2 case with commercial momentum. An organisation with a large virtualised environment, a licensing bill that changed shape, and no appetite for a full cloud migration gets an Arc-governed platform, a GA migration path, and a storage story that reuses a supported SAN investment. It is a defensible destination, provided the team prices the operating model honestly against the alternative of finally doing the migration.
Sovereign and air-gapped workloads are the L3 case: defence and intelligence, critical-infrastructure OT, and data that regulation or risk appetite keeps off any public cloud, including the sovereign public offerings. For these, a local control plane with Azure’s management surface is a real capability that did not exist in GA form before this year.
When a Standard Azure Region Still Wins
Everything elastic, everything PaaS-heavy, and everything without an infrastructure team stays in the region. Azure Local runs VMs and AKS; it does not reproduce a region’s managed-service portfolio. Service Bus and Cosmos DB do not appear locally, and Foundry Local is a separate preview stack with a curated local model catalog and its own Kubernetes-based operating model rather than the complete hosted Foundry service transplanted into your datacenter. Workloads built on managed services would have to be rebuilt poorer to move. Capacity you own is capacity you paid for whether you use it or not, so burst patterns price badly on-premises. And the operating responsibility is real: if the honest answer to “who patches the platform” is nobody, the workload belongs in a region regardless of how the sovereignty discussion feels.
The subtler trap is sovereignty theatre. A disconnected control plane keeps data, operations, and management inside your boundary, and for a defined class of workloads that is exactly what the regulator or the threat model demands. It does not change who writes the software, who signs the updates you import, or whose commercial terms govern the platform. Disconnected operations is a placement option with a specific risk profile rather than a sovereignty verdict, and it earns its cost only for workloads whose classification actually lands in that narrow top band. Classify first; most organisations that run the exercise honestly place far fewer workloads there than the sovereignty discussion assumed.
Where This Leaves Architects
Treat the tiers as three different decisions that share an operating model. L1 is a site-infrastructure decision and the natural Hyper-V successor, cheap to license if your Windows Server agreements are in order. L2 is a datacenter-platform decision that competes with both VMware renewal and cloud migration, and deserves a business case that includes operator headcount. L3 is a sovereignty instrument with an eligibility gate, a hardware overhead, and a services subset, justified by the workloads that genuinely cannot live anywhere else.
The placement exercise feeds the decisions around it: workload classification tells you which tier a workload may use, AKS in 2026 covers the Kubernetes layer that runs on top, and your landing zone design determines how Arc-connected machines are governed next to everything else. Azure Local in 2026 is a serious platform with three honest use cases. The discipline is saying no to the workloads that do not have one.
Technical details verified against Microsoft’s Azure Local documentation and pricing pages on 3 August 2026.
Related: Cloud Sovereignty in 2026 and Why It Is a Workload Classification Problem the classification that decides tier eligibility · AKS in 2026 and When It Still Wins the Kubernetes layer on top · Azure Landing Zones in 2026 and What Actually Matters Now governing hybrid alongside cloud · Shared vs Separate Azure Hubs Under NIS2 and DORA the regulated-hub pattern
Looking for Azure architecture guidance?
We design and build Azure foundations that scale - landing zones, networking, identity, and governance tailored to your organisation.
