Tuning Your ELB for Optimal Performance

Amazon Web Services (AWS) first introduced Elastic Load Balancing (ELB) in May of 2009. The objective of the service was to provide a method for users to distribute traffic across multiple Amazon EC2 instances. Today, AWS offers their ELB service in three distinct flavors:

• Classic Load Balancer
• Application Load Balancer
• Network Load Balancer

In this article, we’re going to look at each flavor and identify circumstances where you would select one type over another. We’re also going to discuss how to configure your ELB solution for optimal performance. We’ll be focused on performance tuning of Classic and Application Load Balancers, but we will reference Network Load Balancers where appropriate.

Selecting The Right Type of Load Balancer

Selecting the appropriate type of load balancer for your needs is key to optimal performance. While the Classic Load Balancer provides support for a broader range of protocols, choosing either an Application Load Balancer or a Network Load Balancer may offer additional gains regarding functionality and performance.

The Application Load Balancer (ALB) operates at request level (Layer 7) which allows you to route traffic based on content. Some additional reasons or circumstances where you might benefit from using an ALB include:

• Routing of HTTP and HTTPS traffic
• Use of the Load Balancer for SSL termination
• Path- and Host-Based Routing

The Network Load Balancer (NLB) operates at the connection level (Layer 4) and can support millions of requests per second with ultra-low latency. Some additional features and determinants for when you might want to use an NLB include:

• Routing of TCP traffic
• Preservation of the client IP address

For additional comparison of features between the Classic ELB, the ALB, and the NLB, AWS provides a handy comparison table.

General Performance Recommendations

Before we take a deep dive into performance tuning of load balancers, there are a couple of best practices to follow to enhance load balance and application performance.

First, if your application or web service implements SSL, move the SSL termination to the load balancer, instead of applying it to each instance. Using the ELB to handle the SSL handshake removes the need to configure certificates on each of the target machines, and also ensures your application is always protected by the most up-to-date encryption technology.

Second, make sure that the health check endpoint on your application is reliable and performant. The health check is used by the load balancer to determine which instances are available for traffic.

What Performance Metrics Are Available?

AWS tracks the performance of its load balancers and logs these to CloudWatch. You can view a full list of metrics in the AWS documentation, but let’s look at a couple of critical areas which are essential for the identification of performance monitoring. Since NLBs function differently from ALBs and ELBs, their specific metrics differ from those shown below. Please refer to the AWS documentation for more information on performance metrics for NLBs.

• Request Count

RequestCount measures the number of requests which were received by the ELB and which returned a response from one of the target instances.

• ELB Error Count

HTTPCode_ELB_5XX_Count measures the number of requests which were received by the ELB and which returned a response from one of the target instances.

• Surge Queue Length

SurgeQueueLength is the number of requests which have been received by the ELB, but are not able to be processed due to lack of availability of resources.

• Latency

Latency is the measure of time between the receipt of a request to the load balancer and the return of a response. High latency can result from different factors, including network connectivity, the configuration of the ELB, and resource-related constraints on the backend application servers.

Monitoring the specific metrics above will be invaluable in early detection of performance problems. The surge queue length is the number of requests which have been received by the ELB but are not able to be processed due to lack of availability of resources.

Configuring Your Load Balancer for Optimal Performance

AWS Load Balancers have been designed to work optimally with minimal configuration. If you experience a sudden degradation in performance of the ELB, the simplest solution is to replace the ELB with a new instance.

Your AWS support representative is also a beneficial resource for resolving performance concerns with ELBs. AWS support has additional tools and services at their disposal for troubleshooting performance issues which will save you both time and headaches.

The following configuration options may be useful as well. Options exist to change these values through the AWS Console, but they can also be modified through the AWS CLI:

Modifying the Idle Timeout

The ELB maintains two connections for each request: one between the client and the ELB, and the other between the ELB and the target instance. If the application does not generate a response, these connections remain open for 60 seconds by default.

The command below sets this timeout value to 20 seconds. Update the command with the timeout value you would prefer your load balancer to use and replace your-elb-name-here with the name of your load balancer.

Cross-Zone Load Balancing

Cross-Zone load balancing allows an ELB to direct traffic to instances both within the same availability zone and to other zones within the same region. This is useful if circumstances result in an imbalance of the number of instances between availability zones due to resizing efforts or unexpected instance termination. A best practice is to ensure that you maintain the same or a similar number of instances in each zone.

To enable cross-zone load balancing, execute the call below through the AWS CLI. Update the command with the timeout value you would prefer your load balancer to use and replace your-elb-name-here with the name of your load balancer. Cross-zone load balancing can also be disabled by replacing true with false.