Elastic Load Balancers


AWS supports 3 types of load balancers:

  • Application load balancer (ALB)

  • Network load balancer (NLB)

  • Classic load balancer (CLB)


  • Instances monitored by ELB are reported as: InService or OutOfService

  • Health checks check the instance health by talking to it

  • Load balancers have their own DNS names, you are never given an IP address.


Application load balancers are best suited for load balancing of HTTP(S) traffic. They operate at Level 7 and are application aware. They are intelligent and you can create advanced request routing, sending specific requests to specific web services.


Network load balancers are best suited for load balancing of TCP traffic where extreme performance is required. Operating at the connection level (OSI Level 4), NLB are capable of handling millions of requests per second, while maintaining ultra-low latencies.


Classic load balancers are the legacy ELB. You can load balance HTTP(S) applications and use Level 7 specific features, such as X-Forwarded and sticky sessions. You can also use strict Level 4 load balancing for applications that rely purely on the TCP protocol.

If your application stops responding, CLB responds with HTTP 504 error. This means that application is having issues.

Sticky sessions

CLB routes each request independently to the registered EC2 instance with the smallest load. Sticky sessions allow you to bind a user session to a specific EC2 instance. This ensures that all requests from the user during the session are sent to the same instance. You can enable sticky sessions for ALB as well, but the traffic will be sent at the target group level.

Cross-zone load balancing

With cross-zone load balancing each load balancer node for your CLB distributes requests eventy across the registered instances in all enabled AZs. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its AZ only. CLB has cross-zone load balancing off by default, ALB cross-zone load balancing is always on.

Path patterns

You can create a listener with rules to forward requests based on the URL path. This is known as path-based routing. If you are running microservices, you can route traffic to multiple backend services using path-based routing. For example, you can route general requests to one target group and requests to render images to another target group.

Pre-warming your ELB

Are you expecting a large spike in traffic for an event? Get in touch with Amazon and have them pre-warm your load balancers. ELBs scale best with a gradual increase in traffic load. They do not respond well to spiky loads, and can break if too much flash traffic is directed their way.

This is covered under the ELB best practices, and can be critical to having your event traffic handled gracefully, or being left wondering what just happened to your application stack when there is a sudden drop in traffic. Key pieces of information to relay to Amazon when contacting them are the total number of expected requests, and the average request response size.

One other key piece of information has to do with operating at scale. If you are terminating your SSL on the ELB, and the HTTPS request response size is small, be sure to stress that point with Amazon support. Small request responses coupled with SSL termination on the ELB may result in overloading the ELBs, even though Amazon will have scaled them to meet your anticipated demand.

AWS will need to know:

  • start and end dates

  • expected request rate per second

  • total size of a typical request


Four different ways to monitor your load balancers:

  • CloudWatch metrics

  • Access Logs

  • Request Tracing

  • CloudTrai Logs

CloudWatch metrics

ELB publishes data points to CloudWatch for your load balancers and your targets. CloudWatch enables you to retrieve statistics about those data points as an ordered set of time series data.

ELB CloudWatch Metrics

Overall health

  • BackendConnectionErrors - number of unsuccessful connections to backend instances

  • HealthyHostCount - number of healthy instances registered

  • UnHealthHostCount - number of unhealthy instances

  • HttpCode_Backend_2XX,3XX,4XX,5XX


  • Latency - number of seconds taken for registered instance to respond / connect

  • RequestCount - number of requests completed / connections made during the specified interval (1 or 5 minutes)

  • SurgeQueueLength - number of pending requests, max 1024, additional requests will be rejected (Classic ELB only)

  • SpilloverCount - number of requests rejected because the surge queue is full (Classic ELB only)

Access Logs

ELB provide access logs that capture detailed information such as a time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze patterns and troubleshoot issues. Access logging is an optional feature of ELB that is disabled by default. After you enable access logging for your load balancer, ELB captures the logs and stores them in S3 bucket that you specify as compressed files. You can disable access logging at any time.

Access logs can store data where the EC2 instance has been deleted. For example, you have a fleet of EC2 instances behind an autoscaling group. For some reason your application has loads of 5XX errors which is only reported by your end customers a couple of days after the event. If you aren't storing the web server logs anywhere persistent, it's still possible to trace these 5XX errors using access logs which would be stored in S3.

Request Tracing

You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the X-Amzn-Trace-Id header before sending the request to the target. Any services or applications between the load balancer and the target can also add or update this header. Available for ALB only.


You can use CloudTrail to capture detailed logs about the calls made to ELB API and store them as the log files in S3.

Last updated