A few days ago Microsoft officially renamed Azure Stack HCI to Azure Local. Since then I've been asked many times what actually changes besides the name. Judging by my projects, most customers mainly have to get used to new terminology, because the core technology and the way you manage it stay familiar. Azure integration and Arc-based management do play an even bigger role now, though.

Azure Local runs on validated hardware and is managed through Azure Arc

Azure Local is a platform that runs the Azure Local OS on Microsoft-validated hardware. The real change is that you manage everything through the Azure portal and Azure Arc. Regular virtual machines (Arc VMs), AKS clusters and Azure Virtual Desktop sessions are all deployed centrally from the cloud, even though the workloads themselves run on-prem in datacenters or branch offices. In practice that's a big step toward consistent operations: if you know Azure, you can handle edge or special on-prem requirements with the same tools. Microsoft's overview and the page on the billing model go into more technical detail.

The typical fit is anything with strict latency, data residency or compliance requirements, for example healthcare, manufacturing sites or retail. When the nearest Azure region is too far away or you can't count on reliable connectivity, Azure Local gives you modern cloud patterns and central management on-prem. If all you need is a handful of VMs in a simple setup, classic Hyper-V is still easier and cheaper. And where there are no edge requirements and you want unlimited scaling, pure Azure remains the better option.

Deployment depends on Arc and now runs through the Azure portal

Compared with a traditional Hyper-V install, the big difference is how much Azure Local relies on Azure Arc. No Arc registration and no connection to Azure means nothing works. For your first cluster you need:

  • Microsoft-validated hardware (certified OEMs like Dell, HPE, Lenovo)
  • Local Active Directory and networking for the hosts
  • An Azure subscription and permissions for Arc registration
  • Connectivity to Azure for management and billing
  • Installation media for the Azure Local OS

The whole deployment now lives in the Azure portal. Under Azure → Azure Local → Create new cluster you connect your hardware, configure the local cluster and turn on Arc management one step at a time (deployment details). Most of the old pain points, such as manual certificates and fiddly network setup, are gone. You still have to plan networking and local AD properly, especially ports, firewall rules and VPNs.

This simple diagram is what I use with customers to show how the components fit together:

flowchart TD
  User["Admin in Azure portal"] --> Arc["Azure Arc"]
  Arc --> AzureLocalOS["Azure Local OS"]
  AzureLocalOS --> VMs["Arc VMs"]
  AzureLocalOS --> AKS["AKS cluster"]
  AzureLocalOS --> AVD["Azure Virtual Desktop on Azure Local"]
  AzureLocalOS --> AD["Local Active Directory"]
  Arc --> Azure["Azure (billing, management)"]

Figure: Azure Local components and how they are managed.

Billing runs through Azure per physical core and still needs planning

Azure Local is billed only through Azure, per physical core per month, against the subscription you connect it to. Windows Server guest licensing is flexible: you can add it as an Azure add-on or bring your own volume licenses with Software Assurance. That's appealing if you run a lot of Windows Server VMs and want to move workloads freely between on-prem and the cloud. Because the billing model is transparent, you're less likely to get surprises, particularly in larger environments with several hosts.

Practical tip: Take a careful inventory of your hardware and planned workloads before rollout. More cores mean higher costs, and that adds up at scale. Check your guest OS licensing and server role assignments in advance as well, so the first invoice doesn't come as a shock.

Azure Local fits some scenarios well and others not at all

In many of the tenants I work with, Azure Local makes the most sense when you really need a bridge between the classic datacenter and the cloud: latency-sensitive apps, local data residency, or the wish to manage everything the same way through Arc. For ordinary server workloads without special requirements, classic Hyper-V or VMware is still simpler and often cheaper. On the other hand, quite a few projects that start out asking for Azure Local would be better served by pure Azure with services like Azure Virtual Desktop or AKS. You get less complexity, no hardware to worry about and practically unlimited scale. In the end it depends on location, compliance, the actual network situation and how much you're prepared to invest.

I think Azure Local has finally grown up

The rename to Azure Local makes Microsoft's direction obvious. The product is moving deep into the Azure ecosystem, and its HCI roots are fading into the background. My customers do benefit from central control and consistent management, but Azure Local is still a specialized solution. Not every small branch office needs its own hardware and Arc just because "Azure on-prem" is now an option. If you have genuine edge requirements or want to modernize your branch offices properly, though, Azure Local is now a mature platform closely aligned with the cloud, and it's worth a serious look.