Een bedrijf heeft een back-upstrategie nodig voor een drielaagse stateless webapplicatie. De weblaag draait op EC2-instances in een Auto Scaling-groep met dynamische schaling. De databaselaag draait op Amazon RDS for PostgreSQL. De webapplicatie vereist geen tijdelijke lokale opslag op de EC2-instances. De recovery point objective (RPO) is 2 uur. De back-upstrategie moet de schaalbaarheid maximaliseren en het resourcegebruik optimaliseren. Welke oplossing voldoet aan deze vereisten?

De correcte optie voldoet aan de vereisten omdat de webapplicatie stateless is en geen lokale opslag op de EC2-instances vereist. Dit betekent dat de EC2-instances zelf geen kritieke gegevens bevatten die geback-upt moeten worden via EBS-snapshots. Het behouden van de nieuwste AMI's voor de weblaag is voldoende om snel nieuwe instances te lanceren. Voor de databaselaag zorgt het inschakelen van geautomatiseerde back-ups in Amazon RDS, inclusief point-in-time recovery, ervoor dat de RPO van 2 uur wordt gehaald. De andere opties zijn minder optimaal: EBS-snapshots van EC2-volumes zijn onnodig voor een stateless applicatie zonder lokale opslag, wat leidt tot onnodige kosten en complexiteit. Een snapshot lifecycle policy voor EBS-volumes heeft hetzelfde nadeel als hierboven. Het maken van EBS-snapshots van EC2-instances elke 2 uur is onnodig en inefficiënt voor stateless instances.