Uma aplicação crítica é executada em uma única instância EC2 e usa um cluster de nó único do ElastiCache for Redis, além de uma instância de banco de dados RDS for MariaDB. Todos os componentes devem estar íntegros e ativos para que a aplicação funcione. Você precisa redesenhar a infraestrutura para que ela possa se recuperar automaticamente de falhas com tempo de inatividade mínimo. Qual combinação de mudanças você deve implementar? (Escolha três.)

Para alta disponibilidade da aplicação, o Elastic Load Balancer distribui o tráfego entre múltiplas instâncias EC2 gerenciadas por um Auto Scaling Group com capacidade mínima de duas instâncias, garantindo que a aplicação permaneça ativa mesmo se uma instância falhar. O RDS Multi-AZ provisiona uma réplica síncrona em outra AZ, promovendo-a automaticamente em caso de falha da primária, minimizando o tempo de inatividade. Para o ElastiCache for Redis, um grupo de replicação com Multi-AZ cria réplicas em outras AZs, permitindo failover automático e recuperação rápida. As opções incorretas são: Configurar o Auto Scaling Group no modo ilimitado não garante um mínimo de instâncias e pode levar a custos excessivos. Criar uma réplica de leitura do RDS na mesma AZ não oferece resiliência contra falhas de AZ, e a promoção manual aumenta o tempo de recuperação. Gerenciar o ElastiCache por um Auto Scaling Group não é a maneira padrão de garantir alta disponibilidade para o Redis, que usa grupos de replicação.