Choosing Between an ELB and an ALB on AWS

If you use AWS, you have two load-balancing options: ELB and ALB. And while choice is always a good thing, the ELB vs. ALB debate can be intimidating. Which load balancer is right for your application? Is ALB better than ELB, or vice versa? This article explores these questions.

What Are the ELB and ALB?

The Elastic Load Balancer (ELB) was released by AWS in the spring of 2009. An ELB is a software-based load balancer which can be set up and configured in front of a collection of AWS Elastic Compute (EC2) instances. The load balancer serves as a single entry point for consumers of the EC2 instances and distributes incoming traffic across all machines available to receive requests.

In addition to providing a single point of entry, the ELB also performs a vital role in improving the fault tolerance of the services which it fronts. The ELB regularly conducts a health check of all instances which have been registered with it, and only routes traffic to those machines which respond as active and healthy to the health check.

In 2016, AWS augmented its Classic ELB offering with an Application Load Balancer (ALB). The Classic ELB and the ALB share commonalities in function, but the ALB has been specialized to provide users with enhanced capabilities. In this article, we’re going to investigate the unique functionality offered by each and consider cases where you would decide to implement one instead of the other.

The OSI Model

Fundamental to understanding the significant differences between the Classic ELB and the ALB is identifying the differences in how they handle and route requests. And the key to this is a basic understanding of the OSI Model. The Open Systems Interconnection Model, or OSI Model, is a conceptual model which is used to facilitate communications between different computing systems.

Individual layers within the OSI Model are supported by the layer below it. Layer 1 is the physical layer, and represents the physical medium across which the request is sent. This medium could be an optical fiber, CAT-5 cable or another transport technology. Layer 2 describes the data link layer, Layer 3 (the network layer), and on up until Layer 7, which serves the application layer. You can learn more about the OSI layer and its history on Wikipedia.

The Classic ELB operates at Layer 4. Layer 4 represents the transport layer, and is controlled by the protocol being used to transmit the request. For web applications, this will most commonly be the TCP/IP protocol, although UDP may also be used. A network device, of which the Classic ELB is an example, reads the protocol and port of the incoming request, and then routes it to one or more backend servers.

In contrast, the ALB operates at Layer 7. Layer 7 represents the application layer, and as such allows for the redirection of traffic based on the content of the request. Whereas a request to a specific URL backed by a Classic ELB would only enable routing to a particular pool of homogeneous servers, the ALB can route based on the content of the URL, and direct to a specific subgroup of backing servers existing in a heterogeneous collection registered with the load balancer.

The Classic ELB: An AWS Original

The Classic ELB is a simple load balancer, is easy to configure, and given its longer history as a product, most AWS engineers are familiar with the product and have used it in the past. If your environment consists of clearly defined services which can each be mapped to a specific address, then the Classic ELB is the logical choice.

Like the more advanced ALB, the Classic ELB supports:

• SSL Termination
• Sticky Sessions
• Termination of Idle Sessions
• Completion of Requests to Instances In The Process Of Being Marked Unhealthy.

The ALB: Perfect for Content-Based Routing

As organizations move towards microservice architecture or adopt a container-based infrastructure, the ability to merely map a single address to a specific service becomes more complicated and harder to maintain.

In addition to the common features mentioned above (i.e. SSL Termination, Sticky Sessions, etc.), the ALB manages routing based on user-defined rules. A request to a URL which resolves to a single ALB can in turn route traffic to different services based on either the host or the content of the path contained within that URL.

Let’s take a quick look at some of the additional functionality available to you after you’ve created your Application Load Balancer. If you log into your AWS console and navigate to the Load Balancer section of the EC2 home page, you’ll be able to create new and edit existing load balancers. If you click on an existing ALB, you’ll be shown a series of tabs with additional information and configuration for the load balancer.

Much like the Classic ELB, when you click on the Listeners tab, you’ll be able to add additional listeners and point them to different targets. Where the ALB differs is the link to View/edit rules.

1. Viewing Listeners for Your ALB

Clicking on the View/edit rules link allows you to add, edit and remove routing rules for this listener. Rules can be path or header-based and each directed to a defined target group. A default action is required and contains the Target Group to be routed to if none of the preceding rules match the request.

2. Managing Content-Based Rules On Your ALB

Which One Should You Pick?

This decision ultimately depends on your environment. If you are currently supporting an environment where each collection of servers has its load balancer, and there is a direct mapping between URL and service, the Classic ELB is probably the best option for you.

In my current projects, we’re working with EC2-based microservices and considering implementing container-based infrastructure as we move forward. A significant part of our roadmap involves migrating to Application Load Balancers, and I’m excited about the additional control we’re going to have at our fingertips.

The beauty of these products is that both are good options, and are supported within your Sumo Logic account.