Amazon SOA-C02: Alta disponibilità, tolleranza ai guasti e ripristino di emergenza — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Meccanismi di failover (health check di Route53, automatizzati)

Il failover automatizzato utilizza health check, policy di routing e orchestrazione. Route53 supporta health check e routing di tipo failover, ponderato (weighted) e basato sulla latenza (latency). Configurare gli health check di Route53 per sondare gli endpoint (HTTP, TCP o allarmi CloudWatch) e un set di record di failover che commuta su una risorsa secondaria quando quella primaria fallisce. Esempio di aggiornamento tramite CLI: aws route53 change-resource-record-sets –hosted-zone-id Z123456 –change-batch file://changes.json. Utilizzare gli allarmi CloudWatch (le azioni degli allarmi attivano AWS Lambda) per orchestrare il failover per azioni non legate al DNS.

Integrare Load Balancer e Auto Scaling: gli health check dei target group di ALB/NLB rimuovono le istanze non integre (unhealthy), mentre Auto Scaling le sostituisce automaticamente. Per il failover dei database, affidarsi a meccanismi a livello di servizio: RDS Multi-AZ o il failover automatizzato di Aurora, e per la promozione cross-region utilizzare le repliche di lettura (read replicas) o la promozione controllata di Aurora Global DB.

Due modelli operativi:

Failover DNS (Route53): veloce da implementare, ma dipendente dal TTL del DNS e dalla cache del client.
Failover del piano di controllo (Lambda/Step Functions + chiamate API): orchestra la promozione, la riassegnazione di IP/EIP e gli aggiornamenti di Route53 in una sequenza prevedibile per applicazioni complesse.

Pianificazione, test e validazione di RTO/RPO

L’RTO è il tempo massimo di inattività accettabile; l’RPO è la perdita massima di dati accettabile. Definire obiettivi misurabili per ogni workload e allineare le scelte architetturali: la replica sincrona riduce l’RPO ma può aumentare la latenza; la replica asincrona riduce i costi ma aumenta la potenziale finestra di perdita dati. Tradurre gli SLA di business in frequenza di conservazione (retention) e di replica: RPO = ritardo di replica (replication lag) + intervallo di backup; RTO = tempo di rilevamento + tempo di orchestrazione del failover + tempo di validazione del ripristino.

Il testing è essenziale: eseguire esercitazioni di DR (Disaster Recovery) pianificate che convalidino le procedure di ripristino, il failover DNS e l’integrità dell’applicazione. Convalidare i backup ripristinandoli in un account o VPC isolato (usare CloudFormation/CloudFormation StackSets o Terraform per automatizzare le ricostruzioni). Raccogliere metriche durante i test (tempo di propagazione DNS, punto di ripristino, controlli a livello di applicazione) e iterare sull’automazione per ridurre l’RTO.

Errori Comuni e Criteri Decisionali

Presumere che gli snapshot equivalgano alla recuperabilità: eseguire sempre i ripristini in un ambiente separato e convalidare la coerenza dell’applicazione; utilizzare snapshot nativi del motore o mettere in stato di quiescenza (quiesce) le applicazioni prima di creare lo snapshot.
Progettare sistemi single-region per workload critici globali: scegliere pattern Multi-Region o warm standby quando un guasto regionale impatta i clienti; considerare la sovranità dei dati (data sovereignty).
Ignorare RTO/RPO in fase di progettazione: definire RTO/RPO per ogni workload e selezionare di conseguenza la replica/i backup; mappare l’RPO alla frequenza di replica e l’RTO all’automazione dell’orchestrazione.
TTL DNS lunghi che bloccano un failover rapido: impostare TTL bassi per i record di failover critici e usare l’accelerazione globale solo quando è richiesto un routing stabile.
Trascurare IAM/permessi per la replica cross-region: la CRR (Cross-Region Replication), la copia di snapshot e l’accesso al backup vault richiedono ruoli e policy di risorsa corretti; testare i percorsi IAM della replica.
Non monitorare il ritardo di replica (replication lag) e lo stato di salute: strumentare le metriche di CloudWatch (ReplicaLag, CPU, rete) e allertare quando le soglie si avvicinano ai limiti di RPO.

Problema Pratico: Scenario d’Uso

AcmePayments gestisce un’API di transazione soggetta a PCI in us-east-1 e necessita di un RTO < 5 minuti e un RPO quasi nullo per i dati transazionali core durante un’interruzione regionale.

Definire RTO=5 min e RPO≈0 selezionando Aurora Global Database con un’istanza primaria scrivibile in us-east-1 e una secondaria in eu-west-1 per una rapida replica cross-region.
Abilitare il Multi-AZ sincrono/per-regione per l’HA intra-regionale (repliche Aurora + Multi-AZ) e pubblicare il DNS tramite Route53 con health check e un TTL basso (60s) per il routing di failover.
Utilizzare snapshot automatizzati cross-region e copie nel vault di AWS Backup come ulteriore copia immutabile con retention e vault lock.
Automatizzare il playbook di failover con Step Functions e Lambda per convalidare la promozione della replica, aggiornare i record di Route53 (aws route53 change-resource-record-sets), eseguire smoke test e fare rollback in caso di fallimenti.
Pianificare esercitazioni di DR trimestrali ripristinando i backup in un VPC isolato e misurare RTO e RPO effettivi, quindi affinare l’automazione e le policy di scaling.

Logica: la combinazione di un prodotto DB globale a bassa latenza (Aurora Global) con un routing basato su DNS e un’orchestrazione automatizzata soddisfa RTO/RPO stringenti, mantenendo al contempo i passaggi operativi ripetibili e testabili. La validazione regolare garantisce che i backup e le repliche siano effettivamente recuperabili.

← Monitoraggio · Tutti i domini · Distribuzione →

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