Amazon DOP-C02: Alta Affidabilità, Resilienza e Disaster Recovery — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’alta disponibilità e il disaster recovery su AWS si concentrano sulla riduzione dei tempi di inattività (RTO) e della perdita di dati (RPO) in caso di guasti a livello di componente, di Zona di Disponibilità (AZ) o di Regione. Le architetture Multi-AZ assorbono i guasti a livello di AZ senza perdita di dati e con un impatto minimo sul servizio; le architetture multi-Regione gestiscono le interruzioni a livello di Regione e gli eventi su larga scala. La scelta tra le strategie active/active, active/passive (warm standby) e pilot-light è guidata dagli obiettivi di RTO/RPO aziendali, dai requisiti di coerenza e dai costi. Il raggiungimento di questi obiettivi richiede una progettazione coerente che includa il routing DNS, l’elasticità delle risorse di calcolo, il bilanciamento del carico, la replica/failover dei database, lo storage a oggetti durevole con replica/versioning, il backup centralizzato e la verifica continua della resilienza tramite fault injection.

Architetture per RTO/RPO e routing intelligente

Architetture Multi-AZ e multi-Regione:

Multi-AZ: Posizionare istanze ridondanti in almeno due sottoreti in diverse AZ dietro un load balancer. Utilizzare database gestiti con replica sincrona (RDS Multi-AZ, cluster Aurora Multi-AZ). L’RPO è tipicamente zero per lo storage sincrono; gli obiettivi di RTO variano da meno di un minuto (Aurora) a pochi minuti (failover di RDS Single-Instance Multi-AZ).
Multi-Regione: Scegliere active/active per l’RTO più basso con isolamento regionale e bassa latenza, oppure warm standby/pilot light per un DR ottimizzato in termini di costi. La replica dei dati deve soddisfare l’RPO: repliche asincrone di DB, Aurora Global Database (RPO tipico <1 s), tabelle globali di DynamoDB (multi-Regione, multi-attivo) e S3 Cross-Region Replication (CRR) con Replication Time Control (RTC) opzionale per una replica supportata da SLA.

Policy di routing e health check di Route 53:

Routing di failover: Creare due record per lo stesso nome: Primary e Secondary. Associare un health check al record Primary (o usare “Evaluate Target Health” per gli alias verso ALB/NLB). In caso di guasto, il traffico viene spostato sul record Secondary. Mantenere un TTL basso (es. 60 s) per ridurre il ritardo della cache DNS e monitorare lo stato degli health check con gli allarmi di CloudWatch.
Routing basato sulla latenza: Indirizzare gli utenti verso la Regione con la latenza misurata più bassa. Associare health check a ogni record per garantire che solo gli endpoint sani ricevano traffico. Abbinare a stack multi-Regione e datastore regionali che supportano la coerenza finale (eventual) o forte (strong) a seconda dei requisiti.
Routing ponderato: Suddividere il traffico per percentuale per supportare rilasci canary, test A/B o una preparazione al DR “a goccia” (ad esempio, l'1% del traffico inviato continuamente al secondario). Combinare con health check in modo che i pesi associati a endpoint non sani vengano esclusi. Utilizzare uno spostamento graduale dei pesi per migrare il traffico durante un’evacuazione regionale.
Health check: Eseguire probe su endpoint HTTP(S)/TCP o su allarmi di CloudWatch. Per gli alias di ALB/NLB, abilitare “Evaluate Target Health” per ereditare lo stato di salute del target group. Progettare gli endpoint di health check in modo che riflettano la reale prontezza (dipendenze raggiungibili, migrazioni applicate). Per le applicazioni stateful, includere controlli sulle dipendenze (database, cache) per evitare di indirizzare il traffico verso istanze parzialmente sane.

Pattern di resilienza per obiettivo:

RPO basso, RTO inferiore al minuto a livello globale: Architettura active/active con routing basato sulla latenza e health check di Route 53, risorse di calcolo stateless locali per regione, tabelle globali di DynamoDB o Aurora Global Database, S3 CRR con RTC per gli oggetti critici.
RPO moderato (≤15 min), RTO ≤4 ore: Architettura warm standby con un ambiente secondario a capacità ridotta (scaled-down), replica asincrona del DB (read replica cross-Regione di RDS o Aurora Global), routing di failover di Route 53, runbook o automazione per scalare e promuovere l’ambiente secondario durante il failover.
DR ottimizzato per i costi: Architettura pilot light solo per i servizi dati principali, infrastructure-as-code per scalare il livello applicativo al momento dell’attivazione, RPO determinato dalla frequenza di replica, RTO determinato dal tempo di provisioning e di recupero dei dati.

Elastic Load Balancing e Auto Scaling

Elastic Load Balancing:

Application Load Balancer (ALB): Layer 7, routing basato su host/path, WebSocket/HTTP/2, WAF integrato, stickiness tramite cookie del target group e health check basati su richiesta. Utilizzare il cross-zone load balancing e il deregistration delay (connection draining) per drenare gradualmente i target durante lo scale-in o i deployment. Configurare lo slow start e l’outlier detection per un warm-up non uniforme del backend.
Network Load Balancer (NLB): Layer 4, latenza ultra-bassa, IP statici/Elastic IP, TLS pass-through/termination, preserva l’IP di origine e supporta connessioni di lunga durata. Da utilizzare per protocolli TCP/UDP, carichi di lavoro a throughput elevato o dove la visibilità dell’IP del client è obbligatoria. Gli health check sono TCP/HTTP/HTTPS a Layer 4/7 come configurato.
Connection draining (deregistration delay): Impostare un ritardo appropriato (ad esempio, 60–300 s) per consentire il completamento delle richieste in transito (in-flight). Assicurarsi che gli eventi di deployment e di terminazione dell’Auto Scaling rispettino questo ritardo per evitare interruzioni per l’utente.

Gruppi di Auto Scaling:

Policy di scalabilità:
- Target tracking scaling: Mantiene una metrica (CPUUtilization, ALB RequestCountPerTarget) a un valore target. È la policy più semplice e adattiva per flotte di server web/API.
- Step scaling: Scala secondo step definiti quando le metriche superano le soglie. Utile per traffico con picchi (bursty) e pattern prevedibili.
- Scheduled scaling: Scala in anticipo per eventi noti (saldi, lanci) per evitare capacità a freddo (cold capacity).
- Predictive scaling: Opzionalmente, prevede la domanda utilizzando il ML per pattern giornalieri/settimanali.
Lifecycle hooks: Launching:Wait e Terminating:Wait consentono di controllare la prontezza (readiness) e la dismissione (teardown) delle istanze. Utilizzare gli hook per:
- Eseguire il bootstrap delle istanze (SSM Automation, completamento dei user data, idratazione dell’AMI) prima che entrino in servizio.
- Raccogliere log e artefatti prima della terminazione per l’analisi delle cause principali (root cause analysis).
- Coordinare deployment blue/green o in-place che devono confermare segnali di prontezza (ad es., cfn-signal).
Warm pools: Mantengono istanze pre-inizializzate nello stato Stopped o Running, collegate all’ASG, per ridurre drasticamente la latenza di scale-out. I warm pool si abbinano bene a lunghi processi di bootstrap (installazione di pacchetti di grandi dimensioni, download di modelli). Configurare una capacità minima riscaldata (warmed capacity) e le policy di riutilizzo. Combinare con il lifecycle hook Launching:Wait per completare l’hook solo quando i controlli di prontezza dell’app hanno successo, garantendo tempi di cutover consistenti.
Impostazioni di resilienza: Abilitare Capacity Rebalance per le istanze Spot, più tipi/allocazioni di istanze, health check legati allo stato del target group e instance refresh per aggiornamenti progressivi (rolling update) sicuri con barriere di protezione (health guardrails).

Resilienza, replica e backup del data layer

Database relazionali:

RDS Multi-AZ: Replica sincrona su un’istanza di standby in una diversa AZ; il failover automatico aggiorna l’endpoint DNS puntando allo standby. Questo protegge da guasti di AZ e di istanza con un RPO ≈ 0 e un RTO tipicamente di pochi minuti per istanze DB Single-AZ con standby Multi-AZ. La più recente opzione Multi-AZ DB cluster per MySQL/PostgreSQL offre un failover più rapido con più istanze di standby leggibili.
Read replicas: Replica asincrona per la scalabilità in lettura e per il DR. Utilizzare read replica cross-Region per il DR; la promozione è manuale (o automatizzata con runbook/funzioni Serverless) e comporta un RPO > 0. Assicurarsi che la replica binlog o logica sia configurata correttamente e che il ritardo di replica (replication lag) sia monitorato.
Aurora: Aurora Multi-AZ (cluster) utilizza uno storage condiviso con repliche in più AZ; il failover è generalmente inferiore al minuto. Aurora Global Database fornisce una replica fisica basata sullo storage verso Regioni secondarie con RPO tipico < 1 s e RTO < 1 min. Utilizzare il failover pianificato gestito (managed planned failover) per migrazioni a zero perdita di dati, o il failover non pianificato per eventi di disastro. Gli endpoint writer/reader astraggono la topologia; le applicazioni dovrebbero implementare tentativi di riconnessione con backoff (retry with backoff).

Object storage e DR:

S3 Versioning: Abilitare il versioning per proteggere da sovrascritture/cancellazioni e per supportare la CRR. Configurare le policy di lifecycle per trasferire le versioni più vecchie su storage più economici e impostare una retention appropriata.
S3 Cross-Region Replication (CRR): Richiede il versioning abilitato sui bucket di origine e di destinazione. Utilizzare un ruolo IAM di replica; se i bucket sono in account diversi, aggiungere una policy sul bucket di destinazione che consenta al ruolo di origine le autorizzazioni

undefined

e di put. Per oggetti crittografati con KMS, concedere al ruolo i permessi kms:Decrypt sulla chiave di origine e kms:Encrypt sulla chiave di destinazione. Considerare:

Replication Time Control (RTC) per la replica del 99,9% degli oggetti entro 15 minuti, con metriche/allarmi.
Replica dei delete marker e dei controlli di proprietà (ownership controls) secondo necessità.
S3 Batch Replication per gli oggetti esistenti.
Metriche e notifiche di replica per gli SLA.
DynamoDB: Utilizzare le global table per scenari multi-Regione/multi-writer a bassa latenza e alta disponibilità (HA). In alternativa, abilitare il PITR e i backup on-demand per il ripristino.

Backup centralizzati con AWS Backup:

Piani di backup (Backup plans): Definire pianificazioni (CRON), finestre di backup, lifecycle (transizione a cold storage, retention) e azioni di copia verso altre Regioni/account. Assegnare le risorse tramite tag o ARN per una copertura guidata da policy.
Depositi di backup (Backup vaults): Contenitori logici con chiavi di crittografia KMS e policy di accesso indipendenti. Abilitare AWS Backup Vault Lock per l’immutabilità WORM e una postura resistente ai ransomware. Utilizzare copie dei vault cross-account per ridurre il raggio d’impatto (blast-radius reduction).
Backup cross-account: In Organizations, applicare le policy di backup agli account membri per una governance coerente. Configurare le policy di accesso al vault per consentire la copia/ripristino da un account di backup centralizzato. Eseguire regolarmente test di ripristino automatici (restore drills) per misurare l’RTO e convalidare i runbook.
Integrazioni: Proteggere EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx e altro. Allineare la pianificazione e la retention agli RPO/RTO normativi e coordinare con il quiescing consistente a livello applicativo (application-consistent quiescing) dove richiesto (script pre/post di SSM).

Chaos engineering e AWS Fault Injection Simulator (FIS)

Gli esperimenti di chaos engineering verificano che i meccanismi di HA (High Availability) e DR (Disaster Recovery) si comportino come previsto. AWS FIS orchestra guasti controllati con dei guardrail (meccanismi di sicurezza):

I template di esperimento definiscono azioni (ad esempio, arrestare o riavviare una percentuale di istanze EC2 in un ASG, iniettare stress sulla CPU o sulla memoria tramite SSM, aggiungere latenza di rete/perdita di pacchetti sulle istanze, terminare pod EKS, arrestare task ECS, attivare il failover di RDS/Aurora) e target (tag di risorsa, ARN).
Controlli di sicurezza: Specificare condizioni di arresto basate su allarmi CloudWatch, limiti di tempo, vincoli sul raggio d’impatto (blast radius) tramite tag/filtri e controlli preliminari (pre-check). Eseguire prima in ambienti di non-produzione, poi in produzione con guardrail rigorosi e l’approvazione del business.
Osservabilità: Strumentare i KPI (tasso di errore, latenza di coda, età degli elementi in coda, ritardo della replica) e verificare le risposte automatiche, incluse le reazioni di Auto Scaling, la convergenza dello stato di salute del load balancer, il failover di Route 53, la promozione del database e il comportamento del circuit breaker.
Resilienza continua: Integrare gli esperimenti nelle pipeline e nei gameday per evitare che il configuration drift eroda la resilienza. Utilizzare Parameter Store o AppConfig per i feature toggle e per coordinare rollout sicuri.

Scenario di un Problema Pratico

Expedia Group gestisce un’API globale per la ricerca di viaggi che deve garantire un RTO inferiore a 60 secondi e un RPO quasi nullo per i dati critici delle prenotazioni, mantenendo al contempo una bassa latenza per gli utenti in Nord America ed Europa. Il team riscontra occasionali cali di servizio a livello regionale (brownout) e instabilità indotta dai deployment, e gli auditor richiedono backup immutabili cross-account ed esercitazioni di DR documentate.

Approccio passo-passo:

Stabilire stack multi-regione, attivo/attivo

Distribuire stack di API stateless in us-east-1 e eu-west-1 su più AZ dietro degli ALB. Utilizzare il routing basato sulla latenza di Route 53 con health check e l’opzione Evaluate Target Health sui record alias. Questo fornisce un routing a bassa latenza e un’evasione automatica della regione se un endpoint non è integro (unhealthy).

Datastore globale a basso RPO

Migrare i dati delle prenotazioni e delle sessioni su Amazon Aurora Global Database (compatibile con MySQL) con us-east-1 come primaria e eu-west-1 come secondaria. Un RPO tipico <1 s e un RTO <1 min soddisfano l’obiettivo in caso di interruzione. Utilizzare gli endpoint del cluster e di lettura (reader) nella configurazione dell’applicazione con meccanismi di retry/backoff per tollerare i failover.

Scalabilità resiliente e transizioni graduali (graceful)

Configurare il target tracking di Auto Scaling su ALB RequestCountPerTarget con una capacità minima in entrambe le regioni. Aggiungere warm pool dimensionati per assorbire picchi di traffico 10 volte superiori durante eventi importanti e lifecycle hook di tipo Launching:Wait per ritardare la registrazione fino al superamento dei controlli di prontezza (readiness check) dell’app. Abilitare un deregistration delay dell’ALB di 120 secondi per preservare le richieste in transito (in-flight) durante lo scale-in e i deployment.

DR per oggetti durevoli

Abilitare il Versioning S3 e la CRR con RTC per i documenti degli itinerari da us-east-1 a eu-west-1. Utilizzare un ruolo IAM dedicato per la replica e chiavi KMS in entrambe le regioni, concedendo l’autorizzazione kms:Decrypt sulla sorgente e kms:Encrypt sulla destinazione. Le metriche e gli allarmi di RTC forniscono fiducia negli SLA di replica.

Controlli DNS per canary e failover

Aggiungere record pesati (weighted) di Route 53 (un flusso costante dell'1% verso eu-west-1) per esercitare continuamente il percorso secondario. In combinazione con gli health check, questo assicura che lo standby sia pronto per la produzione e rileva il drift prima di una crisi.

Backup centralizzati e immutabili

In un account di backup di proprietà del team di sicurezza, creare vault di AWS Backup con Vault Lock e CMK di KMS. Definire policy di backup a livello di organization per pianificare backup giornalieri e copie cross-account per RDS, DynamoDB, EFS ed EBS. Assegnare le risorse tramite il tag Backup_Frequency. Questo permette di ottenere resistenza ai ransomware e separazione dei compiti (separation of duties).

Orchestrazione automatizzata del failover

Implementare una regola EventBridge per rilevare i segnali di guasto della primaria di Aurora e invocare una funzione Lambda che promuove la regione secondaria e aggiorna un endpoint dell’applicazione memorizzato in Parameter Store. Le applicazioni caricano l’endpoint all’avvio e lo aggiornano in caso di errori di connessione, minimizzando i passaggi manuali.

Validazione tramite chaos engineering con AWS FIS

Creare template di esperimento FIS per: terminare il 10% delle istanze dell’ASG, iniettare 150 ms di latenza e l'1% di perdita di pacchetti su EC2 tramite SSM, e attivare il failover di Aurora. Impostare come guardrail delle condizioni di arresto basate su allarmi CloudWatch sulla latenza p95 e sul tasso di errore. Eseguire gameday mensili per validare la velocità del failover di Route 53, il ripristino dell’ASG, la convergenza dello stato di salute dell’ALB e l’RTO della promozione di Aurora.

Perché questi servizi:

Il routing basato sulla latenza e pesato di Route 53 fornisce sia una latenza utente ottimale sia una modellazione controllata del traffico per la prontezza al DR.
ALB più ASG con warm pool e lifecycle hook assicurano una scalabilità rapida e graduale (graceful) senza penalità da cold-start o interruzioni per l’utente.
Aurora Global Database soddisfa in modo unico i requisiti di RPO quasi nullo e RTO inferiore al minuto tra regioni con modifiche minime all’applicazione.
Il Versioning S3 e la CRR con RTC offrono una replica verificabile e supportata da SLA per gli artefatti critici.
AWS Backup con vault cross-account e Vault Lock crea backup immutabili e governati centralmente, in linea con le esigenze di conformità.
AWS FIS fornisce un’iniezione di guasti sicura e automatizzata per dimostrare continuamente la postura di resilienza e impedire che il configuration drift comprometta il piano di DR.

← Container e Operazioni Serverless · Tutti i domini · Architetture Guidate dagli Eventi e Automazione →

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