Un'azienda necessita di una strategia di backup per un'applicazione web stateless a tre livelli. Il livello web è eseguito su istanze EC2 in un gruppo Auto Scaling con scalabilità dinamica. Il livello database è eseguito su Amazon RDS per PostgreSQL. L'applicazione web non richiede storage locale temporaneo sulle istanze EC2. L'obiettivo del punto di ripristino (RPO) è di 2 ore. La strategia di backup deve massimizzare la scalabilità e ottimizzare l'utilizzo delle risorse. Quale soluzione soddisferà questi requisiti?

L'opzione corretta soddisfa i requisiti perché l'applicazione è stateless e il livello web è su istanze EC2 in un gruppo Auto Scaling. Mantenere AMI aggiornate per il livello web permette un rapido ripristino o scalabilità, poiché le istanze EC2 possono essere terminate e ricreate senza perdita di dati specifici dell'istanza. L'abilitazione dei backup automatici e il ripristino point-in-time per Amazon RDS per PostgreSQL soddisfano l'RPO di 2 ore per il database, fornendo un recupero granulare. Le altre opzioni sono meno efficienti o non adeguate: Eseguire snapshot EBS ogni 2 ore per istanze EC2 in un gruppo Auto Scaling è inefficiente e non necessario per un'applicazione stateless, poiché i dati non persistono sui volumi EBS delle istanze. Configurare una policy del ciclo di vita degli snapshot EBS è simile al punto precedente, non ottimale per istanze stateless. L'esecuzione di snapshot EBS ogni 2 ore per le istanze EC2, anche se combinata con i backup RDS, è ancora inefficiente per un'applicazione stateless.