SAN vs S2D vs Azure Local: Choosing Hyper-V Storage in 2026

1. The architectures at a glance

SAN-attached Hyper-V. Classic model with separate compute and storage layers. A dedicated storage array (Dell PowerStore, HPE Alletra, NetApp AFF, Pure Storage, IBM FlashSystem, or similar) delivers block storage over Fibre Channel, iSCSI, or Shared SAS. Hyper-V hosts see the LUNs as CSVs. Compute and storage scale independently.

Storage Spaces Direct (S2D). Hyperconverged on Windows Server 2019, 2022, or 2025. Local NVMe or SSD per node, pooled across an RDMA network into shared storage. No external array required, compute and storage scale together per node.

Azure Local. Microsoft's hybrid platform (previously Azure Stack HCI), managed from Azure, licensed per physical core through an Azure subscription, and integrated with Azure services like Site Recovery and Update Manager. It started out strictly hyperconverged on S2D. Since 2026 it can also use an external SAN, next to S2D or instead of it (see section 2). See Azure Local migration readiness checklist for the full approach.

At the hardware level, the difference between S2D on Windows Server and hyperconverged Azure Local lives in the Solutions Catalog and the licensing form, not in fundamental architecture. Operationally however, they are two distinct products with distinct toolchains.

That is also why a three-way comparison no longer covers it. In 2026 you answer two questions. Where does the data live, on an array or on local disks in the nodes? And which platform runs the hosts, Windows Server or Azure Local? Every combination of the two answers now exists as a supported option.

2. What changed in 2026: Azure Local on SAN

External SAN support went into public preview in November 2025. Release 2604 (April 2026) made Fibre Channel generally available, together with SAN-only clusters. Release 2605 added iSCSI as a preview, and release 2607 (July 2026) made iSCSI generally available as well. Since May 2026 Azure Migrate can also migrate VMs to Azure Local instances that use SAN storage.

Two deployment models:

• Hybrid. A hyperconverged cluster with S2D that also mounts SAN LUNs as Cluster Shared Volumes. You register each SAN CSV as a storage path in the Azure portal and choose per VM where it lives. This can be added to a cluster that is already deployed.
• Disaggregated. No local storage pool at all, only SAN. Compute and storage scale independently, and one instance can grow from one machine to 64, well past the 16-node limit of hyperconverged Azure Local.

Supported arrays. Microsoft publishes a list of supported SAN solutions: Dell PowerStore T and Q (PowerStoreOS 3.0 or later), Everpure (formerly Pure Storage) FlashArray X, C, XL, E and RC20, the Hitachi VSP One and VSP families, HPE Alletra MP 10000, Lenovo ThinkSystem DS, DM and DG, and NetApp ONTAP systems such as AFF and ASA, all over FC or iSCSI. Dell PowerFlex is supported separately through its own software initiator. Since 2607, deployment validation of a disaggregated cluster fails on an array from an unsupported vendor. An older array that is not on the list is therefore not an Azure Local candidate, however well it runs today.

The rules that come with it:

• Block storage only, over FC or iSCSI. SAN-backed CSVs must be NTFS; ReFS is not supported on SAN volumes.
• Every LUN is presented to every node, with identical HBA configuration and zoning on all nodes. A LUN belongs to one CSV and is not shared with another cluster.
• MPIO is enabled by default from 2604, with Round Robin as the default policy, and must be configured identically on every node. Some vendors prescribe their own timer values.
• iSCSI in a hybrid cluster needs dedicated physical ports. Virtual NICs are not supported, and the iSCSI adapters stay outside Network ATC.
• Rack aware clustering is not supported in combination with external SAN on hyperconverged deployments.

The price. Azure Local now has tiered pricing. L1 covers hyperconverged clusters on local storage up to 16 nodes. L2 applies as soon as a cluster uses external SAN storage, whether hybrid or disaggregated, or a multi-rack deployment. L3 is for disconnected operations. At the list prices published in June 2026 that is 10 dollars per physical core per month for L1 and 20.10 dollars for L2. When you add SAN to an existing cluster, a 30-day trial starts, after which the whole cluster bills at L2. Discounts in your agreement change the amounts, not the ratio.

What this means for the choice. An existing SAN investment is no longer a reason to stay off Azure Local, and wanting Azure Local is no longer a reason to write off an array. Two things do not change. The array keeps its own management plane, firmware cycle and fabric, which Azure Local does not manage for you. And the host fee doubles. Azure Local on SAN pays off when you want Azure management anyway, or when you need more than 16 nodes in one instance. If the only goal is to keep using the array, Windows Server with SAN remains the cheaper route.

3. When SAN is still the right choice

SAN-attached Hyper-V gets little attention in trade press anymore, but in 2026 we treat it as the right choice for specific scenarios. None of them are exotic.

Scenario 1: existing SAN investment with years of depreciation left. A customer placed a Pure Storage FlashArray or an HPE Alletra three years ago with a seven-year depreciation. Replacing it with HCI means writing off four remaining years. The financial case for migration is typically weak in this scenario unless other drivers exist (vendor support ending, hardware defects).

Scenario 2: separate compute and storage scaling. When storage growth and compute growth do not move in sync, SAN is more flexible. A database cluster with 200 TB of storage and 12 cores per node can be sized on SAN without paying for cores you do not use. On HCI you have to add nodes that bring both compute and storage, or accept overpaying on cores.

Scenario 3: shared storage across multiple clusters. A SAN array can deliver LUNs to a Hyper-V cluster, a SQL Server failover cluster, and a fileserver cluster simultaneously. HCI is by definition storage-coupled to one cluster. For organisations with multiple small clusters sharing storage resources, SAN is operationally simpler.

Scenario 4: regulatory or compliance requirements for data location. Some compliance frameworks require physically separable storage with explicit encryption-at-rest controls at storage level. SAN arrays deliver that in mature form with decades of tooling. HCI provides comparable features but auditability is organised differently.

Scenario 5: specialised storage features HCI cannot match. Synchronous replication between sites with sub-millisecond RTO (Dell PowerStore Metro, HPE Alletra Peer Persistence), array-level snapshots with VMware VAAI-equivalent integration for Hyper-V (ODX), and array-level deduplication spanning all hosts. HCI provides software equivalents but not always with the same performance characteristics.

What SAN in 2026 does NOT do well:

• Edge deployments and small sites. A SAN for two Hyper-V nodes is operational overkill. HCI or a third option (a single shared SAS-DAS) fits better.
• Fast hardware-refresh cycles. Replacing a SAN array is a big project. Replacing HCI nodes can be done rolling.
• Cloud-native integration on plain Windows Server. A SAN-attached Windows Server cluster gets no Azure management by itself; Arc, Site Recovery and Azure Backup each have to be set up separately. Since 2026 the integrated alternative is Azure Local on the same SAN, at the L2 rate.

4. When S2D on Windows Server fits

S2D without Azure Local has a specific niche in 2026. Microsoft directs strategic investment toward Azure Local, but S2D on Windows Server 2022 or 2025 remains fully supported.

Right fit for S2D on Windows Server:

• Customer wants hyperconverged without the per-core Azure license of Azure Local. Existing Datacenter SA covers Windows Server, and S2D is included without additional OS license.
• Customer has no Azure connectivity or rejects it on principle. Strict air-gapped environments, or organisations with strong sovereignty requirements that reject Azure integration.
• Customer already manages multiple S2D clusters with existing operational expertise and sees no reason to move to a new toolchain for one new cluster.

What makes S2D on Windows Server harder in 2026:

Hardware choice is less standardised than for Azure Local. The Windows Server HCL is broader, but validation is less strict. Not every "Windows Server compatible" config is genuinely well-validated for S2D, and the consequences of a wrong choice (wear on wrong NVMe types, RDMA issues on unvalidated NICs) are painful.

We recommend customers choosing S2D on Windows Server to still buy through an OEM solution (Dell Ready Nodes for S2D, HPE Solution for Microsoft Azure Stack HCI on Windows Server, Lenovo ThinkAgile MX). That delivers the same validation properties as Azure Local without the license shift.

Microsoft's strategic focus has moved to Azure Local. Feature investments in S2D-on-Windows-Server are dropping. For customers wanting to stay on S2D long term, this is a signal to seriously consider Azure Local, even if the per-core license is initially higher.

5. When Azure Local is the right jump

Azure Local in 2026 is the recommended route for new deployments where Azure connectivity is an option, hyperconverged or, since release 2604, on a SAN. That is not the same as "always Azure Local", but the threshold for considering it is low.

Good fit for Azure Local:

• Three or more nodes, with workloads benefiting from S2D storage and software-defined networking.
• Organisation already runs other workloads in Azure, or has a hybrid strategy where Azure Arc, Site Recovery, or Backup add value.
• Central operations team managing multiple clusters through the same Azure tooling, with centralised audit trail and update management.
• Greenfield hyperconverged deployment, which stays on the L1 rate.
• An existing, supported SAN array with years of depreciation left, in an organisation that wants Azure management anyway. Azure Local on that array, hybrid or disaggregated, avoids both a write-off and a large storage migration.
• Environments that need more than 16 nodes under one instance. Disaggregated deployments on SAN go up to 64 machines.

Bad fit:

• Two-node deployments with workloads that do not justify per-core licensing. Economics work poorly below a certain scale threshold.
• Strict air-gapped or disconnected-only environments. Standard Azure Local needs Azure connectivity for billing and management. Disconnected operations exist, but require an eligible agreement, approval from Microsoft, a dedicated management cluster and the L3 tier. For most organisations that is not a realistic route.
• Customers whose array is not on the supported list, or who depend on things Azure Local does not offer on SAN, such as ReFS volumes or rack aware clustering.
• Customers who only want to keep using their SAN and see no value in Azure management. For them the L2 rate buys nothing that Windows Server does not already do.

For the full checklist specific to Azure Local, see the Azure Local migration readiness checklist article.

6. Cost comparison across the full lifecycle

Marketing comparisons between storage architectures are notoriously skewed. The table below is what we use in ClusterTriage assessments as a first-order estimate for a typical four-node Hyper-V cluster with 128 cores total and 200 TB usable storage. Numbers are relative indication, exact amounts vary widely by region and vendor. Azure Local on SAN now has its own column, because its cost profile differs from both of its parents.

Cost component	SAN-attached	S2D on WS	Azure Local (S2D)	Azure Local on SAN
OS license (Datacenter)	Included with Datacenter SA	Included with Datacenter SA	Per-core/month on top of Datacenter SA (L1)	Per-core/month at L2, about twice L1
Compute hardware (4 nodes)	Lower (no local storage)	Higher (local NVMe per node)	Higher (local NVMe per node)	Lower (catalog nodes with HBAs, little local storage)
Storage hardware	Separate, high CapEx, long lifecycle	Included in node price	Included in node price	Separate array, an existing one can be reused
Switches	2× standard datacenter switches	2× DCB-capable switches	2× DCB-capable switches	Datacenter switches plus FC fabric or iSCSI network
Software (replication, snapshots)	Often licensed on array	Included, software-defined	Included, plus Azure services	On the array, plus Azure services
Operational complexity	Higher, two management planes	Lower, one management plane	Lower, centralised through Azure	Higher, array plus Azure
Power and cooling	Higher due to array	Lower, no separate array	Lower, no separate array	Higher due to array
Azure service consumption	N/A	N/A	Material, must be modelled	Material, must be modelled

What this does not show:

• The value of existing hardware. A SAN with five more years of depreciation makes the SAN choice financially much more favourable than greenfield. HCI gives no credit for existing hardware unless you can negotiate a trade-in programme. Azure Local on SAN is now the one route that gives full credit for an existing array while moving to Azure management; the price for that is the L2 rate on every core.
• The value of operational expertise. A team that has worked with Fibre Channel and MPIO for years runs SAN operations cheaper than a team that has to learn it from scratch. The same applies in reverse for S2D and Azure Local.
• Lifecycle events. Replacing a SAN array after seven years is a project of hundreds of thousands of euros. Replacing four HCI nodes after five years is a rolling refresh distributable over a year.
• Risk costs. A SAN controller failure not absorbed by proper HA-path configuration can take a cluster down. An HCI node failure only affects the capacity of that node. Both architectures have failure modes, but the blast radius differs.

7. Performance, not just IOPS but latency profiles too

Performance comparisons between storage architectures often revolve around IOPS, but for Hyper-V workloads that is rarely the relevant metric. Latency and latency stability matter more.

SAN-attached, performance characteristics:

• Latency is consistent over time. A well-configured FC SAN delivers microsecond latency stably under load, because the SAN array is a dedicated device with dedicated cache and no workload interference.
• IOPS peak is high, especially on modern all-NVMe arrays (Pure FlashArray, Dell PowerStore, HPE Alletra MP). Millions of IOPS per array are standard.
• Latency during N-1 evacuation (one host out) is identical to steady state. The SAN does not notice a host is gone.

S2D and Azure Local, performance characteristics:

• Latency is good in steady state on all-NVMe deployments, but less consistent than SAN. Saturation of the RDMA network or NVMe wear levelling can cause latency spikes that do not occur on SAN.
• IOPS peak is high per node, but scales linearly with node count. For extreme IOPS requirements (high-transaction databases) a dedicated SAN is often still more favourable per euro.
• Latency during N-1 evacuation can rise noticeably, because remaining nodes must process more reads and writes. Plan capacity for steady state plus 30% headroom for N-1.

Where HCI clearly wins:

• Mixed read/write workloads with cache locality. S2D's NVMe tier caching works extremely well for VDI and general-purpose VM workloads. P99 latency is often better than on a SAN because write hits land directly in local NVMe.
• Workloads benefiting from data tiering. S2D automatically places frequently-accessed data on the fast tier. SAN arrays do this too, but with different algorithms and tuning requirements.

Where SAN still wins:

• Sequential I/O-heavy workloads. Large backups, file server workloads with sequential reads, and data warehouse loads often perform better on SAN, because the array has a large write cache and sequential-optimised firmware.
• Storage features at the array level. Synchronous replication with sub-millisecond RPO, array-level snapshots with VSS integration, and specific compression algorithms validated at vendor level.

8. Operational reality, what management actually demands

Each architecture has its own operational quirks. What we find in Hyper-V cluster assessments per architecture as typical findings:

SAN-attached operational reality:

• MPIO configuration often gets forgotten or set incorrectly after NIC replacement. Round Robin on an active/passive array is a classic.
• Firmware updates on the SAN array require separate change windows, separate from Hyper-V cluster patching. Two management planes, two maintenance schedules.
• Zoning (for FC) or CHAP (for iSCSI) is statically configured and maintained over years by different administrators. Documentation drift is a recurring problem.

S2D operational reality:

• Drive failures are more frequent than on SAN, simply because there are more physical drives per cluster. S2D handles this autonomously, but replacement procedures must be well documented.
• Storage Spaces health requires active monitoring. A degraded storage pool not noticed does not self-heal and can lead to data loss on a second drive failure.
• Cluster rebalancing during node maintenance can generate storage traffic that saturates the RDMA network. Schedule maintenance outside peak hours.

Azure Local operational reality:

• Two management planes: Azure Portal for primary orchestration, plus PowerShell and Failover Cluster Manager for operational tasks. Teams have to learn both.
• Azure Update Manager for patching is comfortable, but requires disciplined change management for update runs now triggered from cloud.
• Cost monitoring is a continuous activity. Azure Monitor, Log Analytics, and Defender consumption can surprise if not actively watched.

Azure Local on SAN, what we expect to find:

• Every SAN finding above still applies. MPIO, zoning and LUN presentation are just as easy to get wrong, and cluster validation still fails when one node sees a LUN differently from the others.
• Three change calendars instead of two: the monthly Azure Local solution update, the array firmware, and the FC fabric or iSCSI network. HBA drivers and firmware have to match both the Azure Local release and the array vendor's interoperability matrix.
• SAN CSVs only become visible as VM storage once someone registers them as a storage path in the Azure portal. What the array presents and what Azure knows about can drift apart.
• Two teams own one outcome. The storage team zones and masks, the platform team deploys and updates. Microsoft even advises not to zone the host WWNs until after the Azure Local deployment, so the order of work matters.

9. Migration paths between the options

Moving between architectures is not a small operation. Practical options:

• From SAN to S2D on Windows Server. Build a new S2D cluster alongside the existing SAN cluster. Migrate VMs through Live Migration (if both are in the same domain) or Hyper-V Replica followed by failover. Decommission the SAN after verification. No in-place upgrade possible.
• From SAN to Azure Local on the same array. New since 2026. Deploy Azure Local on catalog hardware with supported HBAs or NICs, present new LUNs from the existing array (a LUN belongs to one cluster, so the old and new cluster cannot share them), and migrate VMs with Azure Migrate, which supports SAN-backed Azure Local as a target since May 2026. Note that the Hyper-V source path is still in preview and only takes VMs whose disks sit on CSVs; the VMware path is generally available. Reclaim the old LUNs afterwards. No array write-off and no bulk data move to local disks.
• From SAN to hyperconverged Azure Local. Similar path to S2D, with the additional Azure Local readiness steps. See Azure Local migration readiness checklist for the full procedure.
• From S2D on Windows Server to Azure Local. From Azure Stack HCI 22H2 there is an in-place upgrade path. From S2D on Windows Server 2022 the path is more complex and we recommend building a new Azure Local cluster alongside the existing one and migrating VMs. Hardware validation against the Azure Local Solutions Catalog is a mandatory intermediate step.
• From HCI back to SAN. This happens rarely but it can. On Windows Server, build a SAN cluster and migrate VMs through Live Migration or restore. On Azure Local, attach SAN to the existing cluster and move VMs to the SAN volumes, keeping in mind that the cluster moves to the L2 rate. Arguments are usually financial (HCI cost more than expected) or operational (HCI skills proved too scarce).

What we plan as standard in all migration paths:

• Capacity modelling on the target cluster (see the VMware to Hyper-V pre-migration assessment methodology, comparable for cross-storage migrations).
• Backup strategy revalidation. Backup tooling must correctly support the target architecture, and CSV backup modes differ between SAN and S2D.
• Cutover window planning with explicit rollback criteria. No migration without a clear "when do we stop" trigger.

10. Decision matrix per scenario

Scenario	Recommended	Acceptable alternative	Avoid
New greenfield, 4+ nodes, Azure-suitable	Azure Local	S2D on WS 2025	New SAN unless specific driver
Existing cluster, SAN 3+ years of depreciation left	Keep SAN, on Windows Server	Azure Local on the same SAN if Azure management is wanted	Early replacement without business case
Two-node deployment, edge site	SAN with Shared SAS or S2D	Azure Local if per-core ok	Full HCI without validation
High-transaction database, sub-ms latency required	SAN with dedicated array, on WS or Azure Local	Azure Local with all-NVMe + RDMA	S2D on unvalidated hardware
VDI with strong read-cache benefit	S2D or Azure Local	SAN with SSD cache	Non-NVMe SAN
Mixed workload, 8+ nodes, central ops	Azure Local	Azure Local on SAN if an array is already there	A new array bought only to avoid S2D
More than 16 nodes under one management domain	Azure Local disaggregated on SAN	Several smaller clusters	One hyperconverged cluster at its limit
Disconnected / air-gapped	SAN or S2D on WS	Azure Local with disconnected operations, if approved	Standard, cloud-connected Azure Local
VMware migration, preserve SAN investment	SAN-attached Hyper-V or Azure Local on SAN	Hyperconverged Azure Local at hardware refresh	Forcing HCI without reason

The ClusterTriage storage assessment

A storage architecture assessment builds on that measured baseline. The deliverable includes a reasoned recommendation per workload group, a five-year cost model for each candidate architecture, a migration path analysis if the choice shifts, and a risk assessment of the existing infrastructure.

For customers weighing SAN retention, S2D transition, Azure Local migration, or Azure Local on their existing SAN, the assessment provides the information to make a substantiated choice. Not ideological, but fitting the specific situation.

Schedule a Hyper-V storage architecture assessment →