What's it gonna be: Classic Hyper-V or Azure Local?Wat gaat het worden: Klassiek Hyper-V of Azure Local?

Almost every month the same question lands on the table. A customer is facing a refresh, the old cluster is written off, and someone on the team saw a Microsoft slide saying everything should move to Azure Local. “Or should we still do Azure Stack HCI?” The first thing we have to clear up is a misunderstanding, because Azure Stack HCI no longer exists.

Microsoft renamed it Azure Local in November 2024. Existing clusters moved over automatically, and Azure Arc stayed mandatory. The independent, on-prem variant that a lot of admins actually have in mind, an HCI cluster that runs without a constant connection to Azure, is off the table. What remains is a real choice: Azure Local with Arc, or a classic Hyper-V failover cluster on shared storage. And in a surprising number of cases, we recommend the second.

1. Not an anti-cloud reflex

That is not an anti-cloud reflex. We build Azure environments, we run Arc where it fits, and we have customers for whom Azure Local is exactly the right answer. But the reasons people think they need Azure Local often do not match what they actually need.

2. Start with the runtime

Start with the runtime. A Hyper-V failover cluster on a SAN runs whether the internet is up or not. No registration, no external control plane, no subscription that expires. We have seen environments where an Azure outage on the other side of the world caused no ripple in production, simply because nothing in the chain had to talk to Azure. For a hospital, a production line, or a ship at sea, that is not a detail. That is the whole business case.

3. The cost: once versus every month

Then the cost. You buy Windows Server Datacenter once, perpetually, licensed per physical core, and on that host it covers unlimited VMs. However, with Azure Local you rent: about ten dollars per physical core per month, on top of your hardware, with guest Windows licensed separately. Take two nodes of 32 cores each. That is roughly 640 dollars a month in host fees alone, before you license a single VM, and it keeps running whether you grow or stand still. We model it in every advisory round, and for stable, predictable workloads the one-time purchase often wins. Not always, but more often than the slides suggest. One honest exception, and it cuts the other way: if you already hold Software Assurance on Datacenter, Azure Hybrid Benefit can waive the Azure Local host fee, but only on a cloud-connected, Storage Spaces Direct deployment, not on a SAN and not disconnected. The buyer who wants to stay off Azure gets nothing from it.

4. Maturity and the people who know it

And maybe the most important one: maturity. Failover Clustering has been around since 2008. The pitfalls are known, the runbooks exist, and your people know the stack inside out. And you are not alone with it: there is an army of people who know Hyper-V and SAN out there. You can hire it, bring in a consultant, or search a forum and find someone who already solved your exact problem. Your storage team knows how the multipathing, the zoning, and the firmware of that SAN behave, because they have run it for years. With Azure Local you switch to a completely new update model, the so-called solution updates. On top of that come a new dependency on validated hardware from the catalog, and a far smaller pool of people who know it. All learnable, but it is a new stack with new ways to break, and you pay that bill in the first few years.

5. How long a classic cluster lasts

In our health checks we mostly see how long a classic cluster lasts. Most enterprises depreciate servers over about five years. A well-built Hyper-V cluster on a decent SAN comfortably outlives that, running six or seven years on little more than firmware updates, patch rounds, and the odd replaced disk. That is not nostalgia for the old. It is a low TCO and few surprises. We name the downside too. You do those patch rounds yourself, node by node, with Cluster-Aware Updating and your own maintenance window. Your SAN is a design choice you have to get right, because the zoning, the multipathing, and the redundancy decide your uptime, and nobody catches that centrally for you. And you get no Azure control plane showing all your sites at a glance. Anyone who genuinely needs that last part is buying something real with Azure Local.

6. The disconnected argument

About the “but it runs disconnected now” argument, because it comes up every time. We checked it again. Azure Local's disconnected operations does let you run without a cloud connection, but it does that by hosting the entire Arc control plane locally, inside a virtual appliance. So it is still Arc, all the way down. You just run Arc on your own iron. And that appliance is not free: it needs physical machines, at least three for the management instance, hundreds of gigabytes of headroom, and it is still in preview. The marquee feature, AKS, does not work in a fully air-gapped deployment yet. So if your reason for wanting offline is that you do not want the Azure operating model in the first place, disconnected Azure Local does not remove that model. It moves it into your rack and hands you the bill for running it. A classic cluster has run offline since day one, no fine print.

7. Less final than it feels

Good news for the undecided: the choice is less final than it feels. Both platforms run Hyper-V. Your guests and their VHDX files move from one to the other, so if you start classic and want Azure Local in three years, you migrate the VMs, not your whole application estate.

8. Our advice

Our advice, short. Do you want to own the infrastructure, run offline, know your costs up front, and build on a stack your team already masters? Build the Hyper-V cluster on your own SAN, and keep the control plane in your own server room. Do you want to bring Azure services and central management to your edge, and do you knowingly accept the dependence on Arc and the monthly bill? Then Azure Local is a fine choice, as long as you make it for that reason. What we want to steer you away from: do not pick Azure Local because you actually mean the old Azure Stack HCI. It is gone. The question is not new HCI or old HCI. The question is whether you want to lift your infrastructure into Azure, yes or no.

So, your turn. You are facing the next refresh. Classic Hyper-V cluster on shared storage, Azure Local with Arc, or both for different jobs? Tell us where you land, and why. We put the same question to a vote on LinkedIn. Cast yours, add your reasoning in the comments, and we will fold the best arguments from both sides into a follow-up.

Bijna elke maand komt dezelfde vraag op tafel. Een klant staat voor een refresh, het oude cluster is afgeschreven, en iemand in het team heeft op een Microsoft-slide gezien dat alles naar Azure Local moet. “Of moeten we toch nog Azure Stack HCI doen?” Dan moeten we eerst een misverstand opruimen, want Azure Stack HCI bestaat niet meer.

Microsoft hernoemde het in november 2024 tot Azure Local. Bestaande clusters zijn automatisch meegegaan, en Azure Arc bleef onverkort verplicht. De onafhankelijke, on-prem variant die veel beheerders eigenlijk in hun hoofd hebben, een HCI-cluster dat draait zonder een constante verbinding met Azure, is daarmee van tafel. Wat overblijft is een echte keuze: Azure Local met Arc, of een klassiek Hyper-V failover cluster op gedeelde storage. En in een verrassend groot deel van de gevallen adviseren wij dat tweede.

1. Geen anti-cloud-reflex

Dat is geen anti-cloud-reflex. We bouwen Azure-omgevingen, we draaien Arc waar het past, en we hebben klanten waar Azure Local precies het juiste antwoord is. Maar de redenen waarom mensen denken Azure Local nodig te hebben, kloppen lang niet altijd met wat ze daadwerkelijk nodig hebben.

2. Kijk eerst naar de runtime

Kijk eerst naar de runtime zelf. Een Hyper-V failover cluster op een SAN draait of er nu internet is of niet. Geen registratie, geen externe control plane, geen abonnement dat verloopt. We hebben omgevingen gezien waar een Azure-storing aan de andere kant van de wereld geen enkele rimpeling gaf in de productie, simpelweg omdat er in die keten niets zat dat naar Azure hoefde te praten. Voor een ziekenhuis, een productielijn of een schip op zee is dat geen detail, dat is de hele businesscase.

3. De kosten: eenmalig versus elke maand

Dan de kosten. Je koopt Windows Server Datacenter één keer, eeuwigdurend, met een licentie per fysieke core, en op die host dekt het onbeperkt VM's. Echter, bij Azure Local huur je: ongeveer tien dollar per fysieke core per maand, bovenop je hardware, en de gast-Windows licentieer je apart. Neem twee nodes van elk 32 cores. Dat is grofweg 640 dollar per maand alleen aan hostkosten, voordat je één VM licentieert, en het blijft lopen of je nu groeit of stilstaat. We rekenen het in elke adviesronde door, en bij stabiele, voorspelbare workloads wint de eenmalige aankoop vaak. Niet altijd, maar vaker dan de slides suggereren. Één eerlijke uitzondering, al snijdt die de andere kant op: heb je al Software Assurance op Datacenter, dan kan Azure Hybrid Benefit de hostfee van Azure Local kwijtschelden, maar alleen op een cloud-connected opstelling met Storage Spaces Direct, niet op een SAN en niet offline. Wie juist van Azure af wil, heeft er dus niets aan.

4. Volwassenheid en de mensen die het kennen

En misschien wel het belangrijkste: volwassenheid. Failover Clustering bestaat sinds 2008. De valkuilen zijn bekend, de runbooks liggen er, en je mensen kennen de stack tot in alle hoeken. En je staat er niet alleen voor: er is een leger aan mensen beschikbaar met kennis van Hyper-V en SAN. Je huurt het in, je haalt er een consultant bij, of je zoekt een forum af en vindt iemand die jouw probleem al heeft opgelost. Je storageteam weet hoe de multipathing, de zoning en de firmware van het SAN zich gedragen, want ze beheren het al jaren. Bij Azure Local ga je over op een compleet nieuw updatemodel, de zogenoemde solution updates. Daar komt een nieuwe afhankelijkheid van gevalideerde hardware uit de catalogus bij, en een veel beperktere groep mensen die het kent. Dat is allemaal leerbaar, maar het is wel een nieuwe stack met nieuwe manieren om stuk te gaan, en die rekening betaal je in de eerste jaren.

5. Hoe lang een klassiek cluster meegaat

In onze health checks zien we vooral hoe lang zo'n klassiek cluster meegaat. De meeste bedrijven schrijven servers in zo'n vijf jaar af. Een goed opgezet Hyper-V cluster op een fatsoenlijk SAN gaat daar comfortabel overheen, en draait zes of zeven jaar mee op niet veel meer dan firmware-updates, patchrondes en af en toe een vervangen schijf. Dat is geen romantiek voor het oude, dat is gewoon een lage TCO en weinig verrassingen. De keerzijde noemen we er eerlijk bij. Je doet die patchrondes zelf, node voor node, met Cluster-Aware Updating en je eigen onderhoudsvenster. Je SAN is een ontwerpkeuze die je goed moet maken, want de zoning, de multipathing en de redundantie bepalen je uptime, en niemand vangt dat centraal voor je op. En je krijgt geen Azure-beheervlak dat al je locaties in één oogopslag toont. Wie dat laatste echt nodig heeft, koopt met Azure Local iets reëels.

6. Het disconnected-argument

Dan het “maar het draait nu toch disconnected”-argument, want dat komt elke keer langs. We hebben het opnieuw gecheckt. De disconnected operations van Azure Local laten je inderdaad draaien zonder cloudverbinding, maar dat doen ze door de hele Arc control plane lokaal te hosten, in een virtuele appliance. Het is dus nog steeds Arc, van boven tot onder. Je draait Arc alleen op je eigen ijzer. En die appliance is niet gratis: hij vraagt fysieke machines, minstens drie voor de management-instance, honderden gigabytes ruimte, en hij is nog steeds preview. Het paradepaardje, AKS, werkt nog niet in een volledig air-gapped deployment. Dus als je reden om offline te willen is dat je het Azure-besturingsmodel sowieso niet wilt, dan haalt disconnected Azure Local dat model niet weg. Het verhuist het naar je eigen rack en geeft je de rekening om het te draaien. Een klassiek cluster draait offline sinds dag één, zonder mitsen en maren.

7. Minder definitief dan het voelt

Goed nieuws voor de twijfelaars: de keuze is minder definitief dan hij voelt. Beide platformen draaien Hyper-V. Je gasten en hun VHDX-bestanden verhuizen van het een naar het ander, dus begin je klassiek en wil je over drie jaar alsnog Azure Local, dan migreer je de VM's, niet je hele applicatielandschap.

8. Ons advies

Ons advies, kort. Wil je de infrastructuur bezitten, offline kunnen draaien, je kosten vooraf kennen en voortbouwen op een stack die je team al beheerst? Bouw dan het Hyper-V cluster op je eigen SAN, en houd het control plane in je eigen serverruimte. Wil je Azure-diensten en centraal beheer naar je edge brengen en accepteer je bewust de afhankelijkheid van Arc en de maandrekening? Dan is Azure Local een prima keuze, mits je hem om die reden maakt. Waar we je vooral voor willen behoeden: kies niet voor Azure Local omdat je eigenlijk de oude Azure Stack HCI bedoelt. Die is er niet meer. De vraag is niet het nieuwe of het oude HCI, maar wil ik mijn infrastructuur naar Azure tillen, ja of nee.

Dus, jouw beurt. Je staat voor de volgende refresh. Klassiek Hyper-V cluster op gedeelde storage, Azure Local met Arc, of allebei voor verschillende taken? Vertel ons waar je uitkomt, en waarom. We legden dezelfde vraag op LinkedIn in een poll voor. Breng je stem uit, deel je redenering in de comments, en we verwerken de sterkste argumenten van beide kanten in een vervolg.