Alta disponibilità vs disaster recovery

L’high availability (HA) riduce i tempi di indisponibilità distribuendo i componenti su risorse indipendenti, così che il guasto di una non fermi il servizio. Il disaster recovery (DR) affronta invece eventi più gravi — la perdita di un intero data center o di una Region — con procedure di ripristino verso un ambiente alternativo.

La prima leva è il livello di ridondanza. Un’architettura Multi-AZ replica le risorse su più Availability Zone della stessa Region: le AZ sono isolate fisicamente ma collegate da rete a bassa latenza, quindi coprono guasti hardware, di alimentazione o di una singola zona senza latenza applicativa percepibile. Un’architettura multi-region distribuisce i carichi su Region geograficamente distanti: amplia il blast radius coperto (disastri regionali, data residency, latenza per utenti globali) ma introduce complessità, costi e replica asincrona dei dati per via della distanza.

Regola pratica d’esame: Multi-AZ è la risposta di default per HA dentro una Region; multi-region entra in gioco solo quando il requisito cita esplicitamente resilienza a un guasto regionale o presenza geografica.

Amazon RDS: Multi-AZ e read replica

Sono due meccanismi diversi che l’esame confonde di proposito.

Amazon RDS Multi-AZ crea una standby replica in un’altra AZ con replica sincrona. La standby non serve traffico: esiste solo per la disponibilità. In caso di guasto della primaria, RDS esegue un failover automatico promuovendo la standby e aggiornando il DNS endpoint, tipicamente in uno-due minuti. Serve HA, non scaling.

Le read replica usano replica asincrona e servono a scalare i carichi di sola lettura: indirizzi le query di lettura verso una o più repliche, alleggerendo la primaria. Possono stare in un’altra Region (cross-region read replica), utile sia per servire utenti remoti sia come base per il DR. Non c’è failover automatico: una read replica va promossa manualmente a database indipendente.

Amazon Aurora e Global Database

Amazon Aurora disaccoppia compute e storage: il volume dati è replicato in sei copie su tre AZ, quindi durabilità e resilienza intra-Region sono native. Aurora offre fino a 15 Aurora Replica che condividono lo stesso storage e fungono sia da target di lettura sia da candidati al failover automatico, più rapido rispetto a RDS classico.

Per il multi-region c’è Aurora Global Database: una Region primaria in scrittura e una o più Region secondarie in sola lettura, con replica dedicata a bassa latenza (lag tipicamente sotto il secondo) e possibilità di promuovere una secondaria in caso di disastro regionale, con RTO e RPO nell’ordine dei minuti.

Amazon Route 53: failover e health check

Amazon Route 53 è il DNS che orchestra il routing tra endpoint. Associando una health check a un record e usando la failover routing policy definisci un endpoint primario e uno secondario: se l’health check del primario fallisce, Route 53 smette di rispondere con il suo indirizzo e dirotta il traffico sul secondario. È il collante tipico del DR multi-region. Le altre policy (latency-based, weighted, geolocation) servono a scenari active-active e di ottimizzazione, non al failover puro.

Strategie di DR e RTO/RPO

Il RTO (Recovery Time Objective) è quanto tempo puoi restare giù; il RPO (Recovery Point Objective) è quanti dati puoi permetterti di perdere. Le quattro strategie AWS, dal RTO/RPO più alto (costo minore) al più basso (costo maggiore):

  • Backup & restore: backup su Amazon S3, ripristino on demand. Costo minimo, RTO/RPO in ore.
  • Pilot light: dati replicati in continuo e componenti core spenti, pronti da avviare. RTO in decine di minuti.
  • Warm standby: ambiente ridotto ma sempre attivo, scalato al bisogno. RTO in minuti.
  • Active-active (multi-site): due ambienti che servono traffico insieme. RTO/RPO prossimi a zero, costo massimo.

Il passing score dell’esame è 700/1000: aspettati scenari in cui RTO/RPO desiderati e budget determinano la strategia da scegliere.

Trappole tipiche d’esame

  • “Scalare le letture del database” → read replica, non Multi-AZ: la standby Multi-AZ non serve traffico; solo le read replica alleggeriscono la primaria.
  • “Failover automatico del database” → RDS Multi-AZ o Aurora: le read replica si promuovono a mano, quindi non soddisfano un requisito di failover automatico.
  • “Resilienza a un guasto di intera Region” → multi-region: Multi-AZ copre le AZ dentro una Region, non la perdita della Region stessa; servono cross-region replica, Aurora Global Database o DR multi-region.
  • “RTO/RPO quasi zero” → warm standby scalato o active-active: backup & restore e pilot light hanno RTO troppo alto; se conta anche il costo, warm standby è il compromesso.
  • “Dirottare gli utenti su un sito di backup se il primario è giù” → Route 53 failover routing + health check: non è compito del load balancer, che opera dentro una singola Region.
  • “Minimizzare il costo del DR accettando ore di downtime” → backup & restore: occhio ai distrattori che propongono active-active, tecnicamente valido ma sovradimensionato e costoso.