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 Cloud Watch 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:
NLB does not support HTTP health checks; it uses TCP health checks, which cannot detect HTTP-specific errors.
This option involves adding custom code (a cron job) on the EC2 instances, which does not meet the requirement of avoiding custom scripts or code.
An Application Load Balancer (ALB) supports HTTP health checks, which can detect HTTP errors. The ALB, combined with Auto Scaling, can automatically replace unhealthy instances, improving availability without custom code.
CloudWatch alarms on UnhealthyHostCount cannot directly detect HTTP errors, and NLB only supports TCP health checks, which cannot capture HTTP-specific issues.
I plot 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.
From what I’ve heard, 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.