Azure Local Explained

Almost every customer meeting I had this year ended with the same question: “So, is Azure Local hyperconverged or not?”

It's a good question, and I understand why people ask it. Azure Local has changed quite a bit over the last couple of years: the name changed, the documentation evolved, and Microsoft introduced a new storage architecture alongside the hyperconverged model. On top of that, the hardware vendors have their own solution names and their own way of packaging it.

So if the last time you looked at this was Azure Stack HCI 23H2, some of the terminology will feel unfamiliar. Let's simplify it.

This is the first post in a series of six. Here I give you the big picture — the deep dives come later. We'll cover:

• What Azure Local actually is
• What changed in 2026
• The three storage options: hyperconverged, hyperconverged with SAN, and disaggregated
• What kind of solution you are deploying, and why that is a separate question
• Where Dell Private Cloud and the Dell Automation Platform fit
• Four questions that help you choose

What is Azure Local?

Let's forget the name for a minute. Azure Local is four things stacked on top of each other:

• Hyper-V and Failover Clustering — the same virtualization you already know, on a Windows Server 2025 based OS.
• Storage — this used to be Storage Spaces Direct. Only this part changed.
• Azure Arc — the control plane. Azure portal, Azure CLI, ARM templates, Azure Policy, Azure Monitor, Defender for Cloud.
• Billing per physical core — you pay per core, per month, on your Azure subscription.

Look at that list again and notice where the change is. The hypervisor did not change. The control plane did not change. The billing did not change.

Only the storage layer changed.

That one sentence explains most of the confusion in the market. Azure Local was never really “Microsoft's HCI product” from an engineering point of view. It was always a cloud-connected cluster that happened to ship with only one supported storage design. Since April 2026 that restriction is gone.

Is there proof of this? Yes. Microsoft now maintains two separate documentation trees on Microsoft Learn — one for hyperconverged deployments and one for disaggregated deployments. When a vendor splits its own documentation in half, something real happened.

A picture that helps

Some people need a picture before the concept sticks. I like to think about Azure Local storage like a restaurant kitchen.

Hyperconverged is a kitchen where every chef has a small fridge at their own station. Everything is close, it's fast, and you don't need a delivery boy. But if you want more fridge space you have to hire another chef, because the fridge comes with the station.

Disaggregated is a kitchen with one big cold room in the back that everybody shares. You can hire more chefs without buying more fridges. You can make the cold room bigger without hiring anybody. But now somebody has to run that cold room properly — and if the door to the cold room breaks, nobody can cook.

Keep that picture in mind. Everything below is a variation of it.

Option 1 — Hyperconverged (Storage Spaces Direct)

This is classic Azure Local and it is still fully supported.

Storage Spaces Direct (we say S2D) takes the NVMe and SSD drives inside each machine and pools them together into one shared storage space. Compute and storage grow together. If you need more storage, you add a machine. If you need more CPU, you also add a machine.

The important number here: 1 to 16 machines. That is the ceiling, and S2D is the reason for it.

Is this a problem? For most deployments, no. A shop, a factory, a branch office, a small datacenter — these almost never get close to 16 machines. For those, hyperconverged is still the right answer and probably the cheapest one.

Option 2 — Hyperconverged with a SAN attached

This one is easy to miss but very useful.

Since the 2604 release (April 2026) you can keep S2D as your main storage and attach an external SAN next to it over Fibre Channel. Since the 2607 release (July 2026) you can do the same over iSCSI.

Why would you want this? Because one workload needs something the array does well — snapshots, replication, a specific performance profile — while everything else is perfectly happy on S2D. You don't have to redesign the whole cluster for one workload.

Option 3 — Disaggregated (SAN only)

This is the new one, and it went generally available in the 2604 release.

Here there is no S2D at all. Every drive the cluster uses comes from an external SAN over Fibre Channel or iSCSI. The machines still run Hyper-V and Failover Clustering. They just don't own any storage.

And now the number that makes people sit up: 1 to 64 machines.

Four times bigger than hyperconverged. Why? Because the 16-node limit was never a Windows limit. It was an S2D limit. Take S2D out and you get the normal Windows Server failover cluster ceiling back.

If you have a customer trying to move a 30-node VMware cluster, this single number decides the whole design: three clusters or one cluster.

Now the second question: what kind of solution are you deploying?

Here is where almost everybody gets confused, including me when I first drafted this post.

Choosing the architecture and choosing the solution category are two different questions. People mix them into one list and then argue about the result.

We just covered the architecture. Now the solution category. Today there are two of them in the Azure Local Catalog:

• Integrated System — the vendor picks and tests the hardware configuration, the OS comes preinstalled, security defaults are applied, and firmware and driver updates arrive as validated packages. Microsoft and the vendor share the support queue. This is now the starting point in the catalog.
• Premier Solution — one level above. More engineering work between Microsoft and the vendor, and the validation covers the full deployment and lifecycle, not just the server. The practical difference you will feel: the Solution Builder Extension (SBE) is wired into Update Manager, so firmware and drivers come down through the same update workflow as the platform itself. On the lower level you may still be running a vendor update package by hand. The whole Dell AX System line sits in this category.

There was no big announcement, and this is exactly why it still catches people. Validated Nodes are still mentioned in some Microsoft Learn articles and in almost every blog post written before mid-2026. Those pages are simply out of date.

If you already run Validated Nodes, don't panic. They still work and you can still find them in the catalog using the qualification generation selector. Some can move up to Premier, but that means a redeployment, not an in-place upgrade. Go and check your installed base against the catalog now, calmly, before somebody makes it urgent.

Do you want proof that this is real? Cisco stopped selling Azure Local in July 2026 rather than move its products up a category. When a vendor leaves the ecosystem over this, the category is really gone.

Put this next to the 2607 change I mentioned earlier and you see one direction: Microsoft is closing the do-it-yourself paths. Unsupported SANs now fail validation instead of giving you a warning. The DIY hardware category is gone. You may like this or not, but it is the box you are designing inside.

So where does Dell Private Cloud fit?

Now we can answer this properly, and the answer is short:

Dell Private Cloud is not a fourth architecture. It is disaggregated Azure Local, delivered as a complete solution.

Same Arc control plane. Same Azure Local VMs. Same per-core billing. Same monthly release train. If you deploy it, you are running disaggregated Azure Local.

What does Dell add on top?

• PowerStore integrated as the storage, engineered and tested together with PowerEdge for compute.
• The Dell Automation Platform (DAP) — the automation layer that deploys and expands the environment from blueprints instead of you doing it by hand.
• One support boundary covering the automation, the compute, the storage and the hypervisor. One vendor to call.

What stays exactly the same

This is the part that makes customers relax, so say it out loud in your meetings. Whether you deploy S2D, S2D plus SAN, or fully disaggregated, all of this is identical:

• Same Azure portal, Azure CLI, ARM, Bicep and Terraform.
• Same Azure Local VMs and same AKS enabled by Azure Arc.
• Same PowerShell, Windows Admin Center, Hyper-V Manager and Failover Cluster Manager.
• Same security baseline with drift control, DRTM, Trusted launch and Secure Boot handling.
• Same monthly update workflow, including the offline import path.
• Same billing per physical core.
• Same connectivity rule: outbound HTTPS to Azure at least once every 30 days.

So an administrator who runs a hyperconverged cluster today does not need retraining to run a disaggregated one. The Azure side looks the same. Only the storage conversation changes.

What really changes

Now the honest half. These three things belong in your design document.

The array becomes responsible for resiliency

With S2D, resiliency is built into the platform: three-way mirror, nested resiliency on two nodes, storage fault domains the cluster understands by itself.

With disaggregated, the cluster just sees LUNs. Your RAID design, your replication, your snapshots, your MPIO, your fabric — that is where resiliency lives now.

Is that bad? No. In most enterprises the storage team already does this and does it well. That's exactly why disaggregated appeals to them. And it's exactly why it is the wrong answer for a two-node shop with no storage team at all.

Failure domains have to be designed on purpose

S2D gives you storage-aware fault domains for free. Disaggregated does not. So Microsoft gives you a replacement: rack-aware clustering (GA since the 2601 release) and, since 2607, local availability zones for disaggregated deployments, configured with PowerShell, with VM placement into those zones visible in the portal.

Validation now blocks you instead of warning you

Since 2607, deployment validation fails if your SAN vendor isn't supported, and the wizard won't even let you pick an unsupported LUN.

So check the Azure Local Catalog before you design, not after. “We'll try it and see” is no longer a path.

How to choose: four questions

Ask them in this order. The first one removes more designs than the other three together.

Quick overview

Six things people get wrong

What's next

Part 2 is coming next week. If you can, open the Azure Local Catalog while you read it and look up the hardware your customer actually has. You will remember it much better than by reading alone.

Where I got this

• What are disaggregated deployments of Azure Local — Microsoft Learn
• What's new in hyperconverged deployments of Azure Local — Microsoft Learn
• Connect an external storage array to Azure Local — Microsoft Learn
• Rack-aware clustering — Microsoft Learn
• Azure Local Catalog — aka.ms/AzureStackHCICatalog
• Cisco retires its Azure Local offering — The Register, 30 July 2026
• Explaining Azure Local licensing and hardware ecosystem changes — Microsoft Community Hub, June 2026
• Dell Private Cloud solution brief — Dell Technologies