Uma empresa precisa de uma estratégia de backup para um aplicativo web sem estado de três camadas. A camada web é executada em instâncias EC2 em um grupo do Auto Scaling com escalonamento dinâmico. A camada de banco de dados é executada no Amazon RDS para PostgreSQL. O aplicativo web não requer armazenamento local temporário nas instâncias EC2. O objetivo do ponto de recuperação (RPO) é de 2 horas. A estratégia de backup deve maximizar a escalabilidade e otimizar a utilização de recursos. Qual solução atenderá a esses requisitos?

A opção correta atende aos requisitos de um aplicativo web sem estado e um RPO de 2 horas. Reter as AMIs mais recentes para a camada web (executada em instâncias EC2 em um grupo do Auto Scaling) é o método mais eficiente para fazer backup e restaurar a configuração da instância, pois o aplicativo não requer armazenamento local temporário. As AMIs capturam o estado completo da instância, incluindo o sistema operacional e as configurações do aplicativo. Para o Amazon RDS, habilitar backups automatizados com recuperação point-in-time é a solução padrão e ideal para atender ao RPO, permitindo restaurar o banco de dados para qualquer ponto dentro do período de retenção. As opções incorretas são menos eficientes ou inadequadas: Tirar snapshots de volumes EBS das instâncias EC2 a cada 2 horas é desnecessário e ineficiente para um aplicativo sem estado que não usa armazenamento local persistente. Além disso, o Auto Scaling Group pode substituir instâncias, tornando os snapshots de volumes EBS individuais menos úteis para a camada web. Configurar uma política de ciclo de vida de snapshot para EBS ainda foca em volumes EBS, que não são o principal método de backup para instâncias EC2 sem estado em um Auto Scaling Group. A última opção, embora inclua backups automatizados do RDS, ainda sugere snapshots de volumes EBS para as instâncias EC2, o que é ineficiente para o cenário dado.