Uma empresa executa um projeto de 3 anos com um aplicativo que usa 20 instâncias sob demanda do Amazon EC2 registradas em um grupo de destino do Network Load Balancer em duas zonas de disponibilidade. O aplicativo é sem estado e funciona 24 horas por dia, 7 dias por semana. A utilização normal da CPU é de cerca de 10%, mas a CPU sobe para 100% durante períodos curtos de pico que duram algumas horas. Os usuários relatam respostas lentas. Qual nova arquitetura resolverá o problema de resposta lenta da forma MAIS econômica?

A opção correta é criar um grupo do Auto Scaling com capacidade mínima de 4 e máxima de 28, anexado ao NLB, e adquirir Reserved Instances para as 4 instâncias mínimas. Isso é o mais econômico porque o aplicativo tem baixa utilização de CPU na maior parte do tempo (10%), mas picos ocasionais. As Reserved Instances cobrem a carga base constante de forma mais barata, enquanto o Auto Scaling adiciona e remove instâncias sob demanda (pagas por hora) para lidar com os picos, garantindo elasticidade e desempenho sem superprovisionamento constante. As outras opções são menos eficientes: Definir capacidade mínima de 20 e desejada de 28 com RIs para 20 instâncias é caro, pois 20 instâncias são demais para a carga base. Usar Spot Fleet com request ou maintain e Spot como tipo de capacidade padrão pode ser mais barato, mas Spot Instances são interrompíveis, o que não é ideal para uma carga base de um aplicativo 24/7 que precisa de alta disponibilidade. Substituir o NLB por um ALB não é necessário para resolver o problema de desempenho e pode introduzir complexidade ou custos adicionais sem benefício direto para a escalabilidade das instâncias.