Uma migração lift-and-shift deixou um único grupo do Auto Scaling onde cada instância EC2 executa componentes web, de banco de dados e de cache Redis, causando tempos de resposta variáveis e instâncias sobrecarregadas. A empresa deseja separar os componentes para melhorar a disponibilidade e o desempenho. Qual mudança de arquitetura satisfará esse requisito?

A opção correta separa os componentes em serviços gerenciados e escaláveis. Um Application Load Balancer (ALB) com um grupo do Auto Scaling é ideal para a aplicação web, oferecendo roteamento avançado e escalabilidade. O Amazon Aurora com Multi-AZ proporciona alta disponibilidade e desempenho para o banco de dados, sendo uma solução robusta e gerenciada. Um cluster Amazon ElastiCache (Redis OSS) é a solução gerenciada e escalável para o cache, eliminando a necessidade de gerenciar Redis em instâncias EC2. As outras opções contêm falhas: A primeira opção usa um Network Load Balancer (NLB) para a aplicação web, que é menos adequado que um ALB para tráfego HTTP/S, e cria um ALB para o cache Redis, o que é desnecessário, pois o ElastiCache é a solução ideal. A segunda opção usa um NLB para o cache Redis em uma única AZ, o que não oferece alta disponibilidade e é uma configuração complexa e inadequada para o ElastiCache. A terceira opção usa um NLB para a aplicação web e tenta usar um target group com destinos DNS para o ElastiCache, o que é uma configuração desnecessária e ineficiente, pois o ElastiCache já é um serviço gerenciado.