RTO, RPO e livelli di disaster recovery
Definire Recovery Time Objective e Recovery Point Objective, associarli ai livelli di costo e comprendere quali impegni SLA supporta ogni strategia di DR
RTO, RPO e livelli di disaster recovery è una lezione Cloud & IT Cert Prep gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cloud & IT Cert Prep, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.
Comprendere RTO e RPO
Il Recovery Time Objective (RTO) è il tempo massimo accettabile che può trascorrere dal verificarsi di un disastro fino al ripristino del sistema operativo. Se l'RTO è di 4 ore, l'azienda può tollerare 4 ore di inattività. Il Recovery Point Objective (RPO) è la quantità massima accettabile di dati persi, misurata in termini di tempo: se l'RPO è di 1 ora, deve essere possibile eseguire il ripristino a un punto non antecedente di oltre 1 ora al disastro. Entrambe le metriche sono definite dai requisiti aziendali, non da preferenze tecniche.
# RTO and RPO definitions:
# RTO = max time system can be DOWN
# Example: RTO=4h means restore within 4 hours
#
# RPO = max data LOSS acceptable
# Example: RPO=1h means no more than 1 hour of data lost
#
# Lower RTO and RPO = more expensive DR strategy
# Higher RTO and RPO = cheaper but more business impactI quattro livelli di DR
AWS definisce quattro strategie principali di Disaster Recovery, ordinate dal costo più basso / RTO più alto al costo più alto / RTO più basso: 1) Backup e ripristino: la più economica, con un RTO di alcune ore. 2) Pilot Light: il nucleo minimo è sempre in esecuzione, con un RTO da alcuni minuti ad alcune ore. 3) Warm Standby: una copia ridotta ma funzionale, con un RTO di alcuni minuti. 4) Multi-Site Active-Active: la più costosa, con un RTO quasi nullo. La scelta dipende dal costo aziendale dell'inattività rispetto al costo dell'infrastruttura di DR.
# DR Strategy comparison:
# Strategy | RTO | RPO | Cost
# Backup & Restore | Hours | Hours | Lowest
# Pilot Light | Minutes+ | Minutes | Low
# Warm Standby | Minutes | Seconds | Medium
# Active-Active | ~0 | ~0 | HighestStrategia di backup e ripristino
Con la strategia di Backup e ripristino, si creano regolarmente snapshot dei dati e li si memorizza in un'altra posizione (ad esempio, S3 con replica tra regioni). In caso di disastro, si esegue il ripristino dal backup più recente. Questa è la strategia più economica perché non richiede infrastruttura standby in esecuzione. Il compromesso consiste nell'RTO più lungo (possono servire ore per ripristinare database di grandi dimensioni dagli snapshot) e nell'RPO più alto (i dati creati dopo l'ultimo backup vengono persi). AWS Backup automatizza la pianificazione degli snapshot per EC2, RDS, EFS, DynamoDB e altri servizi.
# Create AWS Backup plan for RDS
aws backup create-backup-plan \
--backup-plan '{
"BackupPlanName": "daily-backup",
"Rules": [{
"RuleName": "daily",
"TargetBackupVaultName": "dr-vault",
"ScheduleExpression": "cron(0 5 ? * * *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {
"DeleteAfterDays": 35
},
"CopyActions": [{
"DestinationBackupVaultArn": "arn:aws:backup:us-west-2:123:backup-vault:dr-vault"
}]
}]
}'Strategia Pilot Light
La strategia Pilot Light mantiene in esecuzione i componenti principali del sistema in una regione di DR, a capacità minima: come una fiamma pilota che può rapidamente accendere la fiamma completa. In genere, ciò significa replicare continuamente il database nella regione di DR e mantenere l'infrastruttura di rete di base (VPC, subnet, gruppi di sicurezza). I server applicativi NON sono in esecuzione, ma possono essere avviati rapidamente da AMI o modelli di avvio preconfigurati. L'RTO è in genere compreso tra 30 minuti e diverse ore, a seconda del lavoro manuale necessario.
# Pilot Light: what runs in DR region at all times
# - RDS Read Replica (continuously replicated)
# - Core VPC/networking infrastructure
# - Route 53 DNS (inactive until failover)
# What is NOT running (launched during failover):
# - EC2 application servers
# - ELB (or dormant)
# Failover steps:
# 1. Promote RDS Read Replica to standalone
# 2. Scale up EC2 instances from launch template
# 3. Update Route 53 to point to DR regionStrategia Warm Standby
La strategia Warm Standby esegue una copia completamente funzionale e ridotta dell'ambiente di produzione nella regione di DR. A differenza di Pilot Light, il livello applicativo è in esecuzione (ad esempio, con 1-2 istanze invece di 20) e il database è un database secondario Aurora Global Database o una replica di lettura RDS. Durante il failover, si aumenta la capacità dell'ambiente di DR fino a raggiungere quella della produzione. L'RTO è in genere inferiore a 15 minuti. Questa è la strategia di DR più comune per i carichi di lavoro di criticità medio-alta.
# Warm Standby: DR region runs scaled-down version
# Production: 10 EC2 instances (ASG min=10, max=50)
# DR Standby: 2 EC2 instances (ASG min=2, max=50)
# During failover:
# 1. Route 53 health check fails for primary
# 2. DNS switches to DR ALB
# 3. ASG in DR scales up from 2 to 10+
# 4. Promote Aurora Global DB secondary
# Total failover time: ~5-15 minutesStrategia Multi-Site Active-Active
La strategia Multi-Site Active-Active esegue contemporaneamente la capacità completa di produzione in due o più regioni. Tutte le regioni gestiscono traffico reale e i dati vengono replicati quasi in tempo reale (o con replica multi-master). Non vi è alcun ritardo di failover: quando una regione si guasta, Route 53 o Global Accelerator instrada immediatamente tutto il traffico verso le regioni integre rimanenti. Questa strategia offre l'RTO e l'RPO più bassi, ma anche il costo più elevato, poiché si paga costantemente la capacità completa di produzione in tutte le regioni.
# Active-Active: full capacity in both regions
# us-east-1: ASG 10 instances (serving ~50% traffic)
# eu-west-1: ASG 10 instances (serving ~50% traffic)
# Route 53 weighted routing:
# us-east-1: weight=50
# eu-west-1: weight=50
# Both records have health checks
# On us-east-1 failure:
# Health check fails -> Route 53 removes us-east-1
# eu-west-1 receives 100% traffic
# ASG in eu-west-1 scales up automaticallyRPO e tecnologia di replica dei dati
L'RPO determina direttamente la tecnologia di replica necessaria. Un RPO = 0 richiede la replica sincrona: non viene perso nulla. Un RPO espresso in secondi richiede una replica asincrona quasi in tempo reale, come Aurora Global Database (latenza <1s). Un RPO espresso in minuti consente la replica asincrona con una latenza ridotta (DynamoDB Streams, repliche di lettura RDS). Un RPO espresso in ore è ottenibile con snapshot periodici (pianificazione oraria di AWS Backup). Definisca chiaramente il requisito aziendale di RPO prima di scegliere una tecnologia.
# RPO requirements mapped to replication technology:
# RPO = 0: RDS Multi-AZ (synchronous)
# RPO < 1 second: Aurora Global Database
# RPO < 1 minute: DynamoDB Global Tables
# RPO < 15 min: RDS Read Replica
# RPO < 1 hour: AWS Backup hourly schedule
# RPO < 24 hours: AWS Backup daily scheduleDR per architetture serverless
Le architetture serverless (Lambda, DynamoDB, API Gateway) sono naturalmente più resilienti, ma richiedono comunque una pianificazione del DR. DynamoDB Global Tables offre una configurazione multi-regione active-active per il livello database. Lambda può essere distribuito in una seconda regione dalla stessa pipeline CI/CD. API Gateway deve essere predisposto nella regione di DR. Il rischio principale è la deriva della configurazione tra le regioni: usi AWS CDK o Terraform per distribuire un'infrastruttura identica in entrambe le regioni a partire dalla stessa base di codice.
# Deploy Lambda to multiple regions with CDK
# cdk.json environment configuration:
{
'primary': {
'account': '123456789',
'region': 'us-east-1'
},
'dr': {
'account': '123456789',
'region': 'us-west-2'
}
}
# Deploy to both:
# cdk deploy --context env=primary
# cdk deploy --context env=drEsempi di compromesso tra RTO e costi
Consideri un'azienda con un fatturato annuo di 10 milioni di dollari. Se l'inattività costa 1.000 dollari al minuto, un'interruzione di 8 ore (RTO=8h) costa 480.000 dollari. Una configurazione warm standby active-passive con RTO=15 minuti riduce la perdita potenziale a 15.000 dollari per incidente. Se lo standby costa 5.000 dollari al mese (60.000 dollari all'anno), è economicamente conveniente solo se si verifica più di un'interruzione significativa all'anno. Questa analisi di giustificazione dei costi è esattamente ciò che l'esame SAA-C03 richiede di eseguire quando si scelgono le strategie di DR.
# DR cost justification formula:
# Annual cost of DR infrastructure
# vs
# Expected annual outage cost
# = P(outage) x downtime_duration x cost_per_minute
#
# Example:
# P(annual outage) = 0.1 (10% chance per year)
# downtime = 8 hours = 480 minutes
# cost = $1000/min
# Expected loss = 0.1 x 480 x $1000 = $48,000/year
#
# If warm standby costs $30,000/year -> worth itTest e documentazione del DR
Un piano di DR che non è mai stato testato è solo un documento. AWS raccomanda vivamente di svolgere regolarmente esercitazioni di DR: faccia pratica con le procedure di failover, misuri l'RTO e l'RPO effettivi e individui le lacune. Usi AWS Fault Injection Simulator (FIS) per simulare in modo controllato il degrado di una regione. Documenti i runbook con i passaggi del failover, affinché durante un incidente reale il team reperibile segua una procedura chiara e verificata invece di improvvisare.
# DR drill checklist:
# 1. Notify stakeholders (planned drill)
# 2. Initiate failover (Route 53 health check override)
# 3. Measure time from trigger to traffic in DR region (RTO)
# 4. Measure data consistency between regions (RPO)
# 5. Test all critical application functions in DR
# 6. Failback to primary region
# 7. Document actual RTO/RPO vs target
# 8. Update runbooks with lessons learnedRequisiti di conformità e DR
Molti settori prevedono requisiti normativi per il DR. PCI DSS richiede piani di DR documentati e sottoposti a test. HIPAA richiede procedure di backup dei dati e disaster recovery. SOC 2 valuta i controlli di disponibilità, incluso il DR. Usi AWS Config e AWS Audit Manager per valutare e documentare continuamente che le risorse di DR (backup, repliche, controlli di integrità) siano configurate correttamente. In questo modo è possibile fornire le prove necessarie per gli audit di conformità senza raccoglierle manualmente.
# AWS Config rule to check RDS backup retention
aws configservice put-config-rule \
--config-rule '{
"ConfigRuleName": "rds-backup-enabled",
"Source": {
"Owner": "AWS",
"SourceIdentifier": "DB_INSTANCE_BACKUP_ENABLED"
},
"InputParameters": "{\"backupRetentionMinimum\":\"7\"}"
}'Verifica rapida
Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.
Riepilogo della lezione
In questa lezione ha imparato che: RTO è il tempo massimo di inattività accettabile e RPO è la perdita massima di dati accettabile, i quattro livelli di DR bilanciano i costi e la velocità di ripristino e il requisito RPO determina la tecnologia di replica da utilizzare. Verifichi sempre il piano di DR per convalidare l'RTO e l'RPO effettivi. Ora analizzeremo in dettaglio la strategia Backup and Restore.
Domande Frequenti
La lezione «RTO, RPO e livelli di disaster recovery» è gratuita?
Sì — il testo completo di «RTO, RPO e livelli di disaster recovery» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cloud & IT Cert Prep, passa a CoddyKit PRO. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.
Cosa imparerò in «RTO, RPO e livelli di disaster recovery»?
Definire Recovery Time Objective e Recovery Point Objective, associarli ai livelli di costo e comprendere quali impegni SLA supporta ogni strategia di DR Eserciti Cloud & IT Cert Prep con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Cloud & IT Cert Prep?
Non è richiesta alcuna esperienza precedente. Cloud & IT Cert Prep su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.
Quanto tempo richiede la lezione «RTO, RPO e livelli di disaster recovery»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Cloud & IT Cert Prep?
Sì. Ogni lezione Cloud & IT Cert Prep include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- RTO, RPO e livelli di disaster recovery
- Backup e ripristino
- Pilot Light e Warm Standby
- Active-active multi-site con Global Tables e Route 53