Diagnosing 503 Errors from ALB

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The application health check endpoint is returning HTTP 5xx or timing out.

  Why this is correct

  The ALB health check is performing HTTP requests against the configured health check path on each target. When the application returns any 5xx status code (or the request times out because the app hangs under load), the ALB marks that target as unhealthy. With an intermittent application bug (e.g., a memory leak or a connection pool exhaustion), the health check will fail sporadically, causing the ALB to periodically stop routing traffic to that instance. If all targets become unhealthy at the same time, the ALB returns HTTP 503 Service Unavailable to clients, which exactly matches the intermittent nature of the reported errors.

• ✗

  The ALB is misconfigured with an incorrect security group blocking traffic to the targets.

  Why it's wrong here

  An incorrectly configured ALB security group that blocks traffic to the targets would prevent health check requests from ever reaching the applications. This condition is persistent, not intermittent: the security group rules do not change on their own, so every health check would fail consistently, and the ALB would return 503 continuously. The question explicitly says the errors are intermittent, which rules out a static security group misconfiguration. Additionally, a security group it too broad or too narrow affects all traffic uniformly; it does not cause occasional 5xx responses only during certain time windows.

• ✗

  The ALB connection draining settings are too short, causing in-flight requests to fail.

  Why it's wrong here

  Connection draining (also called deregistration delay) is an ALB feature that controls how long the load balancer keeps existing connections open to instances that are being deregistered or that have become unhealthy. It does not influence how health checks are performed or whether the health check endpoint returns a successful status code. Misconfiguring the draining delay can drop in-flight requests during scaling events, but it will not cause health checks to intermittently return 5xx or time out. The symptom described in the question is specifically about health check failures, not about connection termination during instance replacement.

• ✗

  The step scaling policy is too aggressive and is terminating instances prematurely.

  Why it's wrong here

  A step scaling policy (via Auto Scaling or a custom scaling solution) adjusts the desired capacity based on CloudWatch alarms, but it does not directly interact with the ALB health check mechanism. If the policy were too aggressive, it might reduce the number of instances too quickly, potentially leading to insufficient capacity and 503s from the ALB when no healthy targets remain. However, that would be a capacity shortage symptom, not a health check failing on its own — the health check would still report the remaining instances as healthy. The question refers to instances being marked unhealthy by health checks, not simply being terminated, so an aggressive scaling policy is not the correct explanation.

Go deeper

Related to this question