Rohit shows you how
to troubleshoot 503 errors
with Classic Load Balancers

503-error-classic-rohit

I’m seeing HTTP 503 errors in Classic Load Balancer access logs, CloudWatch metrics, or when hitting the load balancer’s DNS name in the browser or from my clients. How do I fix this?

Make sure you have registered back-end instances in every Availability Zone that your Classic Load Balancer is configured to respond in, that the registered back-end instances are not failing health checks, and that they’re sized appropriately to handle the load your application requires.

To see the number of healthy back-end instances behind your load balancer, check the HealthyHostCount and UnHealthyHostCount metrics in CloudWatch. If the CloudWatch metrics indicate you have no healthy hosts, or one or more unhealthy hosts, you can troubleshoot the issue by checking the following:

Make sure your back-end instances can respond to health checks

If the back-end instances appear to be running and healthy, but the UnhealthyHostCount metric indicates that you have one or more unhealthy instances, make sure that the load balancer can respond to health check requests. For HTTP/HTTPS health checks, make sure that your load balancer is able receive a 200 response code from the back end; for layer 4 health checks, the load balancer marks the instance as healthy if the instance successfully completes a TCP handshake. For instructions, see Troubleshoot a Classic Load Balancer: Health Checks.

Make sure your load balancer and back-end instances can handle the load

Check your load balancer and back-end instances to make sure they’re able to handle the CPU usage, memory, disk usage, and number of connections your application requires.

For example, check the SpilloverCount and SurgeQueueLength CloudWatch metrics. If SurgeQueueLength is at or near the maximum of 1,024 queued requests, or SpilloverCount is a non-zero number, that indicates that the back end can’t serve requests as fast as they’re coming in, or isn’t able to serve requests at all.

Also check CPUUtilization CloudWatch metrics for your back-end instances—if you observe that the CPU utilization is spiking to 100%, or is consistently high over long periods of time, consider adding more back-end instances, or resize the current instances to larger sizes. For instructions on checking other values, such as memory and disk usage, check the instance vendor’s documentation.


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2016-09-15