Uma aplicação web crítica atualmente é executada em uma única instância Amazon EC2 em uma sub-rede pública e usa um banco de dados MySQL. O DNS está no Route 53. Um arquiteto de soluções deve tornar a aplicação escalável e altamente disponível e reduzir a latência de leitura do MySQL. Qual combinação de mudanças atenderá a esses requisitos? (Escolha duas.)

A criação de um Auto Scaling group com instâncias EC2 em múltiplas Availability Zones (AZs) atrás de um Application Load Balancer (ALB) garante alta disponibilidade e escalabilidade da aplicação. O ALB distribui o tráfego e o Auto Scaling group ajusta a capacidade conforme a demanda, substituindo instâncias com falha. Migrar o banco de dados para um cluster Amazon Aurora MySQL com instâncias primárias e de leitura em AZs separadas oferece alta disponibilidade para o banco de dados e as réplicas de leitura Aurora reduzem a latência de leitura, distribuindo as consultas. A opção de iniciar uma segunda instância EC2 em outra região com política de failover no Route 53 não oferece escalabilidade automática nem alta disponibilidade dentro da região primária. A opção de Auto Scaling group em múltiplas regiões é mais complexa e cara do que o necessário para os requisitos iniciais de alta disponibilidade e escalabilidade dentro de uma única região. A migração para Aurora com réplicas de leitura entre regiões seria para recuperação de desastres inter-regionais, não para redução de latência de leitura dentro da mesma região, que é o foco principal aqui.