Our approach resulted in a doubling of our log ingestion at an ingest cost increase of only 10%, saving us around $1 million.”
Iwan Eising
Team Lead of Service Reliability Architecture
BY OBSERVABILITY USE CASE
BY SECURITY USE CASE
BY INITIATIVE
BY COMPETITION
March 28, 2018
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 is the Elastic Load Balancer (ELB)? The Elastic Load Balancer (ELB) was released by AWS in the spring of 2009. The AWS 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.
[Learn More: AWS Monitoring]
What is the Application Load Balancer (ALB)? 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.
Machine data holds hidden secrets that deliver true insights about the operational health of your AWS infrastructure. Learn more about operational visibility from AWS today!
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 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:
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
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.
Try Sumo Logic today to begin optimizing your AWS costs.
Build, run, and secure modern applications and cloud infrastructures.
Start free trial
Mike Mackrory is a Global citizen who has settled down in the Pacific Northwest — for now. By day he works as a Lead Engineer on a DevOps team, and by night, he writes and tinkers with other technology projects. When he's not tapping on the keys, he can be found hiking, fishing and exploring both the urban and rural landscape with his kids. Always happy to help out another developer, he has a definite preference for helping those who bring gifts of gourmet donuts, craft beer and/or single-malt Scotch.
More posts by Mike Mackrory.
No credit card required. Up and running in minutes.
More than 2,100 enterprises around the world rely on Sumo Logic to build, run, and secure their modern applications and cloud infrastructures.
