Application Load Balancer (ALB) – Scaler Topics

Overview

Recent advancements in cloud computing have prompted developers to decouple the application system design architecture for better performance. Elastic Load Balancing is one of the components of EC2 services that help to achieve this decoupling design architecture. Elastic load balancing is typically used to distribute loads across multiple targets, i.e., EC2 instances. One type of elastic load balancer provided by the AWS EC2 service is the AWS application load balancer. This application load balancer contributes to the decoupling of the system architecture. AWS will manage the availability and scalability aspects of the application load balancer, allowing developers to focus on application development.

Scope

In this article,

• We will discuss the AWS application load balancer and how it works.

• We will also look into the components of the AWS application load balancer.

• We will demonstrate the workings of an application load balancer.

• Finally, we will discuss the features, pricing, and use cases for the AWS application load balancer.

What is an Application Load Balancer?

Before we can discuss an application load balancer, we must first understand a load balancer.

The load balancer is a piece of software or hardware that distributes incoming requests to the backend servers. There are three types of Elastic Load balancers currently offered by the AWS EC2 service. They are

1. Application Load Balancer
2. Network Load Balancer
3. Gateway Load Balancer

One of the distinguishing differences between the application load balancer and the network load balancer is that the application load balancer works at Layer 7 while the network load balancer works at Layer 4 in the OSI 7 Layers.

• The application load balancer AWS is used to distribute traffic across the target. The term “target” in this context refers to EC2 servers or Lambda.
   

• Customers/clients will send requests to the application load balancer, which will then distribute/send the requests to the backend targets (EC2 or lambda). The application load balancer is scalable natively. As a result, we don’t need to be concerned about scaling the application load balancer.

• However, if our total requests increase by more than 50% within 5 minutes, we should contact AWS support to pre-warm our application load balancer AWS.

AWS Application Load Balancer vs Network Load Balancer vs Gateway Load Balancer

Application Load Balancer

• An application load balancer works at layer 7, i.e., the application layer in the OSI architecture. The application load balancer routes request to the targets, such as EC2 instances, Lambdas, etc.
• For Elastic Container Service, the application load balancer AWS supports dynamic port mapping for containers.

Network Load Balancer

• A network load balancer works at layer 4, i.e., the network layer in the OSI architecture. Like the application load balancer, the AWS network load balancer routes requests to targets such as EC2 instances, Fargate Task, EC2 containers, Lambda, and so on.
• For Elastic Container Service, the Network load balancer also supports dynamic port mapping for containers.

Gateway Load Balancer

• Gateway load balancer supports third-party virtual appliance offerings from the AWS Marketplace. This load balancer helps to reduce the positioning of several appliances for monitoring the network traffic within our VPC.

How Does the AWS Application Load Balancer Work?

As you can see in the below diagram, the customer/application/clients send a request to the application load balancer.

• Once the application load balancer AWS receives the request, it will route the traffic to the backend targets such as EC2 based on either path-based routing or rule-based routing.
• If that target is configured with the necessary response code for the request, it will return the response; otherwise, the target will send the 4xx error code to the application load balancer.
• The response is forwarded to customers and clients by the AWS application load balancer.

Application load balancers AWS also act as the front-end components of our application architecture.

Application Load Balancer Components

There are three integral components associated with the application load balancer. They are

1. The Listener’s Rules
2. The Listening Ports
3. Target Group

Rules

The rules that we define for our listeners determine how the Amazon Web Services application load balancer routes request to targets such as EC2 instances, IP addresses, or Lambdas in one or more target groups. Each rule has three parameters: priority, actions, and conditions.

Condition

There are six major types of conditions we can create for rules. They are

NoConditionDescription1Path BasedThe rules will route the request to the path such as /login 2Host Basedif the request came from a subdomain URL, then we can route the request to our desired target group3HTTP-HeaderRoute based on the HTTP headers for each request received for application load balancer4HTTP-request-methodRoute based on the HTTP request method of each request5A query stringRoute the request based on key/value pairs or values in the query string to the target group6Source IPRoute the request based on the source IP address of each request

Action

There are three types of actions available in the application load balancer AWS. Among the three actions, we can choose any one of the below-mentioned actions for the chosen condition.

ActionDescriptionForward toThe AWS application load balancer will forward the received request to the backend targets in the target groupRedirect toIf the request is received, the AWS application load balancer will redirect the request to the specified URL with portFixed Return responseIf the request is received, the AWS application load balancer will return the fixed HTTP code response

Listening Ports

The ports 80 (HTTP) and 443 (HTTPS ) can be used for listeners in the AWS application load balancer.
If we choose HTTPS (443)as our listener, we should map an SSL certificate to the application load balancer.

By default, we can add a maximum of 50 listeners to our AWS application load balancer. For more than 50 listener rules, we should request the AWS Support team to increase the default quota.

Target Group

We can’t create an application load balancer without a target group. While creating the application load balancer itself, we should select at least one target group. The target group contains the target. Here, the target refers to three resources. They are EC2 instances, IP addresses, and Lambda functions. 
We can add a minimum of one and a maximum of 1000 targets (EC2 instances) per target group.

WAF integration with Application Load Balancer

What is WAF?

WAF is abbreviated as “Web Application Firewall.”

In WAF,

1. We can create a rule and a rule group that should be followed by every request payload that passes through. 
2. We can also use pre-configured rules or create our own custom rules 
3. Using the IP sets option, we can allow or deny the partial network CIDR or geographic location.

In the application load balancer, we have the option to put the WAF in front of the application load balancer. By doing so, what will happen?

Every request and traffic should pass through the WAF first, then only reach the application load balancer.

Thus, WAF helps the application load balancer mitigate any web exploitation such as SQL injection, bot control, etc.

Application Load Balancing Monitoring and Logging

Monitoring

The AWS application load balancer is integrated with a cloud watch service where we can monitor a lot of things. The below-mentioned 6 metrics will be majorly used to monitor the application.
The most commonly used metrics are

• Application load balancer 5xx response count
• Target 4xx response count
• Target 2xx response count
• Target response time
• Total request
• Active connection count

Logging

• We can create application load balancer access logs after creating the load balancer.
• The access logs will be stored in a new s3 bucket or existing S3 bucket of our choice.

Features

The Cross AZ Load Balancer

While creating an application load balancer, we have to choose the subnet to provision.

If we choose subnets with one availability zone, the application load balancer routes traffic to the targets residing in the single availability zone.

If we choose two availability zones and one subnet from each availability zone, we can have a multi-availability zone target in the target group. The application load balancer will route traffic to the targets residing in the multi-availability zone.

High Availability and Throughput

Application load balancers are highly available and distribute the traffic towards the targets in a single availability zone or multi-availability zone.

It will automatically scale and handle millions of requests per second.

Security

Using a security group, we can control our application load balancer.

If the load balancer is internally facing, we can allow the desired VPC CIDR in the security group inbound rule to communicate internally between the EC2 instances.

If the application load balancer is internet-facing, we can establish the connection between the application load balancer and the world by allowing the inbound rule for all traffic at port 80 or 443, or both.

In addition to the security group, we can integrate WAF in front of the application load balancer for an extra security layer.

Health Checks

The application load balancer will route traffic to healthy targets by default. If any EC2 instance is unhealthy, the application load balancer stops sending traffic to that target until it becomes healthy.

Possible causes for the Target’s becoming Unhealthy

• Wrongly configured application port
• The EC2 instance/system status check failed.
• Security Group rule establishment between the application load balancer and EC2 instances
• High Memory and CPU Utilization

Sticky Session

Assume we have multiple targets (EC2 instances ) behind the application load balancer when the clients send a request to the application load balancer and receive a response from it.

If we enable a sticky session, the client will receive a response from the same target from which they got a response earlier 

Delete Protection

We can enable this option in the application load balancer to avoid any accidental deletion.

If this option is enabled and we want to delete the application load balancer, we must first disable the delete protection option before deleting the application load balancer.

The AWS Global Accelerator

Using AWS Global Accelerator, we can get a static IP address for our application load balancer. It will act as a fixed entry point for our applications.

The AWS Global Accelerator leverages the Global AWS Network to enhance performance across the network.

Additional charges will apply for using the AWS Global Accelerator.

EC2 Autoscaling

For EC2 autoscaling capabilities, the aws application load balancer will route the traffic to the newly launched instance. Thus, the customer’s request will always be routed to healthy targets (EC2 instance).

AWS Certification Manager 

We can add the SSL Certificate provided by ACM to our application load balancer for HTTPS listeners (Port 443).

Amazon Elastic Container Service

We can configure the Amazon ECS service to use an application load balancer to distribute incoming traffic across the services in a cluster of an EC2 instance or Fargate task.

Note: The AWS application load balancer can also be integrated with Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, and Amazon API Gateway, Route 53.

Algorithm

We can choose either a round-robin or the least outstanding request algorithm in the target group.

The algorithm will determine how the application load balancer selects targets from this target group when routing requests.

Why an Application Load Balancer Instead of a Classic Load Balancer?

The classic load balancer is the first generation of elastic load balancing in AWS. An application load balancer provides a lot of capabilities when compared to the classic load balancer.

FeatureApplication Load BalancerClassic Load BalancerLoad Balancer TypeLayer 7Layer 4/7Target TypeIP, Instance, LambdaInstanceTerminates flow/proxy behaviorYesYesProtocol listenersHTTP, HTTPS, gRPCTCP, SSL/TLS, HTTP, HTTPSReachable viaVIP-RedirectsYes-Fixed ResponseYes-Desync Mitigation ModeYes-HTTP header-based routingYes-HTTP2/gRPCYes-Slow startYes-Outpost supportYes-Local ZoneYes-Connection draining (deregistration delay)YesYesConfigurable idle connection timeoutYesYesUser AuthenticationYes-

Application Load Balancer Pricing

Two components determine the pricing of the application load balancer. They are

1. Application load balancer running each hour or partial hour.
2. Load balancing unit per hour

Application Load Balancer Running Each Hour or Partial Hour

Every hour the application load balancer is running, it will incur charges.
In the Asia-Pacific Mumbai region, the price for using an application load balancer per hour is $0.0239.

Load Balancer Capacity Unit

For the Asia-pacific Mumbai region, the load balancer capacity unit charges $0.01 per LCU-hour (or partial hour). Each load balancer capacity unit, or LCU, comprises four dimensions. They are

NoComponentsDescription1New connectionThe number of newly established connections per second2Active connectionsNumber of active connections per minute(After the client and server connections are connected)3Processed bytesThe number of bytes processed by the application load balancer in GBs for HTTP(S) requests and responses4Rule evaluationsThe first 10 rules are free of charge. After that, the price will be calculated based on the formula Request rate * (Number of rules evaluation-10 )

Quotas for Application Load Balancer

Application Load Balancer

The quotas for application load balancers per region are mentioned below.

NameDefaultAdjustableApplication Load Balancers per Region50YesSSL Certificates per ALB (excluding default certificates)25YesListeners per ALB50YesTarget Registration count per Application Load Balancer1000YesTarget Groups per Action per Application Load Balancer5NoTarget Groups per ALB100NoTarget per ALB1000No

Target Groups

The Target group quotas are mentioned below

NameDefaultAdjustableTarget Groups per Region3000YesInstances or IPs per Target Group per region1000YesLambda function per Target Group1No

Rules

The rules quotas are mentioned below

NameDefaultAdjustableRules per Application Load Balancer (excluding default rules)100Yes

Conclusion

• An application load balancer works at layer 7, which makes it suitable for web and mobile applications.
• The application load balancer aws can be integrated with the Elastic Container Service and Elastic Kubernetes Service as the front end so that it will distribute traffic among tasks and pods.
• It supports path-based routing and host-based routing to the backend targets (Instance)
• It can also be integrated with the Autoscaling group for balancing and distributing unexpected loads across the server.
• We can integrate additional services such as CDN and WAF into our application load balancers.