Move to the Next Level of Load Balancing on AWS

Andreas Wittig – 08 Jul 2017

Are you still using the Classic Load Balancer - formerly known as Elastic Load Balancer - for distributing incoming requests among a fleet of EC2 Instances? AWS announced the Application Load Balancer, as a new alternative to the Classic Load Balancer in November 2016. It’s about time to benefit from the next-generation load balancer!

The Classic Load Balancer, as well as the Application Load Balancer, are managed services provided by AWS offering high availability and scalability out-of-the-box.

But what are the differences between the Classic Load Balancer and the Application Load Balancer?

Classic Load Balancer Application Load Balancer
Load Balancing Type Layer 4 or Basic Layer 7 Advanced Layer 7
Supported Protocols TCP, SSL (secure TCP), HTTP, HTTPS HTTP, HTTPS, HTTP/2, WebSockets
Path- and Host-Based Routing ❌ n/a ✅ out-of-the-box
EC2 Container Service support ❌ n/a ✅ out-of-the-box
Web Application Firewall ❌ n/a ✅ out-of-the-box

Let’s dive into the details of two of these differences.

Path- and Host-Based Routing

Are you operating load balancers (e.g. HAProxy) on top of EC2 Instances yourself to provide path- or host-based routing? The chances are high that you can simplify your infrastructure by using an Application Load Balancer.

Routing incoming requests based on path or host headers, as shown in the following figure, is possible with the Application Load Balancer by default.

ALB Routing

The following steps are needed to configure an Application Load Balancer:

Andreas and Michael Wittig

Hej, Andreas & Michael here!

We launched the cloudonaut blog in 2015. Since then, we have published 325 articles: small tips and tricks, best practices, and service reviews. We enjoy writing about all things AWS a lot.

Do you like our blog posts and podcast episodes? Have you learned something new? Consider supporting us create in-depth and independent AWS content. Please help us with a monthly or one-time payment through GitHub Sponsors.

Start supporting us today!
  1. Add a Listener to your Application Load Balancer by specifying a port and protocol.
  2. Create a Target Group.
  3. Register a Target, consisting of an EC2 Instance ID and port, at your Target Group.
  4. Define a Listener Rule mapping incoming requests based on path or host with your Target Group.

Works with ECS

The EC2 Container Service (ECS) provides a container management service. ECS is distributing your containers across a fleet of EC2 Instances. To be able to send requests to one of the containers providing a particular service a client needs to know where to send its requests. But as ECS needs to launch containers dynamically based on load, during deployments or because of a failure within the cluster it is not an option to use static ports and IP addresses.

As shown in the following figure ECS is integrated with the Application Load Balancer. Whenever ECS launches a new container, a dynamic port is assigned and registered as a target at a Target Group.


A client sends its request to the Application Load Balancer. The Application Load Balancer is forwarding the request to a dynamic port mapped to a container running on one of the EC2 Instances that are forming the ECS cluster.


The Application Load Balancer provides powerful features as path- and host-based routing, integration with ECS, as well as HTTP/2 and WAF support.

It’s about time to use the Application Load Balancer for new infrastructures and migrate from Classic Load Balancers to Applications Load Balancers within existing infrastructures as well.

Want to learn more about the Application Load Balancer? In our A Cloud Guru online course Deep Dive into Application Load Balancer, we’ll introduce you to the Application Load Balance in AWS, and show you how to take advantage of its powerful features. Nine hands-on labs and console walkthroughs will increase your skills and enable you to gain practical experience with the Application Load Balancer (ALB).

Tags: aws elb alb
Andreas Wittig

Andreas Wittig

I'm an independent consultant, technical writer, and programming founder. All these activities have to do with AWS. I'm writing this blog and all other projects together with my brother Michael.

In 2009, we joined the same company as software developers. Three years later, we were looking for a way to deploy our software—an online banking platform—in an agile way. We got excited about the possibilities in the cloud and the DevOps movement. It’s no wonder we ended up migrating the whole infrastructure of Tullius Walden Bank to AWS. This was a first in the finance industry, at least in Germany! Since 2015, we have accelerated the cloud journeys of startups, mid-sized companies, and enterprises. We have penned books like Amazon Web Services in Action and Rapid Docker on AWS, we regularly update our blog, and we are contributing to the Open Source community. Besides running a 2-headed consultancy, we are entrepreneurs building Software-as-a-Service products.

We are available for projects.

Feedback? Questions? Drop me a line: Email, Twitter, LinkedIn.

Briefcase icon
Hire me