AWS load balancer

Application Load Balancer (ALB) on AWS

An Application Load Balancer (ALB) is a fully managed Layer 7 load balancer service provided by AWS (Amazon Web Services). It operates at the application layer of the OSI model (Layer 7), which allows it to intelligently route HTTP/HTTPS traffic based on more advanced rules, such as URL paths, hostnames, headers, and more. ALBs are widely used to distribute web traffic among multiple targets, such as EC2 instances, containers, and Lambda functions, to ensure high availability, scalability, and fault tolerance for web applications.

Components -

Listeners:

Listeners define the protocol/port combination that the ALB will listen on for incoming requests.

A listener checks for connection requests from clients using the protocol and port that you configure, and forward requests to one or more target groups, based on the rules that you define.

Each ALB requires at least one listeners to accept traffic.

Currently, 50 Listeners can be configured on the ALB.

Supported Protocols: HTTP/HTTPS
- Ports 1–65535
Target Groups:
- Are regional constructs.
- A Target Group is a logical grouping of Targets.
- Note that each target group can be associated with only one load balancer.
- Each target group can be associated with only one load balancer.
- Groups can scale each target group individually.
- The target group is used to route requests to registered targets as part of an action for a rule.
- The target group specifies a protocol and target port.
- Health checks can be configured per target groups.
- An ALB can route to multiple target groups.
- You define one Protocol and one port per target group which will be used to route/forward traffic to the registered targets.
- They can exist independently from the ALB.
Targets:

Targets specify the endpoints and are registered with the ALB as part of a target group.

Targets can be EC2 instance, a Microservice, and the Application on an ECS container, or IP addresses.
- You can’t specify public internet routable IP addresses as targets.

An EC2 instance can be registered with the same target group multiple times using multiple ports.

Up to 1000 target can be contained within a target group.

You can register a target with multiple target groups.

You can add and remove targets from your load balancer as your needs change, without distributing the overall flow of requests to your application.

AWS ALB- Targets-Type: IP address

You can use IP addresses as targets to register:

Instances in a peered VPC,
AWS resources that are addressable by IP address and port (for example, databases),

You can register each EC2 instance or IP address with the same target group multiple times using different ports, which enables the load balancer to route requests to microservices.

If you specify targets using an instance ID, traffic is routed to instances using the primary private IP address specified in the primary network interface for the instance.

If you specify targets using IP addresses, you can route traffic to an instance using any private IP address from one or more network interfaces.

This enables multiple applications on an instance to use the same port.

Target Group and Targets

You CAN NOT mix targets of different types in one target group, i.e you can not mix EC2 with ECS and/or IP targets in one target group
- You need to keep the endpoint type homogenous in each group

IP targets are targets within the VPC or on-premise accessible through a VPN and DX

They CAN NOT be public, internet-routable, IP addresses

You can configure health checks on a per target group basis.

Health checks are performed on all targets registered to a target group that is specified in a listener rule for your load balancer.

By default, the load balancer sends request to registered targets using the port and protocol that you specified for the target group.

You can delete a target group if it is not referenced by any actions.

Deleting a target group does not affect the targets registered with the target group. If you no longer need a registered EC2 instance, You can stop or terminate it.

Rules (or Routing Rules)

Rules provide a link between listeners and target groups and consist of conditions and actions.
- Up to 100 rules can be configured per ALB
- Rules determine what action is taken when a rule matches a client request.
- Rules are defined on listeners
- Each rule specifies a condition, target group, action, and a priority. (When the condition is met, the traffic is forwarded to the target group.
- Each rule represents a condition and action that we want to follow.
- You must define a default rule of each listener, and you add rules that specify different target groups based on the content of the request (also known as content-based routing)
- If no rules are found, the request will follow the default rule, which forwards the request to the default target group.
Listener Rules
- Rule Priority

Each rule has a priority.

Rules are evaluated in priority order, from the lowest value to the highest value.

The default rule is evaluated last.

You can change the priority of a non-default rule at any time.

You cannot change the priority of the default rule.

Rule Actions

When you create a listener, you define an action for the default rule.

Default rules can’t have conditions.

You can delete the no- default rules for listeners at any time. You cannot delete the default rule for a listener. When you delete a listener, all its rules are deleted.

If no conditions for any of a listeners rules are met, then the action for the default rule is taken.

Rule Conditions

There are two types of rule conditions: host and path.

When the conditions for a rule are met, then its action is taken.

Each rule can have up to 2 conditions. 1 Path Condition and 1 Host Condition.

Optional Condition is the path pattern you want the ALB to evaluate in order for it to route requests.

Key Features of an Application Load Balancer:

Layer 7 Load Balancing:
- ALB operates at the HTTP/HTTPS layer (Layer 7), which allows it to route traffic based on content such as URL paths, host headers, and query strings.
- This makes it ideal for applications that need to route traffic to different microservices or containers based on URL patterns (e.g., example.com/api or example.com/admin).
Advanced Request Routing:
- ALB supports content-based routing. You can create rules that forward traffic based on conditions such as:
  - Path-based routing (e.g., /api to one service and /static to another).
  - Host-based routing (e.g., api.example.com vs. www.example.com).
  - HTTP header-based routing (e.g., User-Agent, Accept headers).
- This is especially useful for microservices or containerized applications hosted in Amazon ECS or EKS.
Support for HTTP/2 and WebSockets:
- ALB supports HTTP/2, which improves performance by allowing multiple requests and responses to be multiplexed over a single connection.
- It also supports WebSockets, which is useful for real-time applications like chat apps or live updates.
SSL/TLS Termination:
- ALB supports SSL/TLS termination, meaning it can handle HTTPS traffic by decrypting the requests before forwarding them to backend targets. This offloads the encryption/decryption workload from your application servers.
- You can upload SSL/TLS certificates directly to the ALB using AWS Certificate Manager (ACM) or use self-signed certificates.
Auto Scaling Integration:
- ALB integrates with Amazon EC2 Auto Scaling, allowing backend instances or containers to scale automatically based on demand.
- When demand increases, Auto Scaling launches more instances and registers them with the ALB, and vice versa when traffic decreases.
Health Checks:
- ALB performs regular health checks on the registered targets (EC2 instances, containers, etc.). If a target fails the health check, ALB will stop sending traffic to that target until it becomes healthy again.
- This ensures that only healthy instances receive traffic, increasing the reliability and fault tolerance of your application.
Sticky Sessions (Session Affinity):
- ALB supports sticky sessions, where it can bind a user’s session to a specific backend target for the duration of that session. This is useful for applications that require stateful sessions (e.g., shopping carts in e-commerce sites).
- Sticky sessions are maintained using cookies.
Access Logs:
- ALB can generate access logs, which record detailed information about requests handled by the load balancer (e.g., client IP, request URL, response time).
- These logs can be stored in an S3 bucket and are useful for debugging, monitoring, and security analysis.
Security Features:
- ALB integrates with AWS WAF (Web Application Firewall) to provide protection against common web attacks such as SQL injection and cross-site scripting (XSS).
- ALB also integrates with AWS Shield for DDoS protection.
Global Availability with Regional Deployment:
- ALB is deployed within specific AWS regions and supports cross-region load balancing when combined with Route 53 and Global Accelerator. However, ALBs themselves are regional, meaning they distribute traffic to instances within a specific region.

Use Cases for Application Load Balancer:

Microservices:
- ALBs are ideal for distributing traffic to multiple microservices. Each microservice can be hosted in separate containers or EC2 instances, and ALB can route requests based on URL paths or hostnames to the correct microservice.
Web Applications:
- ALB can handle traffic for large-scale web applications, distributing traffic across multiple EC2 instances or containers in an auto-scaling group, ensuring high availability and reliability.
Real-Time Applications:
- For applications like chat apps, gaming platforms, or IoT systems, ALB’s support for WebSockets allows you to maintain persistent connections and handle real-time communication.
HTTPS Termination:
- ALBs are commonly used to handle SSL/TLS encryption and decryption for secure web traffic. This offloads the CPU-intensive work of SSL termination from backend servers.
Hybrid Cloud Architectures:
- ALBs can help distribute traffic between on-premises and cloud resources, facilitating hybrid cloud architectures where some resources are hosted on AWS and others are located in a private data center.

How to Create and Configure an ALB on AWS:

Step 1: Set Up Your VPC:
- Ensure you have a Virtual Private Cloud (VPC) set up with at least two subnets (preferably in different Availability Zones) for high availability.
Step 2: Create a Target Group:
- A target group defines where the traffic will be routed. You can register EC2 instances, containers, or Lambda functions as targets.
- Set up health checks for the target group to ensure that traffic is only routed to healthy instances.
Step 3: Create an Application Load Balancer:
- In the AWS Management Console, navigate to the EC2 Dashboard and select Load Balancers.
- Choose Create Load Balancer and select Application Load Balancer.
- Configure the following:
  - Listeners: Specify HTTP/HTTPS ports (usually port 80 for HTTP and 443 for HTTPS).
  - Subnets: Choose the VPC and subnets where the ALB will be deployed.
  - Security Groups: Attach security groups to the ALB for traffic control.
Step 4: Configure Listeners and Rules:
- Listeners: Define the ports and protocols for incoming traffic (e.g., HTTP on port 80 or HTTPS on port 443).
- Rules: Set up rules to route traffic to different target groups based on conditions such as request path, hostname, etc.
Step 5: Attach Target Groups:
- After setting up your target groups (with EC2 instances or containers), attach them to your ALB. You can register targets manually or enable auto-scaling.
Step 6: SSL/TLS Configuration (Optional):
- If using HTTPS, you’ll need to configure an SSL/TLS certificate. You can request or import a certificate using AWS Certificate Manager (ACM).
Step 7: Test and Monitor:
- After configuring the ALB, test the routing and traffic distribution.
- Use CloudWatch metrics and access logs to monitor the performance and health of your ALB.

Security Considerations:

SSL/TLS Termination: Use AWS Certificate Manager (ACM) to provision and manage your SSL/TLS certificates for secure communication.
Security Groups: Ensure that your ALB and backend targets are protected by appropriate security groups that only allow traffic from trusted sources.
WAF Integration: You can integrate AWS WAF to block malicious traffic based on rules you define.

Monitoring and Logging:

CloudWatch Metrics: Monitor key metrics such as request count, response time, and health check status for both the ALB and target instances.
Access Logs: Enable access logging to capture detailed information about each request, such as client IP, request URL, and response time.

Pricing:

ALB pricing is based on:
- The number of LCU (Load Balancer Capacity Units) used, which depends on the number of new connections, active connections, and the amount of data processed by the ALB.
- Hourly fees for the ALB itself.
- Data transfer costs for traffic handled by the ALB.

Conclusion:

An Application Load Balancer (ALB) on AWS is a powerful and flexible tool for distributing HTTP/HTTPS traffic, enabling sophisticated routing for applications, especially in microservices and containerized environments. By leveraging features such as content-based routing, WebSocket support, SSL/TLS termination, and automatic scaling, ALB helps ensure the scalability, availability, and fault tolerance of your applications.