If you use Amazon Web Services, you have two load balancing options for your applications: Classic Elastic Load Balancer (CLB) and Application Load Balancer (ALB). And while choice is always good, the CLB vs. ALB debate can be intimidating. Which load balancer is right for your application? Is ALB better than CLB, or vice versa? This blog explores these questions.

What is a load balancer?

When you allocate more than one server to handle requests for a website or business application, a load balancer is used to distribute requests between them. The purpose of a load balancer is to spread requests between a group of servers, preventing any individual server from becoming overloaded with requests. An overworked server can lead to slow-downs, timeouts, and mishandled or lost requests that negatively impact the customer experience.

AWS Elastic Load Balancer is a web service to help improve the availability and performance of applications by automatically distributing incoming application traffic among multiple targets, such as AWS EC2 instances, containers, and IP addresses, in one or more Availability Zones. The software is designed to keep track of the health of its registered targets. If any target appears unhealthy, the traffic is automatically routed away from that target to another healthy one. Elastic load balancing scales the load balancers as traffic changes over time, and facilitates auto scaling to the vast majority of workloads.

What are the differences between Classic Load Balancer and Application Load Balancer?

AWS Classic Load Balancer (CLB) more closely resembles traditional load balancing, but virtual devices replace physical hardware to evenly distribute your incoming requests and ensure a clean, fast user experience.

AWS Application Load Balancer (ALB) identifies traffic and directs it to the right resource type. For example, URLs tagged with /API extensions can be routed to appropriate application resources, while traffic bound for /MOBILE can be directed to resources managing mobile access.

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 incoming application traffic you handle and how much uptime availability you want. Generally, the more load balancers you have, the better.

The CLB and ALB can be implemented via the Amazon API, or via the AWS Management Console. The CLB supports EC2 Classic—planned for retirement—while the ALB does not.

Want to dive deeper into the differences? See our detailed comparison of CLB and ALB below.

Understanding the Classic Load Balancer

The CLB has many features available to help provide high availability, AWS monitoring, and better security for your application stack. CLB operates at Layer 4 of the OSI model. This means routes traffic between clients and backend servers based on IP address and TCP port.

For example, a CLB 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 CLB, which will then forward the backend server reply to the client. From the client’s perspective, this request appears to have been entirely fulfilled by the load balancer. The client will have no knowledge of the backend server or servers fulfilling client requests.

Classic Load Balancer and Availability Zones

For the best results, it is recommended to have a pool of servers behind a CLB, though it is possible to have a single server. 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 Availability Zone (AZ) becomes unavailable for some reason, the load balancer can route traffic to other accessible AZs, and avoid the inaccessible AZ while it is unavailable.

In the default configuration, the CLB routes traffic evenly between AZs enabled by the load balancer. Due to the way some clients handle DNS, load imbalance can occur if there are not the same number of servers to answer requests in each AZ with this configuration. With cross zone load balancing enabled, traffic will be distributed evenly among all instances in all AZs enabled in the CLB.

Enabling cross zone load balancing helps mitigate potential load imbalance. It also ensures better availability of your application. For consistency and ease of maintenance, it is also recommended to maintain equal numbers of target instances in each AZ.

Understanding the Application Load Balancer

The ALB operates at Layer 7 of the OSI model. At Layer 7, the ALB can inspect application-level content, not just IP and port. This allows it to route based on more complex rules than with the CLB.

In another example, the ALB at a given IP will receive a request from the client on port 443 (HTTPS). The ALB will process the request, not only by receiving port, but also by looking at the destination URL.

Multiple services can share a single balancer using path-based routing. In the example given here, the client could request any of the following URLs:

• The ALB will know each of these URLs based on patterns set up when configuring the balancer, and can route to different clusters of servers depending on application need. Rules can also be added later, as you add new functionality to your stack.
• The ALB also integrates with Amazon Elastic Container Service (ECS) using Service Load Balancing. This allows for dynamic mapping of services to ports, as specified in the Amazon ECS task definition. Multiple containers can be targeted on the same Amazon EC2 instance, each running different services on different ports. The ECS task scheduler automatically adds 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 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. Each rule can optionally include one of a few conditions.

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.

Priority dictates the order in which the ALB evaluates 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.

How do Classic Load Balancer and Application Load Balancer compare?

CLB vs ALB: What Do They Have in Common?

Despite their differences, the CLB and the ALB have many 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 other AWS load balancers (e.g. AWS Gateway Load Balancer and AWS Network Load Balancer) to provide additional security to your application stack.
• SSL Termination: Terminating your SSL on AWS Elastic Load Balancer (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 a centralized place to manage SSL certs when they are put on ELBs.
• Idle Connection Timeout: Both 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 an EC2 instance from the AWS load balancer without prematurely terminating client connections. This is supported in both CLB and ALB.

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 CLB compared to the ALB.

CLB pricing

The AWS Region determines CLB’s pricing in which it is deployed. 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.

ALB pricing

Calculating pricing for the Application Load Balancer is somewhat more complex, and we’ll only just touch on it. Pricing for ALB is based on an ALB hour (or partial hour), plus the number of Load Balancer Capacity Units (LCUs) per hour (or partial hour). An 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)

To accurately forecast your monthly costs, you will first need to 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 blog, we’ve given you a comparison of the Classic Load Balancer and the Application Load Balancer, along with details on many features that both offer.

Your mileage will vary depending on your exact situation, of course. But in general, the Classic Elastic 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 AWS 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, based on containers and microservices, 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.

How can we help you easily monitor and manage AWS Elastic Load Balancers?

Whether you use CLB or ALB as your AWS elastic load balancer – or if you use both simultaneously for different environments – maintaining a healthy AWS environment requires monitoring your load balancers and user traffic.

AWS Observability solution supports a variety of services, including Application ELB and Network ELB (along with other popular AWS services, such as Lambda). It can be deployed across multiple accounts and regions to provide you with a unified view of your AWS environment.

AWS Elastic Load Balancing Integrations for help you optimize your AWS ELB configuration with visual log analytics and allows you to monitor your AWS ELB configurations in real-time. The Sumo Logic Apps for Elastic Load Balancing ingests logs generated by this activity, providing greater visibility into events that help you understand the overall health of your EC2 deployment. To onboard the Sumo Logic Apps for AWS load balancers is fast and secure.

The App for AWS Elastic Load Balancer Classic is a unified logs and metrics app that helps you monitor the CLB. The pre-configured dashboards provide information on latency, HTTP backend codes, requests, and host status, which help you investigate the issues in the load balancer. CLB logs are stored as *.log files in the buckets you specify when you enable logging. The process to enable collection for these logs is described in AWS ELB Enable Access Logs.

The app for AWS Elastic Load Balancer – Application ingests the logs stored in an S3 bucket, giving you visibility to see the overall health of your ALB and target groups. You can use the Sumo Logic App to analyze the raw ALB data to investigate the availability of applications behind ALBs. Or, you can correlate the ALB data with other data sets to get a broader understanding of the fault tolerance of your applications across multiple AZs.

The App for AWS ELB Metrics lets you analyze the Amazon CloudWatch metrics for the CLB and ALB. The App provides pre-configured searches and dashboards that allow you to monitor the metrics healthy hosts, unhealthy hosts, HTTP backend codes, latency, requests, and more.

The App for AWS Network Load Balancer uses metrics to provide insights to ensure that your network load-balancers are operating as expected, backend hosts are healthy, and quickly identify errors.