A company's ecommerce application is running on Amazon EC2 instances that are behind an Application...

In this scenario, the issue is that the EC2 instances are marked healthy by status checks, but the website is still intermittently failing, returning HTTP 500 errors.

This indicates that the OS-level checks are passing, but the application is not behaving properly. To resolve this, the Auto Scaling group must use ALB (ELB) health checks which verify application-level health, not just EC2 status.

From the Auto Scaling User Guide:

By default, an Auto Scaling group uses EC2 instance status checks to determine the health state of an instance. You can optionally configure the Auto Scaling group to use Elastic Load Balancing health checks in combination with EC2 status checks.

These health checks allow Auto Scaling to detect application failures and replace unhealthy instances automatically.

❌ Why the other options are incorrect:

A. Network Load Balancer is for TCP-level traffic and does not solve HTTP 500 errors.

C. Sticky sessions are used for session persistence and don’t solve server errors.

D. Installing CloudWatch agents and rebooting is reactive and not an automated health check replacement system.