Classic Load Balancer (ELB) vs Application Load Balancer (ALB)
Understanding the Classic Load Balancer:
- 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
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.
- For 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.
Comparing the ELB and the ALB
Below table is the comparison between ELB & ALB
|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||Create and manage security groups associated with instances and load balancers to provide additional security to your application stack.||Create and manage security groups associated with instances and load balancers|
|Dynamic Port Mapping||Elastic Load Balancer only supports fixed mappings between listener and target hosts.||The Application Load Balancer supports dynamic port mapping using the EC2 Container Service. Please refer the below link|
|Protocols:||HTTP, HTTPS, SSL, TCP||Application Load Balancer supports HTTP/2 and Web Sockets in addition to HTTP and HTTPS. TCP and SSL listeners are not currently supported by ALB.|
|Backend Server Auth||Elastic Load Balancer supports backend server auth||Application Load Balancer does not.|
|Cloudwatch Metrics:||Elastic load Balancer supports Cloudwatch Metrics
Classic Load Balancer only allows for monitoring of a single port, with the HTTP 200 response code.
|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.
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||This feature is not supported by ELB.||ALB supports path-based routing|
|Deletion Protection||This feature is not supported by ELB.||ALB supports deletion protection|
|Cost||· Classic Load Balancer in $0.025 per Elastic Load Balancer-hour (or partial hour)
· $0.008 per GB of data processed by an Elastic Load Balancer
|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)