Anche questo mese torna la mia rubrica dedicata all’evoluzione dei servizi di management e security in ambito Azure, con uno sguardo attento agli scenari ibridi e multicloud abilitati da Azure Arc e potenziati dall’utilizzo dell’Intelligenza Artificiale.
Questa serie di articoli mensili si propone di:
- offrire una panoramica delle novità più rilevanti introdotte da Microsoft;
- condividere consigli operativi e best practice raccolti dal campo, per aiutare architect e responsabili IT a gestire con efficacia ambienti complessi e distribuiti;
- seguire l’evoluzione verso un modello di gestione centralizzato, proattivo e basato sull’AI, in linea con la visione di Microsoft dell’AI-powered Management.
Gli ambiti principali affrontati in questa rubrica, accompagnati dagli strumenti e servizi di riferimento, sono descritti in questo articolo.
Hybrid and multicloud environment management
Azure Arc
Automazione sicura dell’onboarding dei server Azure Arc su larga scala con Ansible
Microsoft ha introdotto un nuovo ruolo di onboarding per Azure Arc progettato specificamente per gli scenari di automazione, come quelli basati su playbook Ansible, con l’obiettivo di rendere più semplice e sicura la connessione dei server ad Azure Arc. Questo nuovo approccio adotta il principio del privilegio minimo, assegnando alle identità di automazione esclusivamente i permessi necessari per eseguire l’onboarding, senza ricorrere a service principal eccessivamente permissivi. La novità risponde a esigenze molto diffuse negli ambienti ibridi e multicloud, dove spesso l’onboarding su larga scala è ostacolato da passaggi manuali, difficoltà di standardizzazione e rischi legati alla sicurezza. Integrando il nuovo ruolo con i flussi di lavoro Ansible esistenti, le organizzazioni possono automatizzare l’intero processo in modo ripetibile, coerente e scalabile, riducendo il rischio operativo e semplificando l’adozione di Azure Arc in datacenter distribuiti e in infrastrutture ospitate su cloud differenti.
Azure Arc introduce il supporto a SQL Server su Azure Virtual Machines come target di migrazione (preview)
Azure Arc introduce in Public Preview il supporto a SQL Server su Azure Virtual Machines come destinazione per i percorsi di migrazione. Con questa novità, le istanze SQL Server abilitate tramite Azure Arc possono essere migrate non solo verso Azure SQL Managed Instance, ma anche verso SQL Server eseguito su infrastruttura Azure, utilizzando lo stesso workflow di migrazione unificato. Questa estensione offre maggiore flessibilità alle organizzazioni che stanno pianificando iniziative di modernizzazione SQL Server, permettendo di scegliere la destinazione Azure più adatta in base ai requisiti applicativi, ai modelli operativi esistenti e alle esigenze di compatibilità. Per molte realtà enterprise, questa possibilità rappresenta un approccio graduale alla modernizzazione, in grado di coniugare i benefici dell’infrastruttura cloud con la continuità operativa e funzionale richiesta da applicazioni ancora fortemente dipendenti da SQL Server tradizionale.
Eseguire l’ultima versione dell’agente Azure Arc con Automatic Agent Upgrade (preview)
Microsoft ha introdotto nuove modalità per abilitare su larga scala la funzionalità Automatic Agent Upgrade per l’agente di Azure Arc, con l’obiettivo di semplificare la gestione di ambienti distribuiti composti da numerosi server. In contesti ibridi e multicloud, infatti, la configurazione manuale server per server non risulta sostenibile e può generare disallineamenti operativi, ritardi nell’adozione delle nuove funzionalità e una minore tempestività nell’applicazione degli aggiornamenti di sicurezza. Per rispondere a questa esigenza, Microsoft ha reso disponibile un criterio predefinito di Azure Policy che consente di verificare se l’aggiornamento automatico dell’agente sia attivo all’interno di uno specifico ambito e, se necessario, di correggere automaticamente le configurazioni non conformi. Inoltre, per i server di nuova registrazione, è ora possibile attivare questa funzionalità già in fase di onboarding tramite il parametro
Security posture across hybrid and multicloud infrastructures
Microsoft Defender for Cloud
Rilevamento e blocco anti-malware per i container
Microsoft ha annunciato la disponibilità delle funzionalità di rilevamento e blocco anti-malware per il runtime dei container in Microsoft Defender for Containers. La funzionalità è ora disponibile per ambienti Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) e Google Kubernetes Engine (GKE), rafforzando la protezione dei workload containerizzati anche in scenari ibridi e multicloud. Questa capacità consente di rilevare e bloccare malware nel momento in cui un container tenta di eseguire un file identificato come malevolo. Il controllo avviene quindi durante l’esecuzione del workload, offrendo un ulteriore livello di difesa rispetto alle fasi precedenti del ciclo di vita applicativo, come build, scanning delle immagini e deployment. Un elemento rilevante è la possibilità di definire policy anti-malware personalizzate, configurando condizioni specifiche per la generazione degli alert e per l’attivazione del blocco. Questo permette ai team di sicurezza di distinguere con maggiore precisione le attività legittime dai comportamenti potenzialmente pericolosi, riducendo il rumore operativo e migliorando l’efficacia della risposta agli incidenti. Per le organizzazioni che gestiscono cluster Kubernetes distribuiti su più cloud, questa funzionalità rappresenta un ulteriore passo verso un modello di protezione runtime più coerente, centralizzato e scalabile.
DNS Detection per Kubernetes
La funzionalità DNS Detection for Kubernetes è ora disponibile in General Availability in Microsoft Defender for Containers per ambienti Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) e Google Kubernetes Engine (GKE). Questa novità rafforza le capacità di rilevamento delle minacce runtime, con particolare attenzione al traffico DNS generato dai pod e dalle applicazioni in esecuzione nei cluster Kubernetes. DNS Detection monitora le query DNS provenienti dai workload containerizzati per individuare attività sospette, come comunicazioni verso domini malevoli o possibili tecniche di DNS tunneling. Quest’ultima può essere utilizzata dagli attaccanti per esfiltrare dati o mantenere canali di comunicazione nascosti sfruttando il protocollo DNS. Per utilizzare la funzionalità è necessario distribuire il sensore di Defender tramite Helm. Una volta attivata, DNS Detection offre ai team di sicurezza e cloud operation una maggiore visibilità sui comportamenti di rete dei workload Kubernetes, contribuendo a identificare precocemente potenziali indicatori di compromissione. In scenari ibridi e multicloud, la disponibilità uniforme di questa capacità su piattaforme diverse aiuta a costruire una postura di sicurezza più consistente, governabile e integrata.
Integrazione di Defender for Storage nello Storage Center del portale Azure
Microsoft ha reso disponibile in General Availability l’integrazione di Microsoft Defender for Storage all’interno dello Storage Center del portale Azure. Questa integrazione porta le informazioni di sicurezza direttamente nell’esperienza nativa di gestione dello storage, semplificando l’analisi della postura di protezione e l’identificazione delle aree di miglioramento. Grazie a questa novità, i clienti possono visualizzare lo stato di protezione offerto da Defender for Storage direttamente accanto alle proprie risorse. Lo Storage Center diventa così un punto di osservazione centralizzato e contestuale, utile non solo per la gestione operativa degli account di storage, ma anche per la valutazione della loro esposizione ai rischi. La nuova esperienza consente di individuare rapidamente quali storage account risultano protetti, parzialmente protetti o non protetti. Permette inoltre di verificare l’abilitazione di funzionalità come malware scanning, activity monitoring e sensitive data discovery, offrendo una visione più chiara delle coperture attive e delle eventuali lacune. Questa integrazione è particolarmente utile negli ambienti enterprise, dove servizi come Azure Blob Storage e Azure Files possono essere distribuiti su molteplici subscription, business unit e workload. L’obiettivo è rendere la sicurezza dello storage più accessibile ai team operativi, incorporandola nei processi quotidiani di gestione e favorendo un approccio più proattivo alla protezione dei dati.
Funzionalità di sicurezza per container in Azure Government cloud
Microsoft ha annunciato la disponibilità generale delle funzionalità di sicurezza per container in Azure Government cloud. Questa evoluzione consente ad agenzie federali e governative statunitensi, incluse realtà del Department of Defense (DoD) e agenzie civili, di proteggere workload Kubernetes tramite funzionalità avanzate di Cloud Security Posture Management (CSPM), vulnerability assessment e runtime threat protection.
Aggiornamento del piano Defender for SQL Server on machines per i clienti Fairfax
Microsoft ha annunciato un aggiornamento del piano Defender for SQL Server on machines in Microsoft Defender for Cloud per i clienti Fairfax. Il piano protegge le istanze SQL Server ospitate su macchine Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP) e ambienti on-premises, offrendo un modello di protezione coerente per scenari ibridi e multicloud. La nuova soluzione utilizza l’infrastruttura SQL esistente e non richiede più la distribuzione di Azure Monitor Agent (AMA). Questo cambiamento riduce la complessità operativa e facilita l’adozione del piano, soprattutto negli ambienti distribuiti dove la gestione degli agent può rappresentare un elemento critico. A partire da una data stimata di maggio 2026, sarà inoltre necessario verificare lo stato di protezione delle istanze SQL Server nei diversi ambienti, per assicurarsi che la nuova configurazione sia stata applicata correttamente e che le istanze risultino effettivamente protette. Questo aggiornamento conferma la direzione intrapresa da Microsoft verso modelli di protezione più semplici da distribuire e mantenere, riducendo la dipendenza da componenti aggiuntivi e migliorando la visibilità centralizzata sullo stato di sicurezza delle istanze SQL Server, indipendentemente dalla loro collocazione infrastrutturale.
Governance and policy management
Azure Policy
Nuovo Management Group “Local” per Azure Landing Zone e Sovereign Landing Zone
Microsoft ha introdotto un nuovo Management Group dedicato, denominato “Local”, all’interno dell’architettura concettuale di Azure Landing Zone (ALZ). Questo nuovo nodo viene posizionato sotto il Management Group Landing Zones, affiancando i Management Group già esistenti Corp e Online. Poiché la Sovereign Landing Zone (SLZ) estende e dipende dall’architettura ALZ, anche la gerarchia SLZ eredita automaticamente questo nuovo Management Group nella medesima posizione.
L’obiettivo principale di questa evoluzione è fornire una collocazione chiara e coerente per gli scenari legati ad Azure Local, sia quando i workload vengono eseguiti direttamente su cluster Azure Local, sia quando sono attualmente ospitati nel cloud pubblico Azure ma devono essere progettati con requisiti di portabilità verso scenari di Azure Local disconnected operations (ALDO). In questo modo, le organizzazioni che devono soddisfare requisiti di sovranità, resilienza o continuità operativa possono definire fin dall’inizio un perimetro di governance specifico, applicando controlli, policy e guardrail coerenti.
Il nuovo Management Group “Local” consente quindi di applicare in modo centralizzato criteri di governance e sicurezza a workload che devono essere “exit-ready by construction”, cioè pronti per essere trasferiti verso un ambiente Azure Local disconnesso qualora se ne presenti la necessità. Questo approccio evita che la portabilità venga gestita manualmente o documentata in strumenti esterni, affidando invece alla piattaforma il compito di prevenire configurazioni non compatibili.
A supporto di questo scenario, Microsoft ha reso disponibile una nuova Azure Policy built-in in anteprima, pensata per limitare i tipi di risorse ai soli servizi Azure supportati in modalità Azure Local disconnected operations. La policy può essere utilizzata in modalità Audit, per ottenere visibilità sulle risorse non compatibili già distribuite, oppure in modalità Deny, per impedire il deployment di servizi che comprometterebbero la possibilità di spostare il workload verso Azure Local in modalità disconnessa.
È importante evidenziare che il nuovo Management Group “Local” non è pensato come contenitore generico per tutte le risorse Azure Arc-enabled, ad esempio i server connessi tramite Azure Arc. Microsoft conferma che tali risorse dovrebbero continuare a essere collocate nelle rispettive subscription applicative, seguendo le normali linee guida delle Azure Landing Zone, ad esempio all’interno di landing zone di tipo Corp o Online. Il Management Group “Local” deve invece essere interpretato come uno scope specifico per scenari Azure Local e per workload che richiedono una strategia strutturata di exit planning verso Azure Local disconnected operations.
Nuove iniziative di policy sovrane per Sovereign Landing Zone
Microsoft ha aggiornato la Sovereign Landing Zone (SLZ) sostituendo le precedenti iniziative built-in denominate Sovereignty Baseline con un nuovo set di iniziative di policy sovrane, allineate direttamente ai tre livelli di controllo previsti dal modello di sovranità Microsoft. Questo aggiornamento introduce una maggiore coerenza tra l’implementazione tecnica della SLZ e la documentazione ufficiale relativa ai controlli e ai principi della Sovereign Public Cloud.
Le nuove iniziative built-in sono organizzate in base a tre livelli: Level 1, dedicato alla data residency; Level 2, focalizzato sulla cifratura dei dati at-rest e in-transit; Level 3, orientato alla cifratura dei dati in uso attraverso tecnologie di Confidential Computing. Questa suddivisione consente alle organizzazioni di applicare controlli più mirati in funzione della classificazione dei dati e dei requisiti di sovranità richiesti dai diversi workload.
In precedenza, la SLZ assegnava due iniziative built-in più ampie: una relativa alle policy globali di sovranità, con controlli su restrizioni di localizzazione e Trusted Launch, e una dedicata agli scenari confidential, con policy su customer-managed keys, confidential compute e restrizioni su tipi di risorse e aree geografiche. Pur essendo utili come baseline generale, queste iniziative non erano progettate per mappare in modo puntuale il modello L1/L2/L3 utilizzato da Microsoft per descrivere i controlli sovrani.
Il nuovo approccio offre diversi vantaggi operativi. Innanzitutto, le policy assegnate dalla SLZ diventano coerenti con quanto documentato in Microsoft Learn, riducendo la necessità di interpretazioni o mapping manuali. Inoltre, ogni livello di controllo può essere associato in modo più naturale alla classificazione dei dati, permettendo alle organizzazioni di applicare solo i controlli effettivamente necessari per ciascun ambito. Questo semplifica la governance, migliora la leggibilità dell’architettura e rende più efficace il dialogo tra team cloud, security, compliance e risk management.
Un ulteriore beneficio riguarda la riduzione dell’onere di manutenzione. Utilizzando iniziative built-in gestite direttamente dal product group Microsoft responsabile degli scenari di sovranità, i clienti possono beneficiare degli aggiornamenti futuri senza dover mantenere copie personalizzate delle policy all’interno della propria implementazione SLZ. Inoltre, essendo iniziative built-in, queste policy si integrano nativamente con strumenti come Azure Policy compliance reporting e Microsoft Defender for Cloud, facilitando le attività di auditing e la produzione di evidenze di conformità.
Distribuzione di playbook Ansible tramite Azure Policy e Machine Configuration (preview)
Microsoft ha annunciato la private preview di una nuova funzionalità che consente di distribuire ed eseguire playbook Ansible tramite Azure Policy usando Machine Configuration su macchine Linux in Azure e su server Linux abilitati con Azure Arc. Questa novità si inserisce nella strategia di Azure Arc volta a unificare sicurezza, compliance e gestione di sistemi Windows e Linux, indipendentemente dalla loro collocazione tra datacenter on-premises, edge e cloud pubblici. La nuova capacità consente di orchestrare l’esecuzione dei playbook direttamente dal piano di controllo di Azure, senza la necessità di predisporre un nodo di controllo Ansible dedicato, integrando al tempo stesso il reporting di conformità e i meccanismi di remediation automatica. In scenari operativi sempre più eterogenei, molte organizzazioni utilizzano Ansible per la configurazione dei sistemi operativi e delle applicazioni, ma incontrano difficoltà nel garantire coerenza configurativa, rilevare il drift nel tempo e integrare tali automazioni nei processi centralizzati di governance. Con questa anteprima, Azure Policy diventa un punto di controllo unico anche per l’automazione Linux basata su Ansible, portando tali workload nello stesso modello di governance già adottato per altri ambienti. I risultati di esecuzione dei playbook e lo stato di conformità vengono resi visibili direttamente nel dashboard di compliance di Azure Policy, offrendo così un’esperienza unificata di gestione, sicurezza e controllo, valorizzando al contempo gli investimenti già effettuati dalle aziende nell’ecosistema Ansible.
Backup & Resilience
Azure Backup
Backup di AKS configurabile con un solo comando grazie ad Azure Backup
Microsoft ha annunciato una nuova esperienza semplificata basata su Azure CLI che consente di configurare il backup di Azure Kubernetes Service (AKS) con un solo comando tramite Azure Backup. La novità nasce dall’esigenza di ridurre la complessità dell’onboarding dei cluster AKS alla protezione dei dati, un processo che finora richiedeva il coordinamento di più domini CLI e l’esecuzione di numerosi passaggi distinti, tra cui l’installazione delle estensioni, il provisioning dello storage account, la creazione del vault di backup, la definizione delle policy, la configurazione del trusted access e l’inizializzazione dell’istanza di backup. Con questa nuova modalità, i team di piattaforma possono accelerare sensibilmente l’abilitazione della protezione dei cluster, integrando più facilmente il backup nei processi di automazione e nelle pipeline CI/CD. L’iniziativa si inserisce in una strategia più ampia volta a rendere Azure Backup sempre più adatto agli scenari cloud-native, con l’obiettivo di estendere nel tempo un’esperienza analoga anche ad altri workload supportati dal servizio.
Azure Backup per Elastic SAN (preview)
Azure Backup introduce il supporto per Elastic SAN in Public Preview, offrendo una soluzione completamente gestita per il backup e il ripristino dei volumi Elastic SAN. Questa nuova funzionalità consente di proteggere i dati da scenari critici come eliminazioni accidentali, incidenti ransomware o aggiornamenti applicativi non andati a buon fine, esportando i volumi Elastic SAN in snapshot incrementali indipendenti basati su Managed Disk. Gli snapshot vengono archiviati in Locally Redundant Storage (LRS) e rimangono separati dal ciclo di vita del volume Elastic SAN originale, aumentando il livello di resilienza operativa. In questa fase di preview, la soluzione supporta fino a 450 punti di ripristino con una frequenza di backup ogni 24 ore, è disponibile solo in alcune aree Azure selezionate e supporta volumi fino a 4 TiB. Microsoft precisa inoltre che, durante la preview, non sono ancora supportati i backup a lungo termine in vault né i backup con frequenza oraria. Sebbene in questa fase non vengano applicati costi relativi alle Protected Instance di Azure Backup, restano comunque validi i costi standard associati agli snapshot incrementali dei Managed Disk.
Azure Site Recovery
Azure Site Recovery supporta le VM Azure Windows con controller disco NVMe (preview)
Azure Site Recovery estende il supporto alla replica e al disaster recovery delle macchine virtuali Azure Windows eseguite su famiglie di VM di seconda generazione abilitate a NVMe, attualmente in Public Preview. Tra gli scenari supportati rientra la protezione Azure-to-Azure per serie come Da/Ea/Fa v6 ed Ebsv5/Ebdsv5, che consentono di eseguire workload ad alte prestazioni e a elevata intensità di I/O sfruttando il controller disco NVMe. Questa novità amplia in modo significativo la copertura del servizio verso macchine virtuali particolarmente sensibili alle prestazioni, offrendo nuove opportunità di resilienza per applicazioni critiche e scenari enterprise avanzati. La funzionalità è disponibile in tutte le regioni del cloud pubblico Azure, nel rispetto dei limiti di churn supportati da Azure Site Recovery.
Monitoring
Azure Monitor
Monitorare le applicazioni AKS con OpenTelemetry ed Azure Monitor (preview)
Azure Monitor introduce, in Public Preview, il supporto al monitoraggio delle applicazioni in esecuzione su Azure Kubernetes Service (AKS) tramite OpenTelemetry per fare l’instrumentazione e la raccolta dei dati. I clienti possono scegliere un approccio di auto-instrumentation, distribuendo direttamente sui workload la distribuzione OpenTelemetry di Azure Monitor, oppure adottare una modalità di auto-configuration per instradare verso Azure Monitor i segnali OpenTelemetry Protocol (OTLP) provenienti da applicazioni già strumentate con SDK open source e vendor-neutral. Questa evoluzione semplifica l’implementazione dell’osservabilità negli ambienti AKS e, allo stesso tempo, rafforza l’allineamento con gli standard aperti del mondo cloud-native, favorendo una maggiore interoperabilità e una gestione più coerente della telemetria applicativa.
Azure Monitor per ambienti Azure Arc-enabled Kubernetes basati su OpenShift e Azure Red Hat OpenShift
Azure Monitor estende la propria disponibilità in General Availability agli ambienti Azure Arc-enabled Kubernetes basati su OpenShift e Azure Red Hat OpenShift, attraverso Container Insights e Managed Prometheus. Questa evoluzione consente alle organizzazioni di ottenere un’esperienza di monitoraggio completa per i livelli infrastrutturali Kubernetes e per le applicazioni che vi risiedono, rafforzando le capacità di osservabilità negli scenari ibridi e cloud-native. Grazie a questa integrazione, i team IT possono raccogliere, analizzare e visualizzare la telemetria operativa degli ambienti OpenShift, migliorando le attività di troubleshooting, gestione delle performance e controllo dello stato di salute dei workload distribuiti. Si tratta di un passo importante verso un modello di management sempre più centralizzato, in cui Azure Monitor diventa il punto di riferimento anche per piattaforme Kubernetes eseguite al di fuori del perimetro Azure tradizionale.
Azure Monitor pipeline
Azure Monitor pipeline è ora disponibile in General Availability e introduce un livello avanzato di controllo sulla raccolta, trasformazione e resilienza della telemetria prima che i dati raggiungano Azure Monitor. Questa funzionalità permette ai log di essere indirizzati direttamente verso schemi Azure-native, grazie alla schematizzazione automatica in tabelle come Syslog e CommonSecurityLog. Un elemento particolarmente rilevante è la capacità di ridurre il rischio di perdita dei dati in presenza di connettività intermittente, tramite buffering locale su storage persistente e successivo backfill automatico. Azure Monitor pipeline consente inoltre alle organizzazioni di ottimizzare i costi di ingestion applicando logiche centralizzate di filtro, aggregazione e trasformazione prima dell’invio dei dati verso il cloud. La soluzione è progettata per supportare volumi elevati e continuativi di telemetria attraverso un’architettura scalabile, includendo anche funzionalità per l’ingestion sicura tramite Transport Layer Security (TLS) e mutual TLS (mTLS), provisioning automatico dei certificati, visibilità sullo stato dell’infrastruttura di ingestion e strumenti di sizing per pianificazioni su larga scala.
Ingestion nativa dei segnali OpenTelemetry Protocol (OTLP) tramite Azure Monitor Agent (preview)
Azure Monitor introduce in Public Preview il supporto all’ingestion nativa dei segnali OpenTelemetry Protocol (OTLP) tramite Azure Monitor Agent (AMA). Questa funzionalità consente alle applicazioni instrumentate con OpenTelemetry di inviare la telemetria direttamente ad Azure Monitor, facendo in modo che Azure Monitor Agent riceva i segnali OTLP dalle applicazioni e li esporti verso la piattaforma di monitoraggio. Microsoft supporta diversi meccanismi di ingestion OTLP, tra cui OpenTelemetry Collector, Azure Monitor Agent e l’add-on per Azure Kubernetes Service (AKS). L’approccio basato su Azure Monitor Agent è pensato in particolare per applicazioni eseguite su Azure Virtual Machines, Virtual Machine Scale Sets o server abilitati tramite Azure Arc. Questa evoluzione aiuta le organizzazioni a standardizzare l’osservabilità adottando standard aperti, semplificando la raccolta della telemetria in ambienti cloud, ibridi e distribuiti, e rafforzando il percorso verso un modello di gestione più uniforme e proattivo.
Conclusioni
Le novità di aprile 2026 confermano l’evoluzione di Azure come piattaforma centrale per la gestione, la sicurezza, la governance e l’osservabilità degli ambienti ibridi e multicloud. Azure Arc continua a rafforzarsi come elemento chiave per estendere il controllo di Azure a server, database e workload distribuiti, con maggiore attenzione ad automazione, sicurezza e aggiornamento continuo degli agent. Parallelamente, Microsoft Defender for Cloud amplia le capacità di protezione runtime, in particolare per container, Kubernetes, storage e SQL Server, offrendo una postura di sicurezza sempre più coerente su Azure, AWS, Google Cloud e ambienti on-premises. Anche la governance compie un passo avanti, grazie all’evoluzione delle Azure Landing Zone, alle nuove iniziative sovrane e all’integrazione di Azure Policy con scenari di automazione come Ansible. Queste funzionalità aiutano le organizzazioni a standardizzare configurazioni, ridurre il drift e applicare controlli coerenti su infrastrutture distribuite. Sul fronte della resilienza e del monitoraggio, Azure Backup, Azure Site Recovery e Azure Monitor estendono il supporto a workload moderni come AKS, Elastic SAN, VM NVMe, OpenShift e applicazioni basate su OpenTelemetry, semplificando protezione, disaster recovery e osservabilità. Nel complesso, il messaggio è chiaro: la gestione degli ambienti ibridi e multicloud deve essere sempre più automatizzata, sicura e governata in modo centralizzato. Il consiglio è quindi di valutare queste novità come tasselli di una strategia integrata, partendo da Azure Arc, Azure Policy, Defender for Cloud, Backup e Monitor per costruire un modello operativo più coerente, resiliente e scalabile.