What should a solutions architect do to meet these requirements?
Enable HTTP health checks on the NLB, supplying the URL of the company’s application.
Add a cron job to the EC2 instances to check the local application’s logs once each minute. If HTTP errors are detected, the application will restart.
Replace the NLB with an Application Load Balancer. Enable HTTP health checks by supplying the URL of the company’s application. Configure an Auto Scaling action to replace unhealthy instances.
Create an Amazon CloudWatch alarm that monitors the UnhealthyHostCount metric for the NLB. Configure an Auto Scaling action to replace unhealthy instances when the alarm is in the ALARM state.
Explanations:
Network Load Balancers (NLB) only support TCP and IP health checks, not HTTP. Therefore, enabling HTTP health checks on an NLB is not possible, making this option invalid.
Adding a cron job on EC2 instances would introduce custom logic for restarting the application, which the requirement specifically disallows. This does not align with the goal of using AWS-managed features for automation.
Replacing the NLB with an Application Load Balancer (ALB) allows the use of HTTP health checks, which can monitor the specific URL for HTTP errors. ALBs also integrate well with Auto Scaling actions to terminate and replace unhealthy instances.
Although monitoring theUnhealthyHostCountmetric is possible, it does not allow for specific HTTP-level health checks. This solution would still require using TCP checks and might miss application-layer issues, making it less effective.
In my experience, the answer is:
Replace the NLB with an Application Load Balancer. Enable HTTP health checks by supplying the URL of the company’s application. Configure an Auto Scaling action to replace unhealthy instances.
I categorize that the answer is:
Replace the NLB with an Application Load Balancer. Enable HTTP health checks by supplying the URL of the company’s application. Configure an Auto Scaling action to replace unhealthy instances.