Microsoft ha rilasciato Azure Local 2604 (build 12.2604.1003.209, aprile 2026) e, per una volta, non siamo davanti alla solita release incrementale.
Questa versione segna un cambio di direzione piuttosto netto. Non introduce breaking change, ma porta in General Availability alcune funzionalità che, messe insieme, modificano profondamente il modo in cui Azure Local può essere progettato e adottato.
Le tre più rilevanti sono:
- Supporto SAN
- GPU acceleration
- Local Identity con Key Vault
A queste si aggiunge un quarto elemento, i deployment disaggregati, che, più di ogni altra cosa, cambia il modello architetturale della piattaforma.
Da piattaforma edge a piattaforma datacenter
Per capire davvero il peso di questa release bisogna ricordare da dove si partiva.
Azure Local (e prima Azure Stack HCI) è sempre stato fortemente “opinato”: hyperconverged, Storage Spaces Direct, modello chiuso e coerente con il cloud.
Una scelta che funzionava molto bene per edge e scenari controllati, ma che nel tempo ha escluso una parte importante del mondo enterprise, soprattutto chi ha investimenti significativi in SAN.
Con l’update 2604 questa barriera cade.
Azure Local non è più solo una piattaforma edge: entra esplicitamente nel territorio del datacenter enterprise
SAN support: apertura attesa da anni
Come anticipato, la novità più evidente è la GA del supporto SAN.
È ora possibile collegare storage Fibre Channel e utilizzarlo insieme a Storage Spaces Direct oppure come layer principale.
Dal punto di vista dei workload cambia poco: i volumi vengono esposti come Cluster Shared Volumes (CSV) e il comportamento resta familiare.
Dal punto di vista architetturale, invece, cambia molto.
Per la prima volta Azure Local permette di non toccare lo storage esistente durante una migrazione.
Questo ha un impatto diretto su due aspetti:
- economico → niente refresh completo del datacenter
- organizzativo → storage e virtualization team possono restare separati
Detto questo, non è ancora una soluzione “universale”. Il supporto è limitato al Fibre Channel e alcune funzionalità, come il rack-aware clustering in scenari hyperconverged con SAN esterno, non sono disponibili.
Deployment disaggregati: il vero cambio di paradigma
Se il SAN support apre una porta, i deployment disaggregati la spalancano.
Con 2604 è possibile fare deploy in modalità SAN-only, senza Storage Spaces Direct, e scalare compute e storage in modo indipendente. Inoltre, il limite dei 16 nodi viene superato, arrivando fino a 64.
Qui però il cambiamento non è solo quantitativo, ma qualitativo.
Il modello di rete passa a un’architettura tipica da datacenter moderno:
- fabric leaf-spine
- overlay VXLAN EVPN
- underlay eBGP
Questo non è più il mondo edge “semplice” a cui Azure Local ci aveva abituati, è un’infrastruttura a tutti gli effetti enterprise.
Ed è qui che entra una riflessione importante: la piattaforma guadagna flessibilità, ma perde parte della semplicità che ne era uno dei punti di forza. Non è necessariamente un problema, ma è una transizione che va capita e gestita.
GPU acceleration: AI all’edge senza compromessi
Un altro tassello fondamentale è la General Availability della GPU acceleration.
Azure Local supporta ora in produzione:
- GPU dedicate (DDA)
- GPU partizionate (GPU-P)
E soprattutto permette di gestirle anche come operazioni Day-2, quindi senza dover ricreare le VM.
La GPU-P è probabilmente la parte più interessante. Permette di condividere una singola GPU tra più macchine virtuali, rendendo sostenibili scenari di inferenza AI anche in ambienti edge.
Tradotto in pratica: puoi portare capacità di AI locale senza dover dedicare una GPU per ogni workload.
Local Identity con Key Vault: utile, ma non per tutti
La Local Identity con Azure Key Vault arriva in GA ed è pensata per scenari specifici:
- ambienti senza Active Directory
- contesti regolamentati
- deployment isolati o disconnected
Funziona con autenticazione basata su certificati e utilizza Key Vault per il backup sicuro dei secret.
È una funzionalità importante, ma non è il nuovo default. Se Active Directory è già presente e funzionante, resta la scelta più semplice e gestibile.
Deploy e validation: il miglioramento che si sente davvero
Tra tutte le novità, quella che ha più impatto nel quotidiano è meno “visibile”:
- deploy fino al 40% più veloce
- validation fino al 50% più veloce
- possibilità di riprendere la validation dal punto di errore
Quest’ultimo punto cambia completamente l’esperienza operativa: prima, un errore verso la fine della validation significava ripartire da zero.
Ora si può riprendere da dove si era interrotto (entro una finestra di tre ore).
Questo rende i tempi di deploy molto più prevedibili e riduce drasticamente i problemi legati a errori transitori.
Migliorie operative (quelle che fanno la differenza)
Accanto alle grandi novità, ci sono diversi miglioramenti più piccoli ma molto concreti.
Il domain join prima del deployment permette di separare le attività tra team AD e team infrastruttura, semplificando la pianificazione.
La gestione degli update diventa più controllabile, anche se la piattaforma resta vincolata a un ciclo di vita piuttosto rigido.
Arriva anche la possibilità di bypassare le policy SDN su singole NIC, utile negli scenari ibridi dove convivono networking moderno e workload legacy.
Infine, il portale Azure migliora l’esperienza su dischi, immagini e VM, con un dettaglio da non sottovalutare: il graceful restart diventa il comportamento di default.
Takeaway
Questa release cambia, di fatto, la posizione nel mercato in cui Azure Local si pone.
Non è più solo una soluzione per edge o branch office, ma una piattaforma che punta chiaramente al datacenter enterprise, anche in chiave alternativa a VMware.
La combinazione di SAN support e deployment disaggregati rende possibile migrare mantenendo parte dell’infrastruttura esistente, mentre la GPU acceleration apre scenari concreti per AI all’edge.
Maggiori dettagli qui: What’s new in hyperconverged deployments of Azure Local?
