A company's HTTP application is behind a Network Load Balancer (NLB). The NLB's target group uses an Amazon EC2 Auto Scaling group with multiple EC2 instances running the web service. The NLB is not detecting HTTP errors, which require manual restarts of the web service EC2 instances. The company wants to improve availability without writing custom scripts or code. What should a solutions architect do?

The correct option replaces the Network Load Balancer (NLB) with an Application Load Balancer (ALB). NLBs operate at Layer 4 (TCP/UDP) and cannot inspect HTTP traffic for application-level errors. ALBs operate at Layer 7 (HTTP/HTTPS) and can perform HTTP health checks, allowing them to detect when the application itself is returning errors (e.g., 5xx status codes). By configuring the ALB with HTTP health checks and integrating it with an Auto Scaling group, unhealthy instances (those failing HTTP checks) can be automatically replaced, improving availability without manual intervention or custom scripting. Enabling HTTP health checks on an NLB is incorrect because NLBs only support TCP health checks, not HTTP. Adding a cron job is a custom script solution, which the company wants to avoid. Monitoring UnhealthyHostCount for an NLB is insufficient because NLBs only detect TCP-level unhealthiness, not application-level HTTP errors.