Why do EC2 instances return HTTP 500 when status checks are healthy?
A company's ecommerce application is running on Amazon EC2 instances that are behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. Customers report that the website is occasionally down. When the website is down, the website returns an HTTP 500 (server error) status message to customer browsers. The Auto Scaling group's health check is configured for EC2 status checks, and the instances are healthy. Which solution will resolve the problem?
Community Insight
The test is the difference between EC2 status checks (hypervisor/host level) and ELB health checks (application/target level) — the trap is assuming "instances are healthy" means the application is healthy.
When an Auto Scaling group relies only on EC2 status checks, instances that stay reachable but serve HTTP 500 errors from the application are never replaced. This page explains why adding Elastic Load Balancing (ELB) health checks to the Auto Scaling group is the fix.
Many candidates pick session affinity or swapping the ALB for a Network Load Balancer, mistaking an application-layer 500 error for a load-balancing or stickiness problem rather than a health-check scope problem.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
An EC2 status check only reports whether the instance and its host are running and reachable — it says nothing about whether the application on port 80/443 is answering successfully. With the Auto Scaling group configured for EC2 health checks, an instance that returns HTTP 500 to the ALB's target group health check is marked unhealthy by the load balancer and removed from rotation, but the Auto Scaling group still considers it healthy and never terminates or replaces it. Turning on ELB health checks for the Auto Scaling group makes the ALB's application-level verdict the source of truth, so failing instances are replaced and capacity is restored. That directly addresses the reported symptom: intermittent outages with HTTP 500 responses while the group insists every instance is healthy. As Bad_Mat puts it, the fix is to "Add Elastic Load Balancing (ELB) health checks to the Auto Scaling group."Why the Other Options Are Wrong
Replacing the ALB with a Network Load Balancer (A) changes the traffic plane but not the failure: NLB health checks are also independent of the Auto Scaling group's EC2 status checks, and the application would still emit 500 errors. Enabling session affinity (C) only pins each customer to one target; if the underlying instance is serving errors, stickiness guarantees that customer keeps hitting the same broken instance, which can even worsen the outage. Installing the CloudWatch agent and rebooting instances on a metric (D) is a blunt, reactive workaround — rebooting does not verify the application recovered, causes additional downtime, and is not how Auto Scaling is meant to remediate unhealthy capacity.Community Comment Notes
Only one learner weighed in on this question, and their pick aligns with the AWS-documented behaviour: Bad_Mat selects option B and restates it almost verbatim as "Add Elastic Load Balancing (ELB) health checks to the Auto Scaling group." No commenter argued for the NLB swap, sticky sessions, or CloudWatch-agent reboots. Because the vote sample here is essentially a single data point, treat the community record as confirmation rather than proof, and rely on the EC2-versus-ELB health-check distinction when defending the answer in the exam.Official Reference
Exam Strategy
When a scenario says the Auto Scaling group uses EC2 health checks and the instances are "healthy" while users see 5xx errors, the answer almost always involves switching the group to ELB health checks. Scan for the phrase "EC2 status checks" as the cue, and eliminate any option that only touches load balancer type or stickiness.
Frequently Asked Questions
Why don't EC2 status checks catch an instance returning HTTP 500?
EC2 status checks only verify instance and host reachability, not the application. An instance can pass them while its web server still returns 500 errors to the ALB.
Why is enabling sticky sessions on the ALB target group wrong here?
Session affinity only pins a user to one target. If that target is serving 500 errors, stickiness keeps sending the customer to the same broken instance instead of replacing it.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →