Application Load Balancer

Learn how an application load balancer routes traffic between clients and applications.

Elastic Load Balancers serve as a single point of interaction and are used to distribute incoming traffic across different targets, such as EC2 instances and IP addresses of our servers. An Application Load Balancer operates on the application layer (the seventh layer of the OSI model) and handles HTTP/HTTPS/Web Socket requests.

Press + to interact

Target groups in ALB

Target groups are used to define where an Application Load Balancer routes the incoming requests from a client. While creating a target group, we define the type of targets, the protocols, and the ports. ALBs support EC2 instances, IP addresses, and Lambda functions as its target types, HTTP and HTTPS as its protocols, and ports 1-65535. When we create an ALB, we provide listener rules, where we define the conditions that must be met in order for the ALB to send client requests to a specific target group. Once a target group is created, AWS performs various health checks on the targets registered in a target group to ensure they are available to receive and process requests from a client.

Press + to interact
Target groups in ALB
Target groups in ALB

Routing algorithms in ALB

Application Load Balancers support various routing algorithms to distribute incoming requests across multiple target groups. We can select only one routing algorithm for a routing group at a time, however, we do have the option of updating these algorithms according to our applications’ requirements. Let’s look at the algorithms supported by ALBs:

  • Round robin: This is the default algorithm used by ALBs and distributes incoming requests evenly across multiple targets in a sequential order.

  • Least outstanding requests: Here, incoming requests are sent to the target with the least number of requests whose status is in progress.

  • Weighted random: In this algorithm, weights are assigned randomly to requests that evenly distribute requests across targets in a random order.

Listeners in ALB

Application Load Balancers use listeners, that check connection requests received from the client. We define rules in listeners that determine how our load balancer routes the requests it receives. A single listener can have multiple rules and are evaluated according to the priority we set up. Following are the conditions we can define in rules for our listeners:

  • HTTP header conditions: These rules are created to handle client requests based on their HTTP headers.

  • HTTP request method conditions: These rules are created to handle client requests based on their HTTP request methods.

  • Host conditions: Rules can be created to route requests based on the name of the host.

  • Path conditions: Path conditions in the URL of the request can be used to create rules to route requests to different targets.

  • Query string conditions: Key/value pairs in the query string of the incoming request can be used to create rules to route requests.

  • Source IP address conditions: Rules can be created that route incoming requests based on the source IP address. This IP address must be specified in the CIDR format.

In the following diagram, we can see how different request types are sent to different target groups by an ALB.

Press + to interact
Sending different request types to different target groups
Sending different request types to different target groups

Things to keep in mind

Following are some of the things we must keep in mind while using Application Load Balancers:

  • IP address: ALBs support IPv4 addresses and dual-stack (using both IPv4 and IPv6 addresses) to receive connection requests from the client.

  • Availability zone: We must specify at least two Availability Zones while creating an ALB and should launch at least one target in both zones.

  • Security groups: The security groups associated with our ALB must allow traffic flow in both directions on the listener and the health check port. Also, the security groups associated with our target groups must have inbound rules with the ALB’s security group as the source to allow the ASG to access our targets.

  • WebSockets: ALB supports WebSockets. This means we can create a bidirectional communication channel between a client and a server over a TCP connection to exchange messages in real time.

  • Sticky sessions: We can create sticky sessions in ALB. Through this mechanism, we can ensure that any further requests from a client are sent to the same target.

  • Health checks: ALB performs regular health checks on the registered targets in a target group to ensure they are fit to receive requests from a client.

Create a free account to view this lesson.

Continue your learning journey with a 14-day free trial.

By signing up, you agree to Educative's Terms of Service and Privacy Policy