La aplicación HTTP de una empresa está detrás de un Network Load Balancer (NLB). El grupo objetivo del NLB utiliza un grupo de Auto Scaling de Amazon EC2 con múltiples instancias EC2 que ejecutan el servicio web. El NLB no detecta errores HTTP, lo que requiere reinicios manuales de las instancias EC2 del servicio web. La empresa quiere mejorar la disponibilidad sin escribir scripts o código personalizados. ¿Qué debe hacer un arquitecto de soluciones?

La opción correcta es reemplazar el NLB por un Application Load Balancer (ALB) porque los NLB operan en la capa 4 (transporte) y no pueden realizar comprobaciones de estado HTTP a nivel de aplicación. Los ALB operan en la capa 7 (aplicación) y pueden realizar comprobaciones de estado HTTP detalladas, detectando errores de aplicación. Al configurar un ALB con comprobaciones de estado HTTP y una acción de Auto Scaling para reemplazar instancias no saludables, la empresa automatiza la detección y recuperación de fallos HTTP sin necesidad de scripts personalizados, mejorando la disponibilidad. Habilitar comprobaciones de estado HTTP en el NLB no funcionaría, ya que no tiene esa capacidad. Los trabajos cron requieren scripts personalizados, lo que la empresa quiere evitar. Una alarma de CloudWatch para UnhealthyHostCount en un NLB no detectaría errores HTTP a nivel de aplicación, ya que el NLB no los monitorea.