Azure Local version 2604, released in April 2026, introduces generally available SAN support and disaggregated deployment architecture, allowing organizations to separate compute growth from storage growth for the first time on the platform. Fibre Channel SAN storage can now be attached to Azure Local clusters while preserving Azure Arc integration, Azure-native management, and the full Azure governance model. For enterprises with existing SAN investments, this release removes one of the biggest adoption barriers and creates a supported path into Azure Local without replacing storage infrastructure already serving production workloads.
This matters because many organizations need workloads to stay close to the business. Some need local performance. Some data sets need local control. Some sites need infrastructure near plants, hospitals, labs, campuses, branch offices, and field operations. Azure Local has been gaining traction with these organizations, but until now, every deployment required a fully hyperconverged storage model using Storage Spaces Direct. That model works well in many cases, yet it created friction for companies with mature Fibre Channel fabrics, multipath configurations, and storage teams with established operational practices.
The 2604 release changes that dynamic. Microsoft has made SAN support generally available after a public preview that began in November 2025, and the disaggregated model is now supported by a broad hardware partner ecosystem including HPE, Dell, and several others. Clusters can now scale beyond the previous 16-node limit into multi-rack environments spanning hundreds or thousands of nodes, addressing demand across sovereign, government, defense, and regulated environments.
For Virtuas clients, this matters.
We’ve spent years helping organizations deploy Azure Local in real operating environments. Not lab environments. Not diagram-only architectures. Real sites with existing cabling, naming standards, security requirements, VLAN constraints, procurement timelines, change windows, storage preferences, and workloads owned by different business teams. Some projects align neatly with OEM integrated systems. Others need more design work. Many need a partner willing to connect Microsoft’s platform requirements with the client’s operational reality.
That’s where Virtuas has built real depth. We understand the packaged solutions, and we also understand why packaged solutions do not always match the needs of every organization. Azure Local with SAN support gives companies another supported architecture pattern. For many of our clients, this pattern fits the way their environments already work.
Why Does Azure Local SAN Support Matter Now?
Azure Local has grown from a hyperconverged platform into a broader foundation for distributed infrastructure. Earlier designs leaned heavily on local storage through Storage Spaces Direct. That model works well for many edge and datacenter deployments, especially where simplicity, standardized hardware, and consolidated compute and storage fit the business requirement.
But many enterprises already have SAN platforms with years of investment behind them. Fibre Channel fabrics, multipath configurations, zoning standards, storage replication processes, snapshot policies, operational runbooks, and team expertise already exist. For those clients, asking every Azure Local deployment to adopt a fully hyperconverged model created friction.
The technical platform was modern. The operational fit was not always clean.
Azure Local 2604 changes this by supporting disaggregated deployments with external SAN storage. Compute nodes and storage infrastructure no longer need to grow in lockstep. A client with strong storage capacity but limited compute headroom gets a cleaner option. A company needing more compute for virtualization, Kubernetes, or AI-adjacent workloads gains room to add servers without buying storage capacity before demand warrants the spend. A regulated organization with proven SAN processes gains a path into Azure Local without discarding storage practices already reviewed by governance and audit teams.
Microsoft also confirmed that iSCSI support is on the roadmap, which will broaden the storage connectivity options beyond Fibre Channel in future releases.
The practical shift is simple: Azure Local now fits more datacenter designs without forcing a storage reset.
Infrastructure teams notice this kind of change right away. The feature matters because the release addresses real friction during planning and implementation.
What Problems Does Disaggregated Azure Local Solve?
Most Azure Local conversations start with a business driver. VMware cost pressure. Datacenter modernization. Edge resiliency. Mergers and acquisitions standardization. AI workloads near data sources. Compliance. Latency. A need for Azure-style governance across local infrastructure.
The architecture discussion follows quickly.
Storage often becomes one of the first hard decisions. With a hyperconverged design, adding capacity means thinking through the relationship among disk, memory, CPU, NICs, chassis limits, fault domains, and lifecycle requirements. That relationship has value, yet the model does not fit every use case.
We’ve seen several common challenges across Azure Local planning and deployment work.
| Client challenge | Why this has mattered | How disaggregated Azure Local helps |
|---|---|---|
| Existing SAN investments still have useful life | Organizations have already purchased enterprise storage, built support processes, and trained teams around Fibre Channel operations. | Azure Local gains a supported path for SAN storage instead of requiring a full storage platform change during modernization. |
| Compute and storage growth rarely match | Some environments need more CPU and memory long before storage grows. Others need storage expansion without another wave of compute nodes. | Compute and storage grow independently, creating a better match between spend and workload demand. |
| Datacenter teams have separate operational roles | Server, network, and storage teams often own different parts of the environment, each with approved tools and procedures. | Disaggregated architecture respects existing operational boundaries while Azure Local still provides a unified management experience through Azure Arc. |
| Migration plans need lower disruption | Replacing compute, storage, and operational procedures in one project increases risk and slows stakeholder approval. | Organizations gain a phased modernization path, especially where SAN infrastructure already meets performance and resiliency needs. |
| Large environments need more design flexibility | Multi-rack, regulated, sovereign, and enterprise-scale deployments require stronger choices around fault domains and storage architecture. | Azure Local now supports larger architectural patterns with SAN-backed storage, independent compute growth, and clusters scaling beyond 16 nodes. |
These issues sound ordinary because they are ordinary. That’s the point. Infrastructure projects succeed when the architecture respects normal operational constraints. Azure Local SAN support helps close the gap between cloud-consistent management and enterprise datacenter reality.
Why This Is Bigger Than an OEM Configuration
OEM integrated systems still matter. They reduce variables, simplify procurement, and give clients a validated starting point. We recommend them where the fit is strong. A proven appliance-style path has clear value for many companies.
But Virtuas often works with clients whose requirements do not fit neatly into a single packaged box. The environment might include a specific storage platform, a nonstandard network design, a strict physical rack layout, an existing monitoring stack, or workload placement constraints tied to business continuity plans. A packaged reference architecture helps, but the final design needs experienced engineering.
That’s where our work changes the outcome.
Virtuas approaches Azure Local as a platform, not as a SKU. We look at the client’s business drivers, workload profile, identity model, network topology, storage requirements, governance requirements, and support model. Then we design the deployment around the operating environment. The new disaggregated model gives our architects more room to make the right design decisions.
This matters most in environments where the default answer is too narrow. A client might have a validated SAN already serving mission-critical workloads. Another might need separate lifecycle planning for servers and storage arrays. Another might have internal teams with strong storage expertise and no interest in abandoning established practices. Another might need to reduce VMware dependency while preserving enterprise storage features during the migration path.
The hardware ecosystem reinforces this flexibility. Dell Technologies, Lenovo, HPE, NetApp, DataON, Hitachi Vantara, and Everpure have all released or announced validated configurations for disaggregated Azure Local deployments. Lenovo, for example, now offers compute-only ThinkAgile MX Series configurations paired with ThinkSystem storage arrays. Dell is bringing PowerStore integration for Azure Local under its Private Cloud offering. HPE has validated Alletra Storage MP B10000 for SAN-attached deployments. These are not experimental configurations. They are production-validated options backed by joint engineering with Microsoft.
Azure Local 2604 gives organizations a cleaner conversation. Instead of asking which wrapped solution fits closest, the better question becomes which Azure Local architecture best supports the business, the workloads, and the operating model.
That question is where Virtuas leads.
How Do Disaggregated Azure Local Deployments Work?
Disaggregated Azure Local separates compute from storage. The cluster uses SAN storage through Fibre Channel connectivity, while Azure Local continues to provide the Azure-connected management and operations model. Azure Local instances now support the coexistence of Storage Spaces Direct volumes and external SAN volumes, giving architects the flexibility to use SAN-only or hybrid storage topologies depending on the workload. The platform supports virtual machines, Kubernetes environments, and Azure Virtual Desktop workloads on SAN-backed storage.
Specific requirements exist around host bus adapters, zoning, LUN presentation, NTFS file system support, and multipath configuration. Those requirements deserve attention. SAN support does not remove engineering discipline. In fact, the opposite is true. A successful deployment needs careful validation across servers, HBAs, firmware, drivers, switch zoning, storage array configuration, LUN design, MPIO settings, network segmentation, Azure registration, update readiness, and operational ownership.
There is no shortcut around fundamentals.
But there is a better supported architecture now. That matters. Clients no longer need to choose between Azure Local and established Fibre Channel storage patterns in every case. The architecture has room for both.
Azure Local 2604 also introduces Local Identity with Azure Key Vault, which removes the dependency on Microsoft Active Directory for cluster provisioning. While this feature targets edge and air-gapped environments more than SAN-heavy datacenter deployments, it is part of the same release philosophy: making Azure Local fit more operational realities without forcing prerequisites that do not always exist.
For organizations modernizing from traditional virtualization platforms, this combination becomes especially useful. Many companies evaluating Azure Local also have mature SAN environments connected to VMware clusters. Moving toward Azure Local while preserving the storage layer gives project teams a more practical migration path. The company still needs planning, testing, and change control, but the design no longer requires a simultaneous compute and storage replacement by default.
How Does Virtuas Help with Azure Local SAN Deployments?
Azure Local projects reward preparation. Release notes matter, but successful deployments depend on details outside the release notes.
Virtuas helps clients turn Azure Local from a platform decision into a working environment. Our teams evaluate readiness, define architecture, validate hardware and storage alignment, plan networking, prepare identity integration, configure Azure Arc connectivity, and create repeatable deployment practices. We also help clients decide when to use a standardized OEM path and when a more custom architecture makes more sense.
The custom work matters more now. With disaggregated deployments, organizations have more options, and more options require better decisions. SAN zoning choices affect cluster stability. LUN layout affects operations. Driver and firmware alignment affects supportability. Network design affects lifecycle operations. Identity decisions affect deployment complexity. Monitoring decisions affect response quality after go-live.
Virtuas brings field experience into those decisions.
We’ve also invested in automation around Azure Local deployment workflows. Internally, we’ve built tooling and scripts to make repeatable tasks more consistent. Those automation patterns have helped reduce manual effort, improve validation discipline, and create a more predictable path across client environments. As Azure Local evolves into the new disaggregated model, we’re updating those deployment accelerators to account for SAN-backed designs, new validation steps, and the operational differences between hyperconverged and disaggregated architectures.
This is an important point. Automation should not hide complexity. Good automation exposes the right checks, enforces the right sequence, and reduces avoidable human error. SAN-backed Azure Local deployments need that mindset. A script should not replace design expertise, but a strong deployment framework helps engineering teams produce consistent outcomes across environments.
What Should Organizations Consider Before Adopting Azure Local SAN Support?
Organizations evaluating Azure Local SAN support should start with architecture, not product enthusiasm. The new model has clear benefits, but the best fit depends on workload needs and operational goals.
Clients should examine existing SAN lifecycle, Fibre Channel fabric health, storage array support status, performance requirements, rack and power constraints, Azure connectivity, data protection strategy, and the future growth curve for compute versus storage. Teams should also decide how they want to handle roles across server, storage, network, security, and cloud operations.
The strongest candidates for early planning often share a few traits. They have enterprise SAN investments with remaining value. They need Azure-consistent management for workloads staying local. They want to modernize virtualization or edge infrastructure without replacing every layer at once. They need a supported architecture for regulated, sovereign, or latency-sensitive workloads. They also value a partner able to design beyond the default appliance pattern.
That combination lines up with where Virtuas has been working for years.
A Stronger Foundation for the Next Phase of Azure Local
Azure Local SAN support is not a small storage checkbox. For many companies, this release changes the adoption path. The platform now aligns more closely with the way enterprise datacenters already operate, while preserving the Azure management model organizations want for governance, monitoring, security, and lifecycle consistency.
Our clients benefit because they gain more choice. They gain a path to preserve storage investments. They gain a way to scale compute and storage based on demand instead of forcing both to move together. They gain a better modernization pattern for complex environments where standard OEM packaging does not answer every requirement.
Virtuas is ready for this next phase. We’ve been building Azure Local practices around real deployments, real constraints, and real client outcomes. The new disaggregated model gives us more room to design the right solution, and gives our clients a stronger foundation for modern hybrid infrastructure.
Azure Local is becoming more flexible. Enterprise infrastructure needs exactly that.
Frequently Asked Questions About Azure Local SAN Support
What is Azure Local SAN support?
Azure Local SAN support allows Azure Local clusters to use external Fibre Channel SAN storage instead of relying solely on Storage Spaces Direct. This capability became generally available with the Azure Local 2604 release in April 2026, after a public preview that began in November 2025. It enables organizations to reuse existing enterprise SAN investments while gaining Azure-consistent management through Azure Arc.
What is a disaggregated deployment in Azure Local?
A disaggregated deployment separates compute and storage so they can scale independently. In previous Azure Local versions, compute and storage were tightly coupled in a hyperconverged model using Storage Spaces Direct. With disaggregated deployments in Azure Local 2604, organizations can add compute nodes without adding storage, or expand SAN capacity without buying new servers. Clusters can now scale beyond 16 nodes into multi-rack environments.
Which storage vendors support Azure Local SAN deployments?
Microsoft has announced validated SAN support from Dell Technologies, Lenovo, HPE, NetApp, DataON, Hitachi Vantara, and Everpure. These vendors offer configurations ranging from SAN-only to hybrid deployments that combine Storage Spaces Direct with external SAN volumes. Fibre Channel is the supported connectivity method in the 2604 release, with iSCSI on the roadmap for a future update.
Can Azure Local SAN support help with VMware migration?
Yes. Many organizations evaluating Azure Local as a VMware alternative already have mature SAN environments connected to their VMware clusters. Azure Local SAN support allows those organizations to preserve the storage layer during migration, reducing the scope of change. Instead of replacing compute, storage, and operational procedures simultaneously, project teams can migrate the virtualization platform while keeping existing Fibre Channel storage in place.
Does Azure Local 2604 still support Storage Spaces Direct?
Yes. Azure Local 2604 supports the coexistence of Storage Spaces Direct volumes and external SAN volumes within the same cluster. Organizations can choose a fully hyperconverged model, a fully disaggregated SAN-only model, or a hybrid approach depending on their workload requirements and infrastructure strategy.
What workloads can run on SAN-backed Azure Local clusters?
SAN-backed Azure Local clusters support virtual machines, Kubernetes environments, and Azure Virtual Desktop workloads. The SAN storage is presented to the cluster as Cluster Shared Volumes, and the Azure Arc management model applies the same way it does for hyperconverged deployments.
