Application Load Balancer vs Classic Load Balancer


Load balancer

Engine Yard announced support of AWS Application Load Balancer last December.

A load balancer accepts requests for your application and distributes them to different servers which run your Rails application. The load balancer is the entry point of all requests so it’s important that this is always up and running. An AWS load balancer is managed by AWS and is highly available and reliable.

In general, a load balancer can operate on the request level (Layer 7) or the connection level (Layer 4). At the connection level, we deal with lower level protocols like TCP and UDP. The load balancer doesn’t know whether it is distributing HTTP requests or something else.

At the request level, we deal with higher level protocols like HTTP. On this level, the load balancer knows that your user requested for a particular host (e.g. and a path (/images/logo.png). This is required if you need advanced routing rules that depend on the host and path.

The Classic Load Balancer operates on both the request and connection levels. However, it doesn’t support features like host and path based routing. This is the first load balancer that AWS introduced in 2009 so it is missing some features. The Application Load Balancer was introduced to address this. A Classic Load Balancer is recommended only for EC2 Classic instances.

The Application Load Balancer operates at the request level only. If you’re dealing with HTTP requests, which you are for your web application, you can use this. It supports the basic feature of distributing requests using the round robin algorithm. It also supports advanced features like host and path based routing.

You might also like:   Tutorial on how to use Active Storage on Rails 6.2

Let’s take a look at how to set up these features on an Application Load Balancer. An Application Load Balancer consists of Listeners, Rules, Target Groups.


An Application Load Balancer has one or more listeners. A listener has a protocol (HTTP or HTTPS) and a port (1-65535). For web applications, you normally use a listener for HTTP on port 80 and HTTPS on port 443. These are for requests to the http and https versions of your site. If you can, redirect all http requests to https. You need to do this on your servers because you can’t do this on the AWS load balancers. But this is another topic.


Each listener has a default rule which you can’t delete. This is for the basic feature of distributing all requests to the different servers.

You can also define additional rules. These can be rules to support host and path based routing. Since an Application Load Balancer operates on the HTTP level, it can see the HTTP requests complete with headers (e.g.

You can add a rule for the host and forward the requests to a specific set of servers. You can also add a rule for the path /images/* and forward the requests accordingly.

These rules allow you to do advanced routing that otherwise aren’t supported on a Classic Load Balancer.

Target Group

Each rule has a target group. This is the group of registered targets where requests are distributed to. A target can either be an EC2 instance or an IP address.

You can register a target to multiple target groups which allows you to use more advanced configuration. You can also register an EC2 instance or an IP address with the same target group multiple times using different ports. This is done to support load balancing to microservices.

You might also like:   Building a Vagrant Box: Setting up your Environment


The AWS Application Load Balancer provides more options for advanced routing. It should be your first choice when choosing a load balancer as the Classic version should only be used for the old EC2 instances.

To use an Application Load Balancer, you must learn the different components like Listeners, Rules, and Target Groups.

If you’re interested in using Application Load Balancer with your Rails applications, check out Engine Yard.

Want more posts like this?

What you should do now:


Easy Application Deployment to AWS

Focus on development, not on managing infrastructure

Deploying, running and managing your Ruby on Rails app is taking away precious resources? Engine Yard takes the operational overhead out of the equation, so you can keep innovating.

  • Fully-managed Ruby DevOps
  • Easy to use, Git Push deployment
  • Auto scaling, boost performance
  • Private, fully-configured Kubernetes cluster
  • Linear pricing that scales, no surprises
  • Decades of Ruby and AWS experience

14 day trial. No credit card required.

Sign Up for Engine Yard

14 day trial. No credit card required.

Book a Demo