MENU
A company's HTTP application is behind a Network Load Balancer (NLB). The NLB's target group is configured to use an Amazon EC2 Auto Scaling group with multiple EC2 instances that run the web service.
The company notices that the NLB is not detecting HTTP errors for the application. These errors require a manual restart of the EC2 instances that run the web service. The company needs to improve the application's availability without writing custom scripts or code.
What should a solutions architect do to meet these requirements?
A Network Load Balancer operates at Layer 4 (TCP/UDP/TLS) and is optimized for high performance and static IP use cases. While NLB target groups can perform health checks, they are typically oriented around basic reachability and do not provide the same application-layer (Layer 7) visibility as an Application Load Balancer (ALB). The problem statement says the NLB is ''not detecting HTTP errors,'' which indicates the health signal needs to be based on an HTTP endpoint that can reflect application correctness (for example, returning specific HTTP status codes).
Replacing the NLB with an ALB enables true HTTP/HTTPS health checks against a URL path, including interpretation of HTTP response codes. This is the cleanest managed approach to detect application-layer failure modes that still allow TCP connections but produce bad HTTP responses. Once the ALB detects targets as unhealthy, the target group health status can be used by an Auto Scaling group to take action. With appropriate health check configuration (and, commonly, using ELB health checks as a signal), Auto Scaling can replace unhealthy instances automatically, improving availability without custom scripts.
Option A is misleading: NLB does not provide the same HTTP-aware request routing and rich L7 features; even if an NLB health check is configured, it does not address the broader need for application-layer detection and remediation as directly as ALB. Option B violates the ''no custom scripts'' requirement. Option D reacts to UnhealthyHostCount, but if the NLB isn't marking hosts unhealthy for HTTP error cases, the metric won't reliably trigger replacement; it also still depends on the NLB's limited visibility into HTTP failures.
Therefore, C best meets the requirement by shifting to ALB for application-layer health checks and using Auto Scaling to replace unhealthy instances automatically.