A aplicação HTTP de uma empresa está por trás de um Network Load Balancer (NLB). O grupo de destino do NLB usa um grupo do Amazon EC2 Auto Scaling com várias instâncias EC2 executando o serviço web. O NLB não está detectando erros HTTP, o que exige reinícios manuais das instâncias EC2 do serviço web. A empresa deseja melhorar a disponibilidade sem escrever scripts ou código personalizados. O que um arquiteto de soluções deve fazer?

A substituição do NLB por um Application Load Balancer (ALB) é a solução correta porque o ALB opera na camada 7 (HTTP/HTTPS) e pode realizar verificações de integridade HTTP detalhadas, incluindo o status da aplicação. Ao habilitar verificações de integridade HTTP com a URL da aplicação e configurar uma ação do Auto Scaling para substituir instâncias não íntegras, o sistema detectará automaticamente falhas na aplicação e as corrigirá sem intervenção manual ou scripts personalizados, melhorando a disponibilidade. O NLB opera na camada 4 e não pode inspecionar o conteúdo HTTP para detectar erros na aplicação. Adicionar um cron job é uma solução personalizada e não atende ao requisito de evitar scripts. O alarme do CloudWatch para UnhealthyHostCount no NLB não detectaria erros HTTP da aplicação, apenas a indisponibilidade total da instância conforme as verificações de integridade de camada 4 do NLB.