RTO, RPO e le quattro strategie di DR

Il disaster recovery (DR) parte da due metriche. Il RPO (Recovery Point Objective) è la massima perdita di dati tollerabile, misurata in tempo: risponde a “quanti dati posso permettermi di perdere”. Il RTO (Recovery Time Objective) è il tempo massimo per ripristinare il servizio dopo un disastro. Valori più bassi significano più continuità ma costi più alti: la scelta della strategia è sempre un compromesso fra spesa e questi due obiettivi.

  • Backup & restore: backup copiati in un’altra region (AWS Backup cross-region copy, RDS snapshot copy, S3 Cross-Region Replication) e infrastruttura ricreata on demand da IaC. Costo minimo, ma RTO/RPO nell’ordine di ore. Adatto a workload non critici.
  • Pilot light: i componenti core (tipicamente il database, replicato in continuo) restano accesi e minimali nella region secondaria; il resto dell’ambiente è spento e viene avviato al failover. RPO in minuti, RTO decine di minuti.
  • Warm standby: una copia ridotta ma già funzionante gira nella region DR; al failover si esegue lo scale-up. RPO ed RTO nell’ordine dei minuti.
  • Active-active (multi-site): più region servono traffico contemporaneamente. RPO ed RTO prossimi a zero, ma massima complessità e costo (conflitti di scrittura, coerenza dei dati).

Architetture multi-region

Il routing verso la region attiva si gestisce con Amazon Route 53 (failover routing con health check, oppure latency/weighted routing per l’active-active) o con AWS Global Accelerator per un failover più rapido basato su anycast. L’infrastruttura va sempre descritta come codice (AWS CloudFormation, con StackSets per il deploy multi-region) così da ricrearla in modo identico e ripetibile. La replica dei dati è il cuore dell’architettura: S3 Cross-Region Replication per gli oggetti, DynamoDB Global Tables per tabelle multi-active, e per i database relazionali le opzioni RDS descritte sotto. In active-active la sfida è la coerenza: DynamoDB Global Tables adotta last-writer-wins, mentre le scritture relazionali cross-region restano un problema difficile.

Replica dei database Amazon RDS

  • RDS Multi-AZ NON è DR: è alta disponibilità dentro una singola region, con standby sincrono e failover automatico. Non protegge dalla perdita di un’intera region.
  • RDS cross-region read replica: replica asincrona verso un’altra region; l’RPO dipende dal replication lag. In caso di disastro la replica va promossa a istanza standalone, con RTO più lungo e passaggi manuali.
  • Aurora Global Database: una region primaria in scrittura più region secondarie read-only, con replica a livello di storage dedicata. RPO tipicamente intorno a 1 secondo e RTO di pochi minuti; supporta failover gestito. È l’opzione per RTO/RPO aggressivi su carichi Aurora.
  • AWS Backup: centralizza backup e copie cross-region/cross-account con retention policy, utile per la strategia backup & restore e per la compliance.

Scegliere la strategia dato un RTO/RPO target

Si parte sempre dai numeri target. RTO/RPO di ore → backup & restore. RPO in minuti ma RTO tollerante → pilot light. RTO/RPO in minuti → warm standby. RTO/RPO vicini a zero con budget adeguato → active-active. Per i database, un RPO di secondi impone Aurora Global Database o DynamoDB Global Tables; un RPO più rilassato consente una cross-region read replica. Non pagare per un active-active se il business tollera minuti di downtime.

Trappole tipiche d’esame

  • Serve resilienza al guasto di un’intera region → soluzione: Multi-AZ non basta (è solo HA intra-region); serve un’architettura multi-region con replica dei dati.
  • RPO di circa 1 secondo e RTO di minuti su Aurora → soluzione: Aurora Global Database, non una semplice cross-region read replica (lag variabile e promozione manuale).
  • RTO/RPO di ore con vincolo di costo minimo → soluzione: backup & restore con AWS Backup cross-region, non warm standby (spenderebbe per capacità inutilizzata).
  • Active-active con database relazionale → soluzione: attenzione ai conflitti di scrittura; valutare DynamoDB Global Tables o un singolo writer con Aurora Global Database, non due writer relazionali indipendenti.
  • Failover DNS con recovery rapido → soluzione: Route 53 health check + failover routing (o Global Accelerator per convergenza più veloce), senza affidarsi a TTL lunghi.
  • Orchestrare il DR con OpsWorks → soluzione: è deprecato; usare CloudFormation/StackSets come IaC per ricreare l’ambiente.