Microsoft AZ-305: Alta disponibilità, ripristino di emergenza e continuità operativa — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Solutions Architect Expert AZ-305 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’alta disponibilità (HA), il ripristino di emergenza (DR) e la continuità operativa (BC) in Azure richiedono una progettazione ponderata a livello di calcolo, dati e rete. La resilienza inizia con obiettivi chiari di tempo di ripristino (RTO) e punto di ripristino (RPO), per poi comporre le funzionalità della piattaforma — Availability Zones, routing globale, replica dei dati, backup e orchestrazione del failover — in una strategia testata e automatizzata. Azure fornisce isolamento dei guasti a livello di zona e regione, distribuzione globale basata su DNS e anycast, durabilità dei dati multi-regione e backup/ripristino basati su policy per soddisfare obiettivi rigorosi, controllando al contempo costi e complessità operativa.

Architettura Guidata da RTO/RPO e Resilienza Zonale/Globale

La progettazione inizia con RTO e RPO. L’RTO determina la rapidità con cui un servizio deve essere ripristinato dopo un guasto; l’RPO determina la massima perdita di dati accettabile. Raggiungere un RTO basso richiede un failover automatizzato e capacità pre-provisionata; raggiungere un RPO basso richiede una replica sincrona o quasi sincrona e punti di ripristino frequenti e consistenti.

Le Availability Zones sono domini di errore di data center indipendenti all’interno di una regione. I servizi di zona (ad esempio, Virtual Machines, dischi gestiti, indirizzi IP pubblici Standard) sono associati a una singola zona. I servizi con ridondanza di zona (ad esempio, frontend con ridondanza di zona di Azure Load Balancer Standard, offerte di archiviazione con ridondanza di zona e livelli di Azure SQL con ridondanza di zona) si estendono automaticamente su più zone. Un tipico modello resiliente prevede l’implementazione di VM di zona in almeno due zone, il loro posizionamento in una singola rete virtuale e l’esposizione di un frontend di bilanciamento del carico con ridondanza di zona. Questo elimina il guasto di una singola zona come causa di downtime.

A livello di edge globale, si può scegliere tra una distribuzione del carico basata su DNS e una basata su proxy anycast:

Azure Traffic Manager è basato su DNS. Indirizza i client agli endpoint utilizzando metodi di routing: Prestazioni (latenza più bassa), Ponderato (test A/B e spostamenti graduali del traffico), Priorità (failover attivo/passivo), Geografico (servire gli utenti da endpoint conformi a livello regionale), MultiValore (restituisce più record IPv4/IPv6 integri per client semplici) e Sottorete (mappare intervalli di IP client a endpoint specifici). Essendo basato su DNS, Traffic Manager non accelera i contenuti né funge da proxy per il traffico; i client si connettono direttamente all’endpoint scelto e rispettano il comportamento della cache DNS locale.
Azure Front Door (Standard/Premium) è un reverse proxy HTTP/HTTPS anycast globale con routing intelligente, offload TLS e web application firewall (WAF) integrato. Le regole di routing effettuano il matching su dominio, percorso, metodo e intestazioni, quindi instradano verso i gruppi di origine; le azioni del motore di regole possono riscrivere URL/intestazioni e imporre reindirizzamenti. Gli health probe valutano continuamente lo stato di integrità dell’origine su un percorso e un protocollo configurabili; le origini non integre vengono rimosse dalla rotazione. I gruppi di origine supportano la distribuzione basata su priorità (attivo/passivo) e ponderata tra le regioni. Le policy WAF si applicano all’endpoint o alla rotta, con set di regole gestite, regole personalizzate e limitazione della velocità per mitigare le minacce OWASP e i client abusivi. Utilizzare Front Door quando è necessario un bilanciamento del carico globale con accelerazione, sicurezza a livello di edge e failover a livello di applicazione; combinarlo con Traffic Manager solo quando sono necessari endpoint non HTTP o un controllo a livello di DNS.

A livello 4, Azure Load Balancer fornisce una distribuzione del carico a bassissima latenza per TCP/UDP. Lo Standard Load Balancer supporta frontend di zona e con ridondanza di zona, porte HA, regole in uscita e un comportamento sicuro per impostazione predefinita (configurazione esplicita di NSG e pool di backend). Gli health probe (TCP/HTTP) determinano lo stato di integrità del backend; in caso di guasto, le istanze vengono rimosse dalla rotazione. Il Basic Load Balancer non ha consapevolezza delle zone, funzionalità avanzate e uno SLA: evitarlo per gli ambienti di produzione. Il Cross-region Load Balancer aggiunge un frontend anycast globale che bilancia il carico tra gli Standard Load Balancer regionali, abilitando progetti multi-regione attivi/attivi per carichi di lavoro non HTTP e fornendo un failover regionale rapido basato sullo stato di integrità.

Protezione dei dati e Disaster Recovery: Azure Backup e Site Recovery

Azure Backup fornisce il ripristino point-in-time; Azure Site Recovery (ASR) offre la replica dei carichi di lavoro e il failover orchestrato. Rispondono a esigenze complementari e sono spesso combinati.

Opzioni per i vault di Azure Backup:

Il vault di Servizi di ripristino (Recovery Services vault) protegge le VM di Azure, SQL Server in VM di Azure, SAP HANA in VM di Azure, File di Azure e gli agenti MARS/MABS. Si integra con i criteri di backup (Backup policies) che definiscono pianificazioni, conservazione e backup coerenti con l’applicazione (application-consistent) dove supportato.
Il vault di backup (Backup vault) è il vault modernizzato per carichi di lavoro più recenti come il backup di Dischi Azure (Azure Disks) e il backup di BLOB di Azure (Azure Blobs), offrendo RBAC granulare e archiviazione del vault con ridondanza della zona (zone-redundant) nelle aree supportate. Scegliere il tipo di vault in linea con il carico di lavoro e il modello di governance.

I criteri di backup (Backup policies) regolano quando vengono eseguiti i backup, i loro livelli di conservazione (giornaliero/settimanale/mensile/annuale) e le impostazioni di coerenza. L’eliminazione temporanea (Soft delete) aggiunge una finestra di sicurezza durante la quale gli elementi di backup eliminati possono essere ripristinati, proteggendo da eliminazioni accidentali o dannose. Il ripristino tra aree (Cross-region restore) consente i ripristini dalla regione secondaria quando l’archiviazione del vault utilizza opzioni con ridondanza geografica; deve essere abilitato ed è soggetto al supporto delle funzionalità a livello di area e alla prontezza del piano dati (data-plane).

Azure Site Recovery replica i carichi di lavoro tra zone o aree geografiche e orchestra il DR end-to-end:

I criteri di replica (Replication policies) definiscono la frequenza degli snapshot, la conservazione dei punti di ripristino, la cadenza degli snapshot coerenti con l’applicazione e le soglie di avviso RPO. I criteri bilanciano la larghezza di banda della replica, i costi di archiviazione e la precisione del ripristino.
I piani di ripristino (Recovery plans) forniscono un failover ordinato di applicazioni multi-livello con gruppi (es. database, API, web), passaggi pre/post e automazione tramite runbook di Azure Automation, script o azioni manuali. Integrare nel piano le modifiche DNS, gli aggiornamenti degli endpoint di Traffic Manager/Front Door e la configurazione dell’applicazione.
Il failover di test (Test failover) esegue un ripristino isolato utilizzando una VNet non di produzione o una rete di test per convalidare i runbook, l’ordine di avvio e lo stato di salute dell’applicazione senza impattare la produzione o la replica. Test regolari sono essenziali per convalidare l’RTO.
Il failback riporta i carichi di lavoro al sito o all’area originale quando questa è di nuovo integra. Dopo il failover, è necessario ri-proteggere il carico di lavoro nella nuova direzione primaria, sincronizzare le modifiche, pianificare una finestra di failback e verificare la replica post-failback. Per gli scenari Azure-to-Azure, si esegue tipicamente il failover tra aree abbinate (paired regions) e si inverte la replica per ripristinare la topologia originale quando si è pronti.

Continuità del livello dati: Azure SQL, replica di archiviazione e Cosmos DB

Ogni servizio dati espone semantiche di durabilità e failover distinte che devono allinearsi ai requisiti di coerenza dell’applicazione.

Azure SQL Database e Azure SQL Managed Instance:

La replica geografica attiva (Active geo-replication) crea fino a quattro secondari leggibili per database singoli o pool elastici. Offre una replica a livello di database con failover manuale o guidato da API, abilitando la scalabilità in lettura (read-scale) e il DR. È appropriata quando si necessita di un controllo per singolo database e di un’orchestrazione personalizzata.
I gruppi di failover automatico (Auto-failover groups) creano un gruppo di database (o un’intera istanza gestita) che eseguono il failover insieme tramite un endpoint listener. Semplifica il failover tra aree e la gestione delle stringhe di connessione, e supporta il failover automatico dopo un periodo di tolleranza (grace period). Utilizzare i gruppi di failover per applicazioni multi-database che richiedono un failover coordinato e una connettività client semplificata.
La ridondanza della zona (Zone redundancy) posiziona le repliche tra le zone di una regione per sopravvivere a guasti di zona senza ripristino tra aree. Abilitarla per i livelli di servizio (tiers) che la supportano per migliorare la disponibilità locale senza alterare i profili di latenza.

Opzioni di replica di Archiviazione di Azure (Azure Storage):

GRS (archiviazione con ridondanza geografica) replica i dati in modo asincrono dalla regione primaria (tre copie) a una regione secondaria abbinata (tre copie). Durante il normale funzionamento, letture e scritture sono indirizzate al primario.
RA-GRS aggiunge l’accesso in lettura all’endpoint secondario per scenari come reportistica di emergenza o analisi quando il primario è degradato.
GZRS (archiviazione con ridondanza geografica della zona) combina ZRS nella regione primaria per la durabilità a livello di zona con la replica asincrona verso la regione secondaria, migliorando la resilienza sia locale che a livello di area.
RA-GZRS aggiunge l’accesso in lettura al secondario per gli account GZRS. Se la regione primaria non è recuperabile, è possibile avviare un failover dell’account verso la secondaria. Dopo il failover, l’account di archiviazione diventa primario nella regione secondaria e tipicamente torna a essere con ridondanza locale (finché non viene riconfigurato). Aspettarsi un certo RPO (replica asincrona); le applicazioni dovrebbero gestire l’idempotenza e la riconciliazione dopo il failover.

Azure Cosmos DB:

Le scritture in più aree (Multi-region writes) consentono di scrivere in qualsiasi area configurata con criteri di risoluzione dei conflitti (l’ultima scrittura vince tramite una proprietà designata, strategie personalizzate o multi-master). Ciò riduce la latenza di scrittura e aumenta la disponibilità.
Il failover automatico utilizza un elenco di aree con priorità per promuovere una nuova area di scrittura in caso di interruzione. In combinazione con i livelli di coerenza scelti (da Strong a Eventual), si gestisce il compromesso tra disponibilità e coerenza.
Gli SLA coprono disponibilità, throughput, latenza e coerenza. Con le scritture in più aree, Cosmos DB offre fino al 99,999% di disponibilità sia per le letture che per le scritture, presupponendo una corretta configurazione multi-area. Progettare i client utilizzando l’SDK con il rilevamento degli endpoint (endpoint discovery) e i tentativi (retries) per beneficiare appieno di queste garanzie.

Mettere tutto insieme: Soddisfare obiettivi di ripristino specifici

Associa ogni livello al suo meccanismo di continuità, basandoti su RTO/RPO e domini di errore:

Disponibilità intra-regionale: Usa le Availability Zones. Distribuisci le risorse di calcolo zonali su almeno due zone; utilizza frontend con ridondanza di zona (Standard Load Balancer, Application Gateway v2 con ridondanza di zona o Front Door perimetrale). Abilita la ridondanza di zona per SQL dove supportata e usa GZRS per lo storage che richiede resilienza sia zonale che regionale.
DR tra più aree geografiche: Per i livelli stateful, prediligi la geo-replica nativa (gruppi di failover automatico di SQL, account multi-region di Cosmos DB, Storage GRS/GZRS) per un RPO basso. Per IaaS stateful o carichi di lavoro senza replica nativa, usa Azure Site Recovery con policy di replica e piani di ripristino ben ottimizzati. Per le risorse di calcolo effimere, ricrea da immagini o VM Scale Sets, utilizzando l’Infrastructure as Code.
Routing globale e failover: Per HTTP/S, Azure Front Door fornisce failover basato su health probe, consapevole dell’applicazione, e protezione WAF. Per protocolli non HTTP o misti, aggiungi Traffic Manager (DNS) o Cross-region Load Balancer (L4 anycast) a seconda dei casi. Usa il routing basato sulla priorità per obiettivi RTO attivi/passivi rigorosi; usa quello ponderato per implementazioni graduali (staged rollout) e quello basato sulle prestazioni per esperienze utente a latenza minima.
Backup come ultima linea di difesa: Anche in presenza di replica, mantieni Azure Backup con policy di conservazione che soddisfino la conformità, abilita l’eliminazione temporanea (soft delete) per proteggerti da eventi di eliminazione definitiva (purge) e configura il ripristino tra aree geografiche per i vault che utilizzano storage con ridondanza geografica. I backup proteggono da corruzione logica, ransomware ed errori operativi, rischi che la replica può propagare.

I test non sono negoziabili. Pianifica failover di test regolari con ASR, esegui test di verifica (health drill) su Front Door/Traffic Manager, convalida il comportamento dei gruppi di failover di SQL sotto carico ed esegui simulazioni di failover dello storage in un ambiente sandbox. Strumenta le misurazioni dell’RTO e automatizza il rollback/failback con i runbook. Documenta ed esercitati con i runbook operativi in modo che il personale di reperibilità (on-call) possa eseguirli in modo coerente sotto pressione.

Scenario pratico

Expedia Group deve modernizzare la sua piattaforma globale di prenotazione viaggi per soddisfare un RTO ≤ 15 minuti e un RPO ≤ 5 minuti per le prenotazioni principali, sostenendo al contempo picchi di traffico 10 volte superiori durante i principali eventi di viaggio. La piattaforma serve client web e mobili in tutto il mondo con carichi di lavoro misti HTTP e non HTTP.

Creare resilienza zonale in un’area geografica primaria

Distribuisci microservizi stateless come VM Scale Sets zonali su due o più Availability Zones con frontend ridondanti a livello di zona di tipo Standard Load Balancer. Questo elimina il rischio di guasto di una singola zona e garantisce un traffico intra-regionale a bassa latenza.
Usa Azure SQL Database con gruppi di failover automatico e ridondanza di zona abilitata. I gruppi di failover automatico forniscono un failover coordinato del database e un listener stabile, rispettando l’RTO di 15 minuti con un onere operativo minimo.
Archivia gli artefatti di sessione e le immagini in account di storage GZRS per combinare la durabilità zonale con la protezione regionale asincrona. Questo soddisfa l’RPO di 5 minuti se abbinato all’idempotenza lato applicazione.

Aggiungere DR tra aree geografiche con letture attive/attive

Configura le origini web/API per le prenotazioni in due aree geografiche abbinate dietro un Azure Front Door Standard. Gli health probe e il routing basato sulla priorità consentono un failover rapido in base allo stato di salute dell’applicazione, mentre l’anycast accelera il traffico degli utenti. Le policy WAF con set di regole gestite e rate limiting proteggono da attacchi volumetrici e a livello di applicazione, fondamentali durante i picchi di traffico.
Abilita le scritture multi-region di Cosmos DB per i servizi di itinerario e personalizzazione per ridurre la latenza di scrittura per gli utenti globali e fornire una disponibilità del 99,999%. Il failover automatico dà priorità all’area geografica secondaria, mantenendo un RTO basso senza intervento manuale.
Usa i gruppi di failover automatico di SQL nelle stesse due aree geografiche per le prenotazioni transazionali, abilitando la scalabilità in lettura (read-scale) sui secondari per il reporting e garantendo al contempo un failover rapido e coordinato.

Proteggere lo stato e supportare il ripristino dalla corruzione

Usa i vault di Recovery Services per i backup delle VM di Azure (coerenti con l’applicazione, dove supportato) e di SQL in-VM se rimangono componenti legacy. Applica policy di backup con conservazione a più livelli (tiered retention) e abilita l’eliminazione temporanea (soft delete) per proteggersi da eliminazioni accidentali o dannose.
Per gli Azure Disks che ospitano carichi di lavoro specializzati, aggiungi Azure Disk Backup basato su Backup vault per acquisire snapshot incrementali indipendenti dagli agenti del sistema operativo guest. Questo diversifica le opzioni di ripristino.
Abilita il ripristino tra aree geografiche sui vault che utilizzano storage con ridondanza geografica, consentendo ripristini a livello di piano dati (data-plane) dall’area geografica secondaria durante interruzioni parziali del piano di controllo (control-plane).

Orchestrazione del DR e convalida dell’RTO

Configura Azure Site Recovery per tutti i servizi non replicati in modo nativo (ad es. servizi Windows legacy). Crea piani di ripristino che sequenziano la preparazione del database, poi delle API, poi del web, e includi runbook di Azure Automation per aggiornare i riferimenti a Key Vault, svuotare le cache CDN tramite le regole di Front Door e invertire la priorità di Traffic Manager per gli endpoint non HTTP.
Pianifica failover di test trimestrali in VNet isolate utilizzando dati mascherati per verificare i runbook, misurare la durata effettiva del failover e perfezionare le prenotazioni di capacità. Dopo i test, ripulisci gli artefatti e rivedi le metriche rispetto all’obiettivo RTO di 15 minuti.

Routing globale per protocolli misti

Per HTTP/S, Front Door gestisce il failover basato sullo stato di salute e la sicurezza perimetrale. Per i protocolli non HTTP (ad es. integrazioni TCP con i partner), distribuisci un Cross-region Load Balancer con Standard Load Balancer regionali come endpoint figli. Gli health probe rimuovono istantaneamente le aree geografiche guaste, mantenendo la connettività senza dipendenze dal TTL del DNS. Laddove sia necessario il geofencing a livello DNS (endpoint normativi), sovrapponi il routing geografico di Azure Traffic Manager agli endpoint specifici dell’area geografica.

Perché questi servizi

Le Availability Zones e i frontend con ridondanza di zona eliminano i guasti di una singola zona con un impatto minimo sulla latenza. I gruppi di failover di Azure SQL astraggono la gestione delle connessioni e automatizzano il failover, allineandosi con l’RTO di 15 minuti. Le scritture multi-region di Cosmos DB soddisfano i requisiti di disponibilità ultra-elevata e di bassa latenza di scrittura a livello globale. Le opzioni GZRS e RA forniscono durabilità zonale e regionale con compromessi controllati sull’RPO. Front Door offre accelerazione globale, failover consapevole dell’applicazione e WAF perimetrale. Cross-region Load Balancer e Traffic Manager coprono le esigenze di routing non HTTP e geografico. Azure Backup e ASR forniscono percorsi di ripristino indipendenti — dai ripristini point-in-time al failover completo dello stack — garantendo che la piattaforma possa riprendersi sia da guasti infrastrutturali che da corruzione logica dei dati.

← Reti e connettività · Tutti i domini · Architettura della sicurezza e Zero Trust →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →