AWS Elastic Load Balancing: Classic vs Application
On August 11, 2016, Amazon Web Services introduced its new Application Load Balancer on the AWS Blog. 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.
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.
Understanding the Classic Load Balancer
The Classic ELB has a number of features available to help provide high availability, 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.
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.
For more information see AWS Elastic Load Balancing Best Practices.
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:
The 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.
ALB Use Cases
For an excellent rundown on use cases for Application Load Balancer, and how these can be implemented via the Amazon API, see Introducing Application Load Balancer – Unlocking and Optimizing Architectures.
Comparing the CLB and the ALB
There are a number of features that are shared between both AWS load balancer offerings, and some that are specific to each.
The following is a summary of key features and how they are supported in each offering:
- High Availability: Incoming traffic can be distributed across multiple EC2 instances within an AZ, or traffic can be distributed across multiple AZs. The ELB will automatically scale capacity to handle the number of incoming requests. The Application Load Balancer automatically supports cross-zone load balancing, whereas you will need to enable it in the Classic Load Balancer, where it is disabled by default.
- Health Checks: Both load balancers have the ability to detect EC2 instance health. If the ELB detects an unhealthy instance, it will avoid sending traffic to the unhealthy instance or instances and instead send it to only healthy instances. In the case of ALB, you can specify a range of HTTP response codes that constitute a healthy response.
- 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.
- Sticky Sessions: Sticky sessions allow the load balancer to stick client sessions to specific backend EC2 instances with cookies. If a client makes a request to the ELB, it will be cookied, and the request routed to a specific backend server. All future requests from the client will be routed to the same backend server. This is useful when your application is stateful and requires specific client requests be routed to the same backend server each time.
- VPC: Both load balancer offerings have VPC support, but the Classic Load Balancer also supports EC2-Classic. The Application Load Balancer does not support EC2-Classic.
- 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.
- Dynamic Port Mapping: Classic Load Balancer only supports fixed mappings between listener and target hosts. The Application Load Balancer supports dynamic port mapping using the EC2 Container Service.
- Protocols: HTTP and HTTPS are supported by both ELBs. The Classic Load Balancer also supports TCP and SSL in addition to the above. Application Load Balancer supports HTTP/2 and WebSockets in addition to HTTP and HTTPS. TCP and SSL listeners are not currently supported by ALB.
- Backend Server Auth: Classic Load Balancer supports backend server auth. Application Load Balancer does not.
- Cloudwatch Metrics: CLB supports Cloudwatch Metrics. ALB supports an enhanced version, which provides for per port and per path monitoring of load balanced services, where a range of acceptable HTTP response codes are permissible. In contrast, Classic Load Balancer only allows for monitoring of a single port, with the HTTP 200 response code. ALB includes three additional Cloudwatch metrics: connections per hour, active connections, and overall traffic volume.
- Access Logs: Classic Load Balancer supports ELB access logs. Application Load Balancer supports an enhanced version, that adds type of request (e.g. HTTP/HTTPS, HTTP/2 over SSL/TLS, WebSockets, and WebSockets over SSL/TLS), and the target Amazon Resource Name.
- Path-based routing: ALB supports path-based routing (covered earlier in this article). This feature is not supported by CLB.
- Deletion Protection: ALB supports deletion protection, whereas CLB does not.
CLB vs ALB: Pricing Considerations
Here we’ll consider the pros and cons of pricing models for the Classic Load Balancer as compared to the newer Application Load Balancer.
Classic Load Balancer Costs
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.
See Amazon’s Classic Load Balancer pricing page for examples of how to calculate pricing on CLB. In addition, you can also 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 Costs
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.
Review the Application Load Balancer pricing page to better understand how you will be charged for usage when deploying ALB. The AWS Simple Monthly Calculator does not currently support calculating pricing for the Application Load Balancer.
Determining the ELB Option That’s 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.
Whichever load balancer you choose to use on AWS — or if you use both at the same time, for different environments — you can use the Sumo Logic App for AWS ELB to help monitor your AWS traffic and gain visibility into your ELBs.
AWS: Elastic Load Balancing
AWS: What Is Elastic Load Balancing?
AWS: Classic Load Balancer Details
AWS: Application Load Balancer Details
AWS: AWS Application Load Balancer
AWS: Service Load Balancing
AWS: Powerful AWS Platform Features, Now for Containers
AWS: Introducing Application Load Balancer – Unlocking and Optimizing Architectures
Sumo Logic: AWS Elastic Load Balancing – New Visibility Into Your AWS Load Balancers
Sumo Logic: Monitoring AWS Auto Scaling and Elastic Load Balancers with Log Analytics
Sumo Logic: App for AWS ELB