AWS Elastic Load Balancing: Classic vs Application
On August 11, 2016, Amazon Web Services (AWS) introduced its new Application Load Balancer (ALB), a new load balancer allowing developers to direct and configure user traffic to apps in the public AWS cloud. This is a welcome feature that gives businesses deploying their stacks on AWS many more options when routing traffic to backend instances using Elastic Load Balancing (ELB).
The previously existing ELB product offering has now been renamed the Classic Load Balancer, and is still an option when configuring the ELB through either the API or via the AWS Console.
[Learn More: ELB vs ALB]
Operational Visibility From AWS
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!
So, what are the basic differences between Classic Load Balancer and Application Load Balancer?
Classic Load Balancing. This more closely resembles traditional load balancing, but virtual devices replace physical hardware to evenly distribute your incoming requests and ensure clean, fast user experience.
Application Load Balancing. Application load balancing identifies incoming traffic and directs it to the right resource type. For example, URLs tagged with /API extensions can be routed to the appropriate application resources, while traffic bound for /MOBILE can be directed to resources managing mobile access.
[Learn More: Sumo Logic Elastic Load Balancing]
Which load balancers support EC2 Classic?
The Classic Load Balancer supports EC2 Classic, whereas the Application Load Balancer does not.
How many load balancers do I need?
As a best practice, you want at least two load balancers in a clustered pair. If you only have a single load balancer and it fails for any reason, then your whole system will fail. This is known as a Single Point of Failure (SPOF). With load balancers, the number you require depends on how much traffic you handle and how much uptime availability you want. Generally, the more load balancers you have, the better.
Want to dive deeper into the differences? See our detailed comparison of CLB and ALB below.
Understanding the Classic Load Balancer
The Classic ELB has a number of features available to help provide high availability, AWS monitoring, and better security for your application stack.
The AWS Classic Load Balancer (CLB) operates at Layer 4 of the OSI model. What this means is that the load balancer routes traffic between clients and backend servers based on IP address and TCP port.
For example, an ELB at a given IP address receives a request from a client on TCP port 80 (HTTP). It will then route that request based on the rules previously configured when setting up the load balancer to a specified port on one of a pool of backend servers. In this example, the port on which the load balancer routes to the target server will often be port 80 (HTTP) or 443 (HTTPS).
The backend destination server will then fulfill the client request, and send the requested data back to the ELB, which will then forward the backend server reply to the client. From the client’s perspective, this request will appear to have been entirely fulfilled by the ELB. The client will have no knowledge of the backend server or servers fulfilling client requests.
[Learn More: Route 53 Load Balancer]
Classic ELB and Availability Zones
Though it is possible to have a single server behind a load balancer, it is best to have a pool of servers behind an ELB. It’s also a matter of best practice to have multiple servers in multiple Availability Zones within a region to support high availability. That way, if an AZ becomes unavailable for some reason, the ELB can route traffic to AZs which are accessible, and avoid the inaccessible AZ while it is unavailable.
In the default configuration, the Classic Load Balancer will route traffic evenly between Availability Zones (AZ) that are enabled in the ELB. Due to the way some clients handle DNS, load imbalance can occur if there aren’t an equal number of servers to answer requests in each AZ with this configuration. With cross-zone load balancing enabled, traffic will be distributed evenly amongst all instances in all Availability Zones that are enabled in the ELB.
Enabling cross-zone load balancing will help to mitigate potential load imbalance and also ensure better availability of your application. For the sake of consistency and ease of maintenance, it is also recommended to maintain equal numbers of target instances in each availability zone.
Understanding the Application Load Balancer
AWS Application Load Balancer (ALB) operates at Layer 7 of the OSI model. At Layer 7, the ELB has the ability to inspect application-level content, not just IP and port. This lets it route based on more complex rules than with the Classic Load Balancer.
In another example, an ELB at a given IP will receive a request from the client on port 443 (HTTPS). The Application Load Balancer will process the request, not only by receiving port, but also by looking at the destination URL.
Multiple services can share a single load balancer using path-based routing. In the example given here, the client could request any of the following URLs:
- Application Load Balancer will be aware of each of these URLs based on patterns set up when configuring the load balancer, and can route to different clusters of servers depending on application need. Rules can also be added at a later time as you add new functionality to your stack.
- The Application Load Balancer also integrates with EC2 Container Service (ECS) using Service Load Balancing. This allows for dynamic mapping of services to ports as specified in the ECS task definition. Multiple containers can be targeted on the same EC2 instance, each running different services on different ports. The ECS task scheduler will automatically add these tasks to the ALB.
Key ALB Concepts
There are some key concepts that you will need to know when configuring your ALB. The first is rules. Each rule specifies a condition, target group, and a priority.
- Rules determine what action is taken when a rule matches a client request. Up to 10 URL-based rules can be defined in the ALB.
- The condition is the path pattern you want the ALB to evaluate in order for it to route requests.
- The target group is used to route requests to registered targets as part of an action for a rule. Target groups specify a protocol and target port. Health checks can be configured per target group. An ALB can route to multiple target groups.
- Targets specify the endpoints and are registered with the ALB as part of a target group.
- Priority tells the ALB in which order to evaluate the rules. Rules are numerically evaluated in order from lowest to highest value. When a rule matches a request, traffic will be routed to the specified target group.
The Application Load Balancer can be implemented via the Amazon API, and you may unlock more architectures and solutions with the ALB than the classic version.
[Learn More: ELB Health Check]
Get up to 70% cost savings
Try Sumo Logic today to optimize your AWS costs
Comparing the CLB and the ALB
While the CLB and ALB share some features, it’s important to be aware of how they differ from each other. Let’s looks at the notable differences between the two.
CLB vs ALB Feature Comparison
| Classic Load Balancer | Feature | Application Load Balancer |
| User must enable cross-zone load balancing where it is disabled by default | High Availability | Automatically scales capacity to handle the number of incoming requests |
| CLB automatically detects unhealthy instances | Health Checks | ALB allows the user specify a range of HTTP response codes that define instance health |
| CLB supports custom application cookies | Sticky Sessions | ALB only supports the cookies generated by the load balancer |
| Yes, including EC2-Classic | VPC Support | Yes, but without EC2-Classic |
| No, CLB only supports fixed mappings between listener and target hosts | Dynamic Port Mapping | Yes, ALB supports dynamic port mapping using the EC2 Container Service |
| HTTP, HTTPS, TCP, SSL | Supported Protocols | HTTP, HTTPS, HTTP/2, WebSockets |
| Only allows for monitoring of a single port, and the HTTP 200 response code | Cloudwatch Metrics Supported | Per port and path monitoring Range HTTP response codes Connections per hour Active connections Overall traffic volume |
| CLB supports ELB access logs | Access Logs | ALB supports type of request (HTTP, HTTPS, HTTP/2, WebSockets), and the target Amazon Resource Name |
| Not supported by CLB | Backend Server Authentication | Supported by ALB |
| Not supported by CLB | Deletion Protection | Supported by ALB |
| Not supported by CLB | Path-Based Routing | Supported by ALB |
CLB vs ALB: What Do the ELBs Have in Common?
Despite their differences, CLB and ALB do retain a number of similarities. Here’s a brief rundown.
- Security Groups: Using a Virtual Private Cloud (VPC), you can create and manage security groups associated with instances and load balancers to provide additional security to your application stack.
- SSL Termination: Terminating your SSL on the ELB allows you to offload SSL processing from your application servers to the ELB. This will free up compute resources on your application servers, and also allow for a centralized place to manage SSL certs when they are put on ELBs.
- Idle Connection Timeout: Both load balancers support configurable idle connection timeout, which terminates connections that exceed a time threshold where no data is sent between client and server. A configurable timeout is desirable when it takes backend servers longer to fulfill requests than the ELB default of 60 seconds.
- Connection Draining: With connection draining, you can gracefully remove instances from the ELB without prematurely terminating client connections. This is supported in both the Classic and Application Load Balancer.
Gain deep insights into your AWS ecosystem with Sumo Logic for AWS operations and log management.
CLB vs ALB: Pricing Considerations
With the features covered we’ll now consider the pros and cons of pricing models for the Classic Load Balancer as compared to the newer Application Load Balancer.
[Learn More: ELB vs NGINX]
Classic Load Balancer Pricing
Determining pricing for the Classic Load Balancer is the same as it was prior to the addition of Application Load Balancer, and varies based on the AWS Region in which it is deployed. At this time, US-East-1 (Northern Virginia) and US-West-1 (Oregon) are the least expensive, with SA-East-1 (Sao Paulo) being the most expensive.
Classic Load Balancer in US-East-1 will cost $0.025 per hour (or partial hour), plus $0.008 per GB of data processed by the ELB.
Use the AWS Simple Monthly Calculator to help you determine the load balancer pricing for your application. Just look under the EC2 tab on the left side of the page.
Application Load Balancer Pricing
Calculating pricing for the Application Load Balancer is somewhat more complex, and we’ll only just touch on it in this article.
Pricing for ALB is based on an Application Load Balancer hour (or partial hour), plus the number of Load Balancer Capacity Units per hour (or partial hour).
A Load Balancer Capacity Unit (LCU) is based on the highest usage dimension of one of the following:
- Number of new connections per second (up to 25 new connections per second is one LCU)
- Number of active connections per minute (up to 3,000 active connections per minute is one LCU)
- Bandwidth measured in Mbps (up to 2.22 Mbps is one LCU)
In the US-East-1 region, the Application Load Balancer runs $0.0225 per hour (or partial hour), plus $0.008 per LCU-hour (or partial hour).
As you can see, estimating costs for Amazon’s Application Load Balancer is fairly complicated. In order to accurately forecast your monthly costs, you will need to first know the estimated number of new connections per second, the connection time for those connections, and the bandwidth used in Mbps.
ALB vs CLB: Which ELB is Best For You?
In this article, we’ve given you a comparison of Amazon Web Services Classic and the Application Load Balancer, along with details on many of the features that both offers.
Your mileage will vary depending on your exact situation, of course. But in general, the Classic Load Balancer is likely to be the best choice if your routing and load-balancing needs can all be handled based on IP addresses and TCP ports.
In contrast, the Application Load Balancer can address more complex load-balancing needs by managing traffic at the application level. This is especially advantageous for next-generation infrastructure, such as that based on containers, or if you are building complex web applications in which requests for certain components should be directed to one cluster, while others go to a different one.
Still unsure if you’re better off with CLB or ALB? Get guidance of how to choose.
Easily Monitor and Manage Your AWS ELB
Whether you use CLB or ALB as your load balancer — or if you use both at the same time, for different environments — maintaining a healthy AWS environment requires monitoring of your ELB and user traffic.
Get up to 70% cost savings
Try Sumo Logic today to optimize your AWS costs
