Amazon SAP-C02: Resilienza, Disaster Recovery e alta disponibilità — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Pianificazione di RTO e RPO: quantificare la tolleranza e mappare l’architettura

L’RTO (Recovery Time Objective) e l’RPO (Recovery Point Objective) guidano ogni scelta di resilienza, dal dimensionamento delle risorse di calcolo alla topologia di replica. Iniziate classificando i carichi di lavoro in base all’impatto sul business e al costo del downtime, quindi traducete tali priorità in obiettivi misurabili: RPO nell’ordine dei millisecondi richiedono una replica sincrona o database globali appositamente costruiti, mentre RPO da minuti a ore consentono la replica asincrona, la pianificazione di snapshot o il trasferimento di log in batch. Utilizzate servizi AWS in linea con gli obiettivi: Amazon Aurora Multi‑AZ e Aurora Global Database per RTO/RPO bassi su larga scala, RDS Multi‑AZ per l’alta disponibilità sincrona in una singola Regione, repliche di lettura cross-Regione per il ripristino e il reporting, e AWS Elastic Disaster Recovery (DRS) per la replica quasi in tempo reale di server on-premise con modifiche minime all’applicazione. Una trappola comune è progettare solo per sostenere il carico medio anziché le operazioni di ripristino nel caso peggiore; un’altra è presumere che i soli snapshot soddisfino l’RPO per i sistemi transazionali, poiché gli snapshot possono essere distanziati di minuti e potrebbero non avere consistenza a livello di applicazione. I compromessi decisionali sono chiari: la replica sincrona aumenta i costi e la latenza di scrittura ma abbassa l’RPO; la replica asincrona riduce la latenza e i costi ma aumenta la potenziale perdita di dati. Testate il piano con chaos testing, failover pianificati ed esercitazioni di ripristino per convalidare i valori effettivi di RTO/RPO e identificare dipendenze nascoste come autenticazione esterna, DNS o whitelist di IP.

Architetture Multi‑AZ e Multi-Regione e strategie di failover

Le architetture Multi‑AZ proteggono dai guasti di una AZ posizionando risorse di calcolo, rete e storage ridondanti in più Zone di Disponibilità; le architetture Multi-Regione estendono la tolleranza a guasti a livello di regione, disastri naturali o grandi partizioni di rete. Scegliete un pattern architetturale — pilot light, warm standby, active-passive o active-active — in base ai costi e alle esigenze di ripristino. Il pattern pilot light utilizza risorse minime in una Regione secondaria per ridurre i costi e si espande durante il failover; il warm standby mantiene in esecuzione servizi ridimensionati per un ripristino più rapido; l’active-active gestisce il traffico in più Regioni per ottenere l’RTO più basso, ma richiede una solida replica dei dati e la risoluzione dei conflitti. Utilizzate Route 53 con health check e routing di failover, Amazon CloudFront o Global Accelerator per la gestione del traffico globale e servizi dati come DynamoDB Global Tables o Aurora Global Database per la replica cross-Regione. Le trappole comuni includono l’affidarsi a TTL del DNS troppo lunghi, non convalidare il failover di servizi stateful (archivi di sessione, cache) e trascurare i costi di trasferimento dati cross-Regione e i vincoli di conformità. Valutate il compromesso tra la complessità e il costo di un’implementazione multi-Regione rispetto a downtime e perdita di dati accettabili; in caso di dubbio, strumentate e modellate i tempi di failover per supportare il business case.

Pattern di resilienza applicativa: statelessness, disaccoppiamento e gestione dello stato

Progettate per il fallimento (design for failure) minimizzando lo stato legato ai singoli nodi di calcolo e disaccoppiando i componenti in modo che i guasti parziali non si propaghino a cascata. Nodi applicativi stateless dietro un Application Load Balancer o un Network Load Balancer consentono la scalabilità orizzontale e la sostituzione rapida. Per lo stato di sessione, preferite archivi esterni come Amazon DynamoDB o Amazon ElastiCache anziché le sessioni sticky; per la condivisione di file, utilizzate Amazon S3, Amazon EFS o FSx a seconda del protocollo e delle esigenze di performance. I pattern asincroni che utilizzano Amazon SQS, SNS o Kinesis assorbono i picchi di carico, abilitano i tentativi di ripetizione (retry) e gestiscono la contropressione (backpressure), riducendo le dipendenze sincrone durante il failover. Implementate nei client pattern come circuit breaker, bulkhead ed exponential backoff per isolare i sottosistemi in errore. Una trappola frequente per gli architetti è sottovalutare i tempi di cold-start o di scale-up: i limiti di concorrenza di Lambda, i cooldown di Auto Scaling e le strategie di warm-up influiscono sull’RTO. Un’altra è trattare la cache come se fosse uno storage durevole; le cache devono poter essere ricostruite. Le scelte di compromesso tra costo e resilienza si manifestano nel dimensionamento dei buffer e nella replica: una maggiore resilienza richiede spesso più capacità riservata o una replica cross-Regione, aumentando i costi; scegliete la ridondanza minima praticabile (minimum viable redundancy) che soddisfi RTO/RPO, garantendo al contempo l’osservabilità e l’automazione per rilevare i guasti e porvi rimedio.

Backup, replica, governance e prontezza operativa

I backup sono un’assicurazione; gli aspetti cruciali sono la coerenza, la sicurezza, la conservazione e la ripristinabilità. Utilizzare AWS Backup per policy di backup centralizzate su EBS, RDS, DynamoDB, EFS e FSx e imporre copie di backup cross-account e cross-Region per la resilienza geografica. Per i dati a oggetti, abilitare il versioning di S3 con regole di Lifecycle e la S3 Replication (CRR) per la durabilità cross-Region. Garantire snapshot coerenti con l’applicazione (application-consistent) per database e file system Windows sfruttando i backup nativi dei database, gli snapshot automatici di RDS o AWS DRS con supporto VSS. La replica cross-account e il principio del privilegio minimo (least-privilege) di IAM sono essenziali per prevenire cancellazioni accidentali. Esercitazioni di ripristino regolari rivelano problemi come ruoli IAM mancanti, configurazioni di rete (sovrapposizioni di CIDR dei VPC) o integrazioni esterne. Automatizzare i runbook con Systems Manager Automation e codificare le procedure di failover in CloudFormation o Terraform per ridurre l’errore umano. Le trappole comuni includono l’affidarsi esclusivamente a snapshot point-in-time senza possibilità di esportazione, non crittografare i backup con chiavi gestite dal cliente (customer-managed key) e non monitorare il successo dei processi di backup. Bilanciare i costi di conservazione e archiviazione con i requisiti normativi; trasferire i backup più vecchi su S3 Glacier per il controllo dei costi, mantenendo i backup recenti rapidamente accessibili per ripristini veloci.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Events Inc., un’azienda globale di eventi dal vivo, gestisce un’applicazione di ticketing in una singola Regione AWS utilizzando gruppi di EC2 Auto Scaling dietro un ALB, con un cluster PostgreSQL a 3 nodi su EC2 in una AZ e snapshot EBS notturni. L’organizzazione deve ridurre l’RTO a meno di 10 minuti e l’RPO a meno di 5 minuti, minimizzando al contempo il carico operativo e i costi.

Sfida: Ottenere una disponibilità quasi continua e una bassa perdita di dati per il database tra diverse AZ/Regioni, con un failover prevedibile e modifiche minime all’applicazione.

Approccio Consigliato:

1. Configurare Amazon RDS for PostgreSQL con un’implementazione Multi‑AZ o migrare ad Amazon Aurora PostgreSQL con Multi‑AZ e abilitare backup continui automatici ed esportazioni rapide degli snapshot; abilitare i backup automatici con una finestra di conservazione appropriata.
2. Aggiungere la replica cross-Region utilizzando Aurora Global Database (o la replica logica/fisica di RDS verso una read replica in una Regione secondaria) per raggiungere gli obiettivi di RPO geografici, e configurare il routing basato sulla latenza di Route 53 con health check per consentire un failover di Regione controllato.
3. Sostituire il PostgreSQL su EC2 in una singola AZ con un servizio gestito per eliminare la manutenzione degli host, e rifattorizzare la logica di connessione dell’applicazione per utilizzare gli endpoint del cluster o RDS Proxy per il connection pooling e una gestione più rapida del failover.
4. Implementare la verifica continua della replica e l’automazione dei runbook: esercitazioni di failover pianificate utilizzando Systems Manager Automation e template di CloudFormation per una rapida ricreazione delle risorse; strumentare le metriche e attivare allarmi tramite CloudWatch e SNS.

Motivazione: L’uso di servizi di database gestiti e Multi-AZ e della replica cross-Region riduce la complessità operativa e soddisfa obiettivi di RTO/RPO aggressivi; l’automazione e le esercitazioni periodiche assicurano che il piano funzioni nella pratica, mentre RDS/Aurora minimizzano i passaggi manuali e il tempo di failover.

← Migrazione e modernizzazione · Tutti i domini · Ottimizzazione dei costi e governance →

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

Sfoglia Amazon →