Uma aplicação Java foi implantada no AWS Elastic Beanstalk usando um ambiente de instância única para economizar custos durante o desenvolvimento. Testes mostram utilização sustentada da CPU acima de 85%, causando gargalos de desempenho. Você deve mitigar o gargalo da CPU antes da produção com o menor overhead operacional. O que você deve fazer?

A opção correta aborda o gargalo de CPU com o menor overhead operacional. Modificar o ambiente existente para um tipo balanceado por carga permite escalar horizontalmente, distribuindo a carga entre várias instâncias e mitigando o gargalo da CPU. Habilitar todas as Zonas de Disponibilidade aumenta a resiliência e a disponibilidade. A regra de scale-out automatiza a adição de instâncias quando a CPU excede 85%, garantindo desempenho contínuo. As outras opções são menos eficientes ou incorretas: Criar uma nova aplicação Elastic Beanstalk (primeira opção) ou um segundo ambiente (segunda opção) introduz overhead operacional desnecessário, pois o ambiente existente pode ser modificado. A opção de divisão de tráfego (segunda opção) é para implantações canary ou azul/verde, não para escalar um gargalo de CPU em um único ambiente. Rebuild environment (quarta opção) recria o ambiente, o que pode causar inatividade, e selecionar apenas uma Zona de Disponibilidade não é ideal para alta disponibilidade.