Application Load Balancer


Engine Yard announces support for Application Load Balancing. This new feature gives you the option to choose between a Classic Load Balancer and an Application Load Balancer.


The original ELB Classic Load Balancer supports both Layer 4 (TCP) and Layer 7 (HTTP) load balancing. Choose this if you are using EC2 Classic Instances or if you need Layer 4 load balancing.

The Application Load Balancer supports Layer 7 load balancing. It has a number of features that a Classic Load Balancer does not have. We recommend that you use an ALB unless you need Layer 4 load balancing. If you're not sure which load balancer to use, contact our Support team.

ALB Features

Additional Protocols

The Application Load Balancer supports WebSocket and HTTP/2. This is good news if you're using ActionCable in your Rails application.

Advanced Routing

An Application Load Balancer operates on Layer 7 where it has access to the HTTP requests and headers. It can route traffic to specific EC2 instances based on the path (e.g. /api) or based on the host (e.g.

Better Health Checks

Application Load Balancers use health checks to determine if the target instances are healthy. If the instances fail the health checks, the load balancer takes them out of service. You can set the HTTP response codes that are considered successful from 200 to 499. The Classic Load Balancer only accepts 200 as the successful HTTP response.

Better Metrics

New CloudWatch metrics include overall traffic (in GB), number of active connections, and the connection rate per hour.

Lower Pricing

Pricing differs depending on the region. ALBs are charged by the hour plus LCU-hour. A Load Balancer Capacity Unit (LCU) measures 4 dimensions and only the highest usage is charged.

An LCU contains 25 new connections per second, 3,000 active connections per minute, 2.22Mbps bandwidth, and 1,000 rule evaluations per second.

This sounds more complex but bottom line ALB pricing is lower than Classic Load Balancer pricing.

Creating an ALB

Step 1. Enable the ALB Early Access Feature

The ALB feature is available under Early Access. Open a Support ticket and we'll enable the feature for you.

Step 2. Click Tools > App Load Balancers


Step 3. Click the Add Load Balancer Button
Step 4. Select an Environment and Certificate

Select an environment. Your environment must have a VPC network attached. Create a new VPC network if necessary then attach it to the environment. If you have existing instances running, replace them with new instances after attaching the VPC network. Alternatively, you can create a new environment with a VPC network attached.

Some regions also use a default VPC depending on your account. Read here for more details on using VPCs at Engine Yard.

Enter a name. This will be used for the load balancer's hostname and must be unique within an account.

Select an SSL certificate. This is optional. If you choose an SSL certificate, load balancer port 443 will be forwarded to 8081 on stable-v5. Without an SSL certificate, only load balancer port 80 will be forwarded to 8081 on stable-v5. On stable-v4, internal port 81 is used instead of 8081.

Enter a health check path. The default is '/'. The check will be done over HTTP on the internal traffic port of the ELB.


Step 5. Wait for Provisioning

It takes a minute or two to provision the ALB. When it's provisioned, you will see the hostname, a link to the AWS console, the number of nodes/instances on the ALB, and the service that forwards load balancer port 80 to internal port 8081 (on stable-v5).

If you selected an SSL certificate, you'll see a second service that forwards load balancer port 443 to internal port 8081 (on stable-v5).


Updating an ALB

You can add or change the SSL certificate of the ALB port 443 by clicking Edit on the top right of the screenshot above.


You can add a service to forward a custom port of the load balancer to an internal port on the instances.


Questions and Feedback

We like to hear from you. Open a ticket if you have questions or feedback regarding ALB.

Free Ebook: PaaS Is Dead

Platform as a Service (PaaS) is experiencing a digital transformation, and despite what some may argue, it’s far from dead. Learn why PaaS continues to prove it has a promising future for DevOps.

PaaS Is Dead

Related posts

It's Almost Time For Ruby Conf 2018!

November 6, 2018

It’s autumn and November is right around the corner! We all know what this means…

Read More

Auto Scaling

December 8, 2017

Engine Yard announces support for AWS Auto Scaling.

Read More

MySQL Replication Tutorial For Disaster Recovery

November 16, 2017

This blog post is a step by step tutorial on how to set up MySQL Replication between AWS

Read More

Christopher Rigor

Christopher Rigor is a Senior Technical Evangelist at Engine Yard. He’s a long time Rails user, system administrator, and recently became a contributor of RailsInstaller. Previously, he was the DevOps Support Manager for Asia-Pacific at Engine Yard.
Find me on:


Subscribe to our Blog