For an IT team, the question is less “Which architecture is best?” than “Which resources need to grow, and which team will operate the storage?” Microsoft’s Tech Community post presents a useful decision framework. Its implementation and pricing claims still need to be read alongside Microsoft Learn’s qualification requirements and the Azure Local pricing terms.
Azure Local’s three storage architectures put different teams in charge
A hyperconverged Azure Local deployment uses Storage Spaces Direct, or S2D, to pool drives attached to the cluster’s machines. Compute and storage live in the same system. Microsoft recommends this as the straightforward integrated choice, particularly where a site does not already have a SAN and its associated storage operations team. Microsoft Learn specifies that drives used by S2D must be direct-attached, not shared SAN disks.
A disaggregated deployment uses an external storage area network, or SAN, as the cluster’s storage architecture. Separating the compute nodes from the array lets an organization add SAN capacity without buying compute simply to obtain more local disk. It also lets a team retain established array-management practices. Those advantages are most relevant when storage demand grows differently from CPU and memory demand—not merely when an organization happens to own a SAN. Microsoft documents disaggregated deployments of up to 64 nodes, subject to the applicable network and system design.
A hybrid deployment keeps S2D and attaches external SAN storage as well. Microsoft positions it for clusters whose workloads need different storage placement, or whose operators want to add external capacity without making the SAN the sole storage architecture. Here hybrid describes two storage types in one Azure Local environment; it does not mean that the SAN replaces S2D’s direct-attached drives.
| If the requirement is… | The architecture to evaluate first |
|---|---|
| One integrated compute-and-storage platform | S2D-only hyperconverged |
| SAN-backed storage without S2D as the workload-storage architecture | Disaggregated |
| Existing S2D storage alongside SAN-backed workload storage | Hybrid |
| A cluster design above 16 nodes | Disaggregated, with its network topology and hardware qualifications checked |
The last row is a design boundary, not a sizing recommendation. Microsoft describes hyperconverged systems with up to 16 machines and disaggregated systems with up to 64; a larger deployment brings its own network-pattern requirements. The node limit alone cannot establish that a particular 17-to-64-node configuration is supported.
External SAN support depends on the whole Azure Local configuration
Microsoft’s external-storage guidance describes Fibre Channel and iSCSI connectivity for qualified Azure Local configurations. It also describes SAN-backed storage for virtual machines, Azure Kubernetes Service clusters, and Azure Virtual Desktop instances. This is a supported architectural option, not permission to connect any array that speaks one of those protocols.
The supported-solutions list names Dell, Everpure, Hitachi, HPE, Lenovo, and NetApp, with qualifications that differ by product. It identifies, for example, Dell PowerStore T and Q appliances running OS 3.0 or later, HPE Alletra MP 10000, and specified Everpure FlashArray and Hitachi VSP families. NetApp directs customers to its interoperability matrix for the complete combination of Azure Local release, ONTAP version, drivers, adapters, multipathing tools, and fabric components. A vendor name on the list is not an approval of every model and firmware combination it sells.
Microsoft’s documented rules explain why qualification must cover more than the array. SAN logical unit numbers, or LUNs—the block devices presented by the array—must be visible to every cluster node, not just a subset. SAN-backed Cluster Shared Volumes, or CSVs, must use NTFS; each SAN LUN is dedicated to a single CSV, and Multipath I/O must be configured consistently across nodes. Microsoft says ReFS is unsupported for these SAN-backed volumes. A proposed design that assumes it can use an existing ReFS-formatted SAN volume unchanged therefore needs to be revised before deployment.
Protocol guidance deserves a similarly specific check. Microsoft’s supported-SAN list and external-storage setup guidance describe both Fibre Channel and iSCSI, while another Azure Local system-requirements passage describes external SAN use specifically through Fibre Channel. The practical approach is to qualify the exact release, deployment architecture, protocol, array, and host configuration together rather than infer iSCSI support for an existing installation from a general statement about Azure Local.
A SAN-backed volume still has to become usable Azure Local storage
Attaching an array is only the beginning of the workflow. Microsoft’s connection procedure applies to Azure Local release 2604 or later and separates host preparation, array-side LUN presentation, cluster validation, and workload storage-path registration. Fibre Channel requires certified host bus adapters and drivers on the nodes; iSCSI has its own network and initiator requirements. In a hybrid S2D-plus-iSCSI configuration, Microsoft specifies dedicated physical iSCSI ports rather than virtual NICs.
For Fibre Channel, Microsoft warns administrators not to zone host adapter World Wide Names to the SAN before Azure Local deployment, to avoid confusing deployment with already-visible FC LUNs. Once the cluster is deployed, array-side setup involves registering the hosts, zoning where applicable, and presenting LUNs consistently to every node. Those array operations vary by vendor; a generic PowerShell sequence cannot stand in for the qualified array configuration.
The host-side checks are concrete. Microsoft calls for verifying Multipath I/O, rescanning storage with Update-HostStorageCache, and checking with Get-Disk that every node sees the same LUNs. Disk numbers can differ between nodes, so the disk UniqueId is the useful cross-node comparison. Administrators then validate cluster storage, initialize and NTFS-format new, intended LUNs on one node, add the available disks as CSVs, and register each SAN CSV path under the cluster’s Settings > Storage path in the Azure portal. A path such as C:\ClusterStorage\Volume1 is what makes that CSV available for Azure Local VM placement.
That order has an important safety consequence: identifying the correct LUNs and confirming their visibility comes before initialization or formatting. If a disk is absent on one node, Microsoft’s troubleshooting checks start with LUN mapping, Fibre Channel zoning or iSCSI connectivity, and MPIO configuration. If cluster validation fails, resolve the reported storage issue before adding the disk as a CSV. Those checks are particularly valuable when reusing an array that already holds other systems’ data.
The Azure Local host-fee tier changes when external storage is attached
Microsoft’s September 22 guidance quotes a host service fee of $10 per physical core per month for S2D-only deployments and $20.10 per physical core per month for disaggregated or hybrid deployments using external storage. Those figures are useful as the post’s stated comparison, but Microsoft’s pricing page returned placeholder prices rather than numerical L1 and L2 rates in the available view. A purchase decision needs a current quote or a pricing-calculator result under the organization’s agreement.
The tier distinction itself is clear on Microsoft’s pricing page: hyperconverged deployments without external storage are L1; disaggregated deployments and hyperconverged deployments with external storage are L2. A team considering a hybrid expansion should therefore model a change to the host-service-fee category, not only the purchase and operation of the array. Microsoft says Azure Local billing counts physical processor cores, excludes multithreading from that count, and bills registered systems daily. The page also describes a 60-day trial after registration.
Licensing can make the gap more consequential for an eligible organization. Microsoft says Azure Hybrid Benefit can waive the L1 host service fee for qualifying Windows Server Datacenter licenses with active Software Assurance through the specified Enterprise Agreement or CSP routes. That Azure Local benefit is unavailable for L2 and L3. Guest operating-system licensing, hardware, and other applicable costs still need their own place in the comparison.
Microsoft also argues that retaining an existing array can preserve operational expertise and allow use of array services such as compression or deduplication. Those capabilities depend on the qualified product and its configuration. The post’s suggestion that separated storage and compute can make maintenance more predictable is a possible operational benefit, not a measured saving supplied with customer results. For a business case, compare the actual host fees, array costs, support arrangements, and maintenance processes on both sides.
What this means for you
Choose an architecture from workload growth and operating responsibilities first, then qualify its hardware and price before committing to a deployment. Microsoft points to ODIN for Azure Local as a way to turn workload, resiliency, and growth assumptions into an example design; its output remains a planning aid, not a support certificate.
- If you want one integrated platform and have no requirement to retain SAN storage, evaluate S2D-only hyperconverged Azure Local first.
- If SAN capacity must grow independently of compute, evaluate disaggregated Azure Local against the supported array and network patterns.
- If an existing S2D cluster needs SAN-backed workload placement, evaluate hybrid storage—and include the L2 host-fee category in the cost model.
- Before ordering or connecting equipment, confirm the Azure Local release, protocol, array model and firmware, host drivers, multipathing, and every-node LUN presentation as one qualified configuration.
- Before making a SAN LUN available to workloads, verify its identity on every node, validate cluster storage, create the required NTFS CSV, and register its storage path.
Azure Local’s storage choice is a useful expansion of the design conversation: an organization can favor an integrated cluster, preserve a qualified SAN, or run both storage types. The sound decision is the one whose workload placement, support matrix, operational ownership, and licensing cost all work together—not simply the one that makes the most use of equipment already in the rack.