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.
The Application Load Balancer supports WebSocket and HTTP/2. This is good news if you're using ActionCable in your Rails application.
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. admin.example.com).
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.
New CloudWatch metrics include overall traffic (in GB), number of active connections, and the connection rate per hour.
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.
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.