Azure Local ha vissuto mesi intensi. La release 2604 di aprile 2026 ha ridisegnato le fondamenta di storage e scala, la 2605 di maggio ha consolidato con nuova osservabilità GPU e fix di affidabilità, e Microsoft Build 2026 ha ridefinito la direzione della piattaforma nel suo complesso. Questo articolo esamina le due release mensili e gli annunci Build separatamente, per dare a ciascuno il giusto peso.
Azure Local 2604: le novità di aprile
La build 2604 (versione 12.2604.1003.209) porta tutti i deployment al nuovo OS 26100.32690, su .NET 8.0.26 e .NET 10.0.6. Richiede un driver compatibile con tale OS build o con Windows Server 2025; per l’hardware Integrated System o Premier dal catalogo Azure Local, l’OS arriva preinstallato via OEM.
Le novità principali di 2604:
- SAN support GA: lo storage SAN è ora generalmente disponibile. Le organizzazioni possono collegare volumi SAN esterni e usarli insieme a Storage Spaces Direct (S2D). Al momento del GA la connettività supportata è Fibre Channel, con configurazioni validate da Dell Technologies, Lenovo, HPE, NetApp, Hitachi Vantara, DataON ed Everpure
- Disaggregated deployments GA: un cluster può essere deployato su sola storage SAN, disaccoppiando la crescita dello storage da quella del compute. Scala fino a 64 nodi, superando il tetto storico dei 16 nodi del modello hyperconverged
- iSCSI SAN preview: estensione della connettività SAN a iSCSI, per vendor come Pure Storage, NetApp, Dell, Lenovo, HPE e Hitachi. Copre sia deployment hybrid (S2D + SAN) che disaggregated (solo SAN)
- GPU acceleration GA: attach e detach di GPU complete (DDA) o partizioni GPU (GPU-P) sulle Azure Local VM, come operazione Day-2 via portale o CLI
- Local identity with Key Vault GA: identity management locale con Azure Key Vault; il rack-aware clustering adesso supporta questo modello di identità
- Domain join prior to deployment: il join al dominio prima del deployment è supportato out of the box
- Update settings: nuovo controllo granulare su come gli aggiornamenti vengono applicati per cluster
- Validation improvements: tempo di validazione ridotto fino al 50%; la validazione riprende dal punto di fallimento entro una finestra di tre ore invece di ripartire da zero
- Deployment performance: durata del deployment coerente per cluster fino a 8 nodi, con riduzione complessiva fino al 40%
- Security baseline: testo e banner di logon utente per conformità a DISA STIG e CIS, protetti da drift control
- Enhanced VM e disk management: nuova esperienza di gestione dischi a livello cluster nel portale, attach di dischi esistenti da VM view, navigazione immagini Azure Marketplace in full-page view
- Graceful restart default: il riavvio delle Azure Local VM esegue ora uno shutdown controllato per impostazione predefinita
- SDN management per-interface: possibilità di abilitare o disabilitare la gestione SDN per singola interfaccia di rete
Sul fronte AKS: supporto per le versioni Kubernetes 1.31, 1.32 e 1.33; Kubernetes 1.30 non è più supportato. KMS v2 è incluso e la deprecazione di KMS v1 è imminente — i cluster devono essere pianificati per il redeployment su v2.
Azure Local 2605: le novità di maggio
La build 2605 (versione 12.2605.1003.210, disponibile dal 28 maggio 2026) è un aggiornamento mensile di sicurezza e qualità, non una release feature come 2604. Porta il baseline OS a 26100.32860 e aggiorna il runtime a .NET 8.0.27 e .NET 10.0.8.
L’unica aggiunta funzionale degna di nota è il supporto per il monitoraggio dei GPU metrics per GPU configurate con GPU Partitioning (GPU-P): l’utilizzo GPU è ora visibile attraverso gli strumenti di monitoring standard, colmando il gap di osservabilità lasciato aperto dal GA del lifecycle GPU in 2604.
Sul fronte reliability, 2605 risolve due problemi rilevanti:
- Un bug che in Azure Local versione 2601 e successive poteva causare cancellazione involontaria delle VM quando un componente della piattaforma le classificava erroneamente durante operazioni di routine
- Un fallimento del comando az stack-hci-vm stop con le versioni CLI 1.14.x su cluster precedenti alla 2604
Chi è su build 2601 o successive con workload in produzione dovrebbe applicare 2605 con priorità per il primo fix.
Microsoft Build 2026: la direzione della piattaforma
Gli annunci Build 2026 per Azure Local non riguardano una singola release mensile — riguardano dove Microsoft sta portando la piattaforma. Il messaggio è chiaro: Azure Local si muove in due direzioni contemporaneamente. All’estremità superiore, infrastruttura sovereign-scale per grandi ambienti regolamentati. All’estremità inferiore, dispositivi edge compatti a nodo singolo. In entrambi i casi, la management experience resta invariata: portale Azure, Azure CLI, Azure API.
Prima di entrare nei singoli annunci, vale la pena chiarire la tassonomia dei deployment che Build ha completato:
| Tipo | OS | Storage / compute | Scala | Stato |
|---|---|---|---|---|
| Hyperconverged | Windows | Storage Spaces Direct | Fino a 16 nodi | GA |
| Disaggregated | Windows | SAN storage | Fino a 64 nodi | GA |
| Multi-rack | Azure Linux | Rack preintegrati, SAN, networking gestito | Centinaia–migliaia di nodi | GA |
| Small form factor | Linux | Singolo nodo, Docker / K3s | Dispositivo edge | Preview |
Small form factor: Azure Local all’edge
L’annuncio più inatteso di Build è un nuovo deployment type in preview: dispositivi compatti, Linux-based, a nodo singolo, progettati per ambienti edge e distribuiti — retail, fabbriche, filiali, qualsiasi contesto in cui un rack completo non ha senso. Le differenze rispetto all’Azure Local tradizionale sono sostanziali:
- OS Linux, non Windows
- Single-node only
- Docker (incluso nell’immagine base) e K3s, la distribuzione Kubernetes leggera, al posto di Hyper-V
- Zero-touch provisioning: si scrive l’immagine OS su una chiavetta USB, si accende il dispositivo, si rimuove la chiavetta, tutto il resto si gestisce da Azure
- Validato su hardware compatto: ASUS NUC 14 Pro, ASUS NUC 15 Pro, Lenovo ThinkEdge SE30, Lenovo ThinkEdge SE100, OnLogic HX521
Microsoft posiziona questo deployment sotto il banner Physical AI: i dispositivi sono validati per eseguire Foundry Local per l’inferenza AI, Azure IoT Operations per la connettività di device e sensori, e AKS su bare metal per i workload containerizzati. L’obiettivo è un singolo dispositivo gestito centralmente che gestisce ingestione dati IoT, elaborazione AI locale e workload Kubernetes all’edge — pensato per deployamenti in migliaia di location.
AKS su bare metal
Direttamente collegato allo small form factor è il public preview di AKS su bare metal. AKS può ora girare direttamente sull’hardware edge senza hypervisor: nessun Hyper-V, nessun layer di virtualizzazione, Kubernetes direttamente sul metallo. Le stesse API, lo stesso control plane, la stessa esperienza — su una nuova classe di hardware. Il control plane Kubernetes gira localmente sul dispositivo, quindi i workload deployati continuano a funzionare normalmente in caso di perdita di connettività.
Vale notare che Microsoft ha menzionato AKS bare metal anche nel contesto di NVLink, RDMA e workload GPU ad alte prestazioni, il che suggerisce che questa capability potrebbe estendersi ben oltre i dispositivi edge compatti.
Sovereign Private Cloud: scala e stack completo
La formalizzazione della Microsoft Sovereign Private Cloud come categoria distinta è avvenuta a fine aprile 2026, con la conferma che Azure Local (nella variante multi-rack, su Azure Linux) scala ora a migliaia di server in un singolo ambiente sovrano. A Build, l’accento è caduto sul completamento dello stack entro il confine di fiducia del cliente:
- Azure Local per l’infrastruttura
- Microsoft 365 Local per produttività e collaboration senza dipendenze SaaS
- Foundry Local per i workload AI
- GitHub Enterprise Local per il DevOps lifecycle
La significatività è pratica: per la prima volta queste quattro componenti operano in modo coerente all’interno dello stesso confine controllato dall’organizzazione.
Foundry Local: multi-node e vLLM
A Build, Foundry Local su Azure Local ha ricevuto due aggiornamenti rilevanti. Il supporto multi-node permette di scalare l’inferenza AI su più nodi del cluster invece di essere confinata a un singolo nodo. L’aggiunta del runtime vLLM è altrettanto significativa: in precedenza Foundry Local si appoggiava esclusivamente a ONNX Runtime, che richiedeva modelli in formato ONNX e limitava la scelta. vLLM è il motore di inferenza open-source su cui la comunità AI si è standardizzata e permette di deployare modelli da Hugging Face nel loro formato nativo, senza conversione.
Combinato con il supporto per NVIDIA RTX PRO 6000 Blackwell e la famiglia di modelli open Nemotron, lo stack per l’inferenza AI on-premises diventa: Azure Local, hardware GPU, Foundry Local, vLLM.
Agentic retrieval: RAG on-premises su dati M365
Foundry Local supporta ora l’agentic retrieval — essenzialmente RAG — eseguita interamente on-premises su dati locali di Microsoft 365 Local. I modelli AI su Azure Local possono cercare e recuperare contesto da documenti in SharePoint locale, OneDrive e altri dati M365, generando risposte contestualizzate senza che i dati lascino l’infrastruttura. Il layer di retrieval usa il Model Context Protocol (MCP) per esporre le capacità RAG come tool consumabili da qualsiasi agente MCP-compatibile — lo stesso pattern di Foundry IQ in cloud, ma eseguito localmente sul cluster.
GitHub Enterprise Local
Per ambienti sovereign e air-gapped, GitHub Enterprise Local è entrato in preview. GitHub Enterprise Server può ora girare come VM prebuilt su Azure Local, portando il DevOps lifecycle completo — inclusi source code, pipeline di build e artefatti — interamente all’interno dell’infrastruttura propria. Combinato con Foundry Local per lo sviluppo assistito da AI e GitHub Copilot, gli sviluppatori in ambienti disconnessi o regolamentati ottengono lo stesso toolchain dei colleghi connessi al cloud.
Azure Kubernetes Fleet Manager per cluster Arc-enabled
Azure Kubernetes Fleet Manager si estende ora oltre Azure ai cluster Arc-enabled. I cluster AKS su Azure Local — e su qualsiasi ambiente connesso via Arc — possono essere gestiti come una fleet da un unico control plane, applicando aggiornamenti, policy e deployment di workload in modo coerente sull’intero estate Kubernetes. Per chi gestisce AKS su Azure Local su più siti, questo evita la gestione cluster per cluster.
Conclusions
Le release 2604 e 2605 hanno rimosso limiti storici della piattaforma — architettura storage, numero di nodi, ciclo di vita GPU, osservabilità. Build 2026 ha aggiunto la dimensione strategica: Azure Local come infrastruttura per sovereign cloud a scala enterprise nella direzione alta, e come piattaforma per dispositivi edge intelligenti a nodo singolo nella direzione bassa. Il filo conduttore è che sempre più workload AI vengono abilitati su infrastruttura che le organizzazioni possiedono e controllano direttamente, con la stessa management experience del cloud Microsoft. Per chi sta valutando una strategia ibrida, edge o sovereign, questo è il momento in cui i pezzi iniziano a combaciare.
#DBS