Amazon SAA-C03: Alta Disponibilità, Tolleranza ai Guasti e Disaster Recovery — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Implementazioni Multi-AZ e Replicazione

Le architetture Multi-AZ gestiscono il guasto di un singolo data center o di una singola Availability Zone, niente di più. Questa distinzione è il punto più frainteso nella progettazione ad alta disponibilità. Un’implementazione Multi-AZ tollera la perdita di una AZ all’interno di una Regione; non tollera un’interruzione a livello di Regione, un degrado di un servizio regionale o la cancellazione accidentale di una risorsa che replica immediatamente la cancellazione sull’istanza di standby. La replicazione propaga fedelmente i dati errati — corruzione logica, errori di schema, scritture da ransomware — motivo per cui la replicazione e il backup sono complementari, non sostitutivi.

Per Amazon RDS, la modalità Multi-AZ predispone una replica di standby sincrona in una diversa AZ. Le scritture vengono confermate (commit) su entrambe le istanze prima della notifica (acknowledgment), fornendo un RPO effettivamente pari a zero e un RTO tipicamente di 60-120 secondi durante il failover automatico. Nella classica implementazione Multi-AZ a istanza, la standby non è leggibile: esiste esclusivamente per la durabilità e il failover. Le implementazioni Multi-AZ a cluster (due standby leggibili) riducono ulteriormente il tempo di failover e forniscono una certa scalabilità in lettura, ma rimangono comunque confinate in una singola Regione.

Per la scalabilità in lettura, si aggiungono repliche di lettura (read replica). Le repliche di lettura utilizzano la replicazione asincrona ed esistono per alleggerire il carico di query di reporting, analisi e dashboard. Trattare una replica di lettura come un meccanismo di failover per l’alta disponibilità (HA) è sbagliato per tre motivi: la replicazione è asincrona (perdita di dati durante la promozione), la promozione è manuale o tramite script (non automatica) e l’endpoint primario non viene preservato. Quando un carico di lavoro in crescita necessita di maggiore capacità di lettura senza aggiungere complessità, si aggiunge una replica di lettura; quando il requisito è un failover automatico con zero perdita di dati, si usa il Multi-AZ. Quando RPO/RTO devono resistere a un guasto di Regione per un motore relazionale, Aurora Global Database fornisce una latenza di replicazione cross-region inferiore al secondo e un RTO di failover gestito inferiore al minuto.

Amazon ElastiCache segue lo stesso schema con i gruppi di replicazione. Un gruppo di replicazione Redis con Multi-AZ abilitato mantiene un’istanza primaria e una o più repliche distribuite tra le AZ; se il primario si guasta, ElastiCache promuove una replica e aggiorna l’endpoint primario. Per la scalabilità orizzontale, Redis (con la modalità cluster abilitata) partiziona i dati su più shard, dove ogni shard è a sua volta un gruppo di replicazione. Memcached, al contrario, non replica: la perdita di un nodo significa la perdita dei dati per quella partizione.

Amazon FSx offre tipi di implementazione Multi-AZ per FSx for Windows File Server e FSx for ONTAP, utilizzando la replicazione sincrona tra un file server preferito e uno di standby. FSx for Lustre è generalmente single-AZ (scratch o persistent); la durabilità per Lustre deriva dalle associazioni con repository di dati S3, non dalla replicazione tra AZ.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Backup automatici di RDS e ripristino Point-in-Time

I backup automatici di RDS combinano uno snapshot giornaliero con il caricamento continuo dei log delle transazioni su S3 ogni 5 minuti, offrendo il ripristino point-in-time (PITR) a qualsiasi secondo all’interno della finestra di conservazione (retention) da 1 a 35 giorni. Se il tuo RPO è di 2 ore, i backup nativi di RDS lo soddisfano già: non è richiesta alcuna pianificazione di snapshot aggiuntiva, e aggiungere AWS Backup come ulteriore livello è ridondante, a meno che non siano necessarie copie cross-region, isolamento cross-account o semantiche di Vault Lock che vadano oltre ciò che offre la copia di snapshot di RDS. Il backup automatico predefinito è spesso la risposta corretta e più economica per requisiti di RPO modesti.

AWS Backup come piano di controllo centralizzato

AWS Backup è il piano di controllo basato su policy per il backup di EBS, EC2 (come AMI), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 e altro ancora. Invece di creare script con logiche di snapshot specifiche per ogni servizio, si definiscono piani di backup (backup plan) che raggruppano regole che descrivono la frequenza, la finestra di backup, le finestre di inizio/completamento, le transizioni del ciclo di vita verso l’archiviazione a freddo (cold storage), la conservazione (retention) e i vault di destinazione. Le risorse vengono incluse tramite assegnazioni di risorse (resource assignment) per tag o ARN, quindi una convenzione di tagging come Backup=Daily diventa il contratto operativo che governa la copertura. Per flotte di centinaia di istanze EC2, la selezione basata su tag è l’approccio che richiede il minimo sforzo: si applica il tag e si lascia che AWS Backup faccia l’enumerazione, invece di creare pianificazioni per ogni singola istanza.

Un vault di backup (backup vault) è il contenitore, crittografato con KMS, in cui risiedono i punti di ripristino. L’accesso è controllato da policy di risorsa sul vault.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Copie Cross-Region e Cross-Account

Il blocco CopyActions è il meccanismo per le copie di DR cross-region. AWS Backup gestisce la copia dello snapshot, la ricrittografa con una chiave KMS della Regione di destinazione (il vault di destinazione deve fare riferimento a una chiave in quella Regione) e applica un ciclo di vita indipendente. Gli snapshot di EBS e RDS risiedono di default nella Regione di origine: se l’intera Regione subisce un’interruzione, lo stesso vale per gli snapshot. Qualsiasi requisito normativo o aziendale che menzioni la resilienza regionale deve includere un passaggio esplicito di copia cross-region, sia tramite le azioni di copia di AWS Backup, la copia cross-region automatica degli snapshot di RDS, o le policy DLM con destinazioni cross-region.

Per le copie cross-account, AWS Organizations delega un account amministratore per AWS Backup; la policy del vault di origine autorizza l’account di destinazione, e il vault di destinazione permette le copie dall’origine. Questo è il modo economicamente vantaggioso per centralizzare il DR: un unico account di gestione conserva i punti di ripristino di molti account di workload e può eseguire il ripristino in entrambe le Regioni. Per EC2, una copia dell’AMI in una seconda Regione più la condivisione dello snapshot consentono di avviare istanze lì senza un’infrastruttura “warm” (tiepida). Gli snapshot crittografati richiedono la condivisione della CMK: l’account o la Regione di destinazione necessita del permesso kms:CreateGrant e dell’accesso alla chiave. La mancanza di questo permesso è il motivo per cui i ripristini cross-account falliscono silenziosamente.

Un RPO di 24 ore è soddisfatto a basso costo da uno snapshot giornaliero automatico copiato cross-region, una soluzione molto meno costosa di una replica di lettura cross-region o di un cluster di standby “warm”. Si passa a una replicazione continua solo quando l’RPO scende al di sotto di ciò che la cadenza degli snapshot può offrire.

Ciclo di vita delle AMI e backup di EC2

Due meccanismi automatizzano i backup di EC2: Data Lifecycle Manager (DLM) e AWS Backup. DLM è precedente ad AWS Backup e crea snapshot EBS o AMI basate su policy, con pianificazione e azioni di copia tra Regioni e tra account. AWS Backup ingloba questa funzionalità e aggiunge policy centralizzate, Vault Lock e un ambito multi-servizio. È preferibile usare AWS Backup se lo si utilizza già per altri servizi; usare DLM per scenari puramente EBS/AMI in cui non sono necessarie le funzionalità di vault.

Per i livelli web stateless dietro un gruppo di Auto Scaling senza dati locali persistenti, eseguire il backup delle istanze EC2 in esecuzione è uno spreco. L’approccio corretto è creare una AMI “hardened” (tramite EC2 Image Builder o una pipeline CI), farvi riferimento nel launch template e lasciare che l’ASG gestisca la sostituzione delle istanze. Lo sforzo di backup si concentra sui livelli stateful, i cui backup nativi automatizzati soddisfano l’RPO.

Immutabilità: Vault Lock e Object Lock

Un semplice snapshot nel proprio account può essere eliminato da chiunque abbia i permessi IAM corretti — gli snapshot da soli non soddisfano i requisiti di immutabilità. I regimi normativi (SEC 17a-4, FINRA, HIPAA, GDPR) richiedono spesso una conservazione write-once-read-many (WORM) che nemmeno gli amministratori possono aggirare. Due meccanismi AWS offrono questa funzionalità.

AWS Backup Vault Lock applica il WORM su un backup vault:

In modalità compliance, una volta trascorso il periodo di riflessione, nessun utente — incluso l’account root — può abbreviare la conservazione, eliminare i punti di ripristino prima della scadenza o rimuovere il blocco stesso. Questo neutralizza sia l’eliminazione da parte di un insider sia un operatore ransomware che abbia compromesso completamente l’account.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock fornisce WORM a livello di oggetto in modalità Governance (gli utenti con privilegi s3:BypassGovernanceRetention possono sovrascriverlo) o in modalità Compliance (nessuno, incluso root, può eliminare o abbreviare la conservazione). Il Legal Hold è indipendente dai periodi di conservazione. Object Lock richiede il versioning e deve essere abilitato alla creazione del bucket per una protezione completa.

Prenotazioni di capacità per la Regione di failover

Un piano di DR che presume che la Regione di failover avrà capacità EC2 disponibile il giorno di un evento su larga scala non è un vero piano. Quando una Regione fallisce, tutti eseguono il failover contemporaneamente e i tipi di istanza — specialmente quelli grandi, con GPU o specializzati — possono esaurirsi. Le On-Demand Capacity Reservations (ODCR) nella Regione di destinazione garantiscono la capacità per un tipo di istanza, una piattaforma e una AZ specifici, e vengono fatturate indipendentemente dal loro utilizzo. Abbinarle a un Savings Plan per compensare il costo. Per impegni a lungo termine su GPU/ML, si applicano i Capacity Blocks; per flessibilità sulla famiglia di istanze, una Capacity Reservation Fleet copre più famiglie di istanze. Il principio è: se il business richiede capacità di calcolo garantita nella Regione di DR, prenotala — non fare affidamento sulla disponibilità best-effort On-Demand.

Selezione della strategia di DR

AWS definisce quattro livelli canonici di DR, ognuno con un diverso compromesso tra costo e ripristino:

Il livello corretto è dettato dall’RPO e dall’RTO del business — non da preferenze architetturali. Un RPO di 24 ore tollera copie giornaliere di snapshot tra Regioni (Backup & Restore). Un RPO di pochi secondi richiede una replica continua — read replica tra Regioni, Aurora Global Database, DynamoDB Global Tables o S3 Cross-Region Replication. Tentare di ottenere un RPO di 5 minuti con snapshot notturni è architetturalmente impossibile, indipendentemente dal budget. Al contrario, usare di default l’approccio active-active per ogni workload è un anti-pattern di costo: richiede dati globalmente consistenti (DynamoDB Global Tables o Aurora Global con write-forwarding), capacità di calcolo duplicata su vasta scala e una gestione complessa del traffico tramite Route 53 o Global Accelerator. Scegli il pattern più economico che soddisfa l’RPO/RTO dichiarato — per un RPO di 2 ore, backup-and-restore o pilot light sono solitamente sufficienti, e warm standby è un’eccessiva ingegnerizzazione.

Protezione dall’eliminazione e misure di sicurezza stratificate

La resilienza non è semplicemente “abbiamo i backup?”, ma “un singolo attore, errore o attacco può cancellarli?”. Controlli stratificati prevengono la catastrofe da “un clic sbagliato”:

• RDS: abilitare DeletionProtection e richiedere uno snapshot finale all’eliminazione.
• EC2: abilitare DisableApiTermination e DisableApiStop sulle istanze critiche.
• DynamoDB: abilitare la protezione dall’eliminazione e il point-in-time recovery.
• S3: Versioning + MFA Delete + Object Lock per l’immutabilità.
• CloudFormation: DeletionPolicy: Retain sulle risorse stateful e protezione dalla terminazione dello stack.
• IAM SCPs: negare backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance e ec2:DeleteSnapshot al di fuori dei ruoli “break-glass”.

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Combinati con Vault Lock in modalità compliance, questi meccanismi producono una difesa in profondità: anche una credenziale di amministratore compromessa non può distruggere i punti di ripristino di ultima istanza.

Trappole Comuni

Trattare il Multi-AZ come DR. RDS Multi-AZ, ElastiCache Multi-AZ e FSx Multi-AZ risiedono tutti all’interno di una singola Regione. Un’interruzione dell’API a livello regionale, una cancellazione accidentale di una tabella (table drop) o una migrazione di schema applicata in modo errato colpiscono entrambi i nodi. Qualsiasi requisito che menzioni “un’altra Regione”, “guasto regionale” o “RPO cross-Region” impone la replica o la copia cross-Region — il Multi-AZ da solo non soddisfa il requisito.

Confondere le read replica con l’HA. Le read replica sono asincrone, la loro promozione è manuale e cambiano endpoint. Risolvono lo scaling in lettura, non il failover automatico.

Presumere che gli snapshot equivalgano alla compliance. Gli snapshot senza Vault Lock (modalità compliance) o Object Lock possono essere eliminati da qualsiasi principal con i permessi IAM corretti e dall’account root. La conservazione normativa WORM richiede una configurazione esplicita di immutabilità con un periodo di riflessione (cooling-off period) bloccato e trascorso.

Snapshot solo locali per un RPO regionale. Gli snapshot di EBS e RDS vengono creati di default nella Regione di origine. La resilienza regionale richiede un’azione esplicita di copia cross-Region.

Backup senza ripristini testati o capacità riservata. Uno snapshot che non è mai stato ripristinato è un’ipotesi, non un backup. Le esercitazioni di ripristino (restore drill) rivelano ruoli IAM mancanti, problemi di accesso alle chiavi KMS nella Regione e nell’account di destinazione, e tipi di istanza non disponibili. Senza Capacity Reservations per i carichi di lavoro critici, la Regione di DR potrebbe semplicemente non avere la “shape” di cui hai bisogno quando tutti eseguono il failover contemporaneamente — e l’RTO diventa illimitato.

Sovra-ingegnerizzare verso l’active-active. Duplicare il compute a livello globale, la replica dei dati globalmente consistente e una gestione complessa del traffico (traffic steering) sono costosi. Se l’RPO/RTO non lo giustifica, un’architettura pilot light o warm standby è la scelta corretta.

Eseguire il backup di tier stateless. Fare lo snapshot di web server effimeri dietro un ASG è uno spreco di denaro e complica il ripristino. Prepara (bake) delle AMI, referenziale nei launch template e concentra l’investimento per il backup sui dati stateful.

← Gestione · Tutti i domini

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

Sfoglia Amazon →