Friday, May 16, 2025

Application Load Balancer (ALB) – Version 2 (Introduced in 2016)

AWS Load Balancers, Types and Use Cases

Load balancers distribute incoming network traffic across multiple servers or resources to ensure reliability, high availability, and optimal performance. Here's an overview of the types of load balancers and their use cases:

Types of Load Balancers

Layer 4 Load Balancer (Transport Layer)

Operates at the TCP/UDP level.
Makes routing decisions based on IP address, port numbers.
Examples: AWS Network Load Balancer, HAProxy (TCP mode), NGINX (stream module).
Use Case:

High-performance, low-latency traffic.
Game servers, VoIP, or any app requiring direct connection handling.

Layer 7 Load Balancer (Application Layer)

Operates at the HTTP/HTTPS level.
Makes routing decisions based on URLs, cookies, headers, etc.
Examples: AWS Application Load Balancer, NGINX-ingress, Apache HTTPD, Traefik.
Use Case:

Web applications needing routing based on domain/path.
API gateway routing, content-based routing, A/B testing.

Global Load Balancer / DNS-Based Load Balancer

Routes traffic based on geolocation or latency using DNS or Anycast.
Examples: AWS Route 53, Google Cloud Load Balancer, Azure Front Door.
Use Case:

Disaster recovery, multi-region traffic routing, global app deployments.

Hardware Load Balancer

Physical devices from vendors like F5, Cisco, or Citrix.
Often support both Layer 4 and Layer 7.
Use Case:

Enterprises requiring advanced security and protocol handling on-prem.

Software Load Balancer

Installed on general-purpose servers (e.g., HAProxy, Envoy, NGINX).
Use Case:

Cost-effective, customizable solutions for internal traffic or edge proxying.

Key Features

Feature	Description
Layer 4 & 7 Routing	Routes based on HTTP, ( NLB) and host headers, paths (e.g. /api/*), query strings, HTTPs methods, etc.
Support for HTTP/2 and WebSockets	Native support for persistent, multiplexed connections and real-time apps.
Target Groups	Routes traffic to EC2, ECS (Fargate or EC2), Lambda, or IP-based targets.
Advanced Health Checks	HTTP-based health monitoring of targets with configurable thresholds.
Listener Rules	Enables sophisticated traffic control with priority-based evaluation.
Container-Aware (ECS integration)	Supports dynamic port mapping for microservices.
WAF Integration	Easily integrates with AWS Web Application Firewall for enhanced security.
Authentication	Built-in OIDC/OAuth2 authentication (e.g., Cognito, Okta, Auth0).
Redirects & Fixed Responses	Supports 301/302 redirects and custom error responses.

Target Types

EC2 Instances
ECS Tasks
Lambda Functions
IP addresses (on-prem or other VPCs)

Security and Monitoring

Integrated with AWS Certificate Manager (ACM) for SSL/TLS
Logging via Access Logs to S3
Metrics via CloudWatch
Integrated with AWS WAF, Shield, and IAM for security and access control.

twtech-Use Case

Scenario	Load Balancer Type	Reason
Hosting a website with multiple backend servers	Layer 7 (e.g., ALB, NGINX-ingress)	Path-based routing, SSL termination
Real-time chat or gaming app	Layer 4 (e.g., NLB, HAProxy)	Low latency, TCP/UDP support
Serving users from different continents	Global/DNS-based (e.g., Route 53, Cloudflare)	Latency-based routing
Zero-downtime deployments	Any + health checks	Traffic can shift away from unhealthy servers
Kubernetes ingress traffic	L7 (Ingress Controller) or L4 (Service type=LoadBalancer)	Routing to services/pods

More Use Cases

Use Case	Why ALB?

Deploying microservices with ECS or EKS	ALB integrates directly with container platforms.
Blue/Green Deployments	Separate target groups for staging and production with rules to control traffic flow.
API Gateways or RESTful APIs	ALB supports routing logic and request filtering.
Real-time applications	HTTP/2 and WebSocket support.

Application Load Balancer (ALB) – Version 2 (Introduced in 2016)

The Application Load Balancer (ALB) is part of AWS's second-generation Elastic Load Balancing (ELBv2) family. It is designed specifically for content-based routing at the Application Layer (Layer 7) and is ideal for modern web architectures, including containerized and microservices-based applications.

It is designed to handle HTTP and HTTPS traffic with advanced routing capabilities, especially for microservices and container-based applications (e.g., those running on ECS or EKS).

Application Load Balancer (v2):

key features of Application Load Balancers: (ALB)

Layer 7 Load Balancing (HTTP/HTTPS)

Operates at the application layer of the OSI model.
Supports content-based routing based on URL path, hostname, HTTP headers, method, and query string.

Target Groups

Targets can be EC2 instances, IP addresses, Lambda functions, or ECS containers.
Health checks are defined at the target group level.

Host-based and Path-based Routing

Route requests to different target groups based on the domain name or URL path.

Native Support for Containers

Supports dynamic port mapping, making it ideal for Docker/ECS/EKS environments.

WebSocket Support

ALB supports WebSocket and HTTP/2.

SSL Termination & SNI Support

Supports TLS/SSL offloading, allowing ALB to manage encryption.
SNI (Server Name Indication) support enables hosting multiple secure (HTTPS) applications on a single load balancer.

Authentication

ALB supports integration with Amazon Cognito or OIDC-compliant IdPs for user authentication.

Access Logs

Stores logs in S3 for auditing and monitoring.

WAF Integration

Can be integrated with AWS Web Application Firewall (WAF) for security.

Sticky Sessions

Session stickiness (based on cookies) can be enabled per target group.

Pricing

Based on number of hours the ALB runs and number of new connections/processed bytes.

Using a load balancer is critical in modern infrastructure for several reasons.(Benefits):

1. High Availability

Load balancers monitor server health and automatically route traffic to healthy instances only. If one server fails, traffic is rerouted to others — ensuring minimal downtime.

2. Scalability

As traffic grows, you can add more backend servers. A load balancer distributes traffic evenly, helping the system scale horizontally without changing the application logic.

3. Performance Optimization

By balancing the load, servers avoid overload. Advanced load balancers can also use caching, compression, or SSL offloading to improve speed and reduce server workload.

4. Fault Tolerance & Redundancy

Load balancers enhance fault tolerance by masking server failures. They can also perform automatic failover to standby systems.

5. Security

Many load balancers support:

SSL/TLS termination
Web application firewall (WAF) integration
DDoS protection
Application-layer filtering (especially Layer 7)

6. Simplified Maintenance and Zero-Downtime Deployments

You can take backend servers out of rotation to update or maintain them without affecting users — allowing rolling updates and blue/green deployments.

7. Multi-Region or Multi-Cloud Routing

Global load balancers can route traffic based on user geography, latency, or availability — ideal for multi-region deployments or hybrid cloud setups.

twtech-Real-World Example:

Imagine a high-traffic e-commerce site like Amazon:

Without a load balancer: One server handles all requests... leading to overload, slow response, or crash.
With a load balancer: Traffic is distributed across multiple web servers.
If one fails, others pick up the load, ensuring seamless user experience.

In AWS Application Load Balancer (ALB), a Target Group is a logical grouping of resources (called targets) that the ALB routes traffic to. Each listener rule on the ALB sends requests to a specific target group, and ALB can have multiple target groups.

Target Groups

Concept	Description
Targets	Can be EC2 instances, ECS tasks, Lambda functions, or IP addresses (within VPC).
Target Type	instance, ip, or lambda. Determines how the target is specified.
Health Checks	Defined at the target group level to determine target health (protocol, path, interval, etc.).
Port	ALB sends traffic to targets on this port (can vary if dynamic port mapping is used).
Protocol	HTTP, HTTPS (for ALB).
Stickiness	Optional: Enables sticky sessions using application-based cookies.
Load Balancing	Requests are distributed across healthy targets within the group.

Common Use Cases

Microservices: Each microservice (e.g., /api, /auth) can map to a different target group.
Blue/Green Deployments: Use two target groups and shift traffic between them during deployments.
Containerized Environments: ECS with dynamic ports uses target groups with IP-based registration.

twtech Target Group Creation (AWS CLI)

# bash

aws elbv2 create-target-group \

--name twtech-target-group \

--protocol HTTP \

--port 80 \

--vpc-id vpc-12345678 \

--target-type instance

twtech Health Check Configuration

When creating or modifying a target group:

Protocol: HTTP or HTTPS
Path: /health
Interval: Time between checks
Thresholds: Healthy/unhealthy check counts
Timeout: For each health check

# bash

aws elbv2 modify-target-group \

--target-group-arn <target-group-arn> \

--health-check-protocol HTTP \

--health-check-path /health \

--health-check-interval-seconds 30

Project: Hands-on

Application Load Balancer(ALB) /Target-groups (TG)

How twtech creates the application load balancer for applications.

Step one,

Launch amazon Linux-2023 instances or use existing instances. : lunch them without the keypair (only the private IP is needed)

Bootstrap user-data: httpd

#!/bin/bash

yum update -y

yum install -y httpd

systemctl start httpd

systemctl enable httpd

echo " <h1> twtech hello-app from $(hostname -f)</h1>" > /var/www/html/index.html

NB: Make sure the instances are up and running: Ready

Step 2:

Use the PrivateIP address toverified that the httpd service was was installed and enabled:

Verify that Both instances have httpd service successfully bootstrap

Yes:

Step 3:

Create a load balancer from: ec2 console: ALB

Key differences between: ALB, NLB and GWLB

Here's a clear comparison of ALB (Application Load Balancer), NLB (Network Load Balancer), and GWLB (Gateway Load Balancer) — the three types of Elastic Load Balancers in AWS:

twtech Comparison Table

Feature / Property	ALB (Application LB)	NLB (Network LB)	GWLB (Gateway LB)
OSI Layer	Layer 7 (Application)	Layer 4 (Transport)	Layer 3 (Network)
Protocols Supported	HTTP, HTTPS, WebSocket	TCP, TLS, UDP, TCP_UDP	All IP traffic (encapsulated in GENEVE)
Routing Type	Content-based (URL/host/path)	IP and Port-based	Traffic mirroring and forwarding
Target Types	Instance, IP, Lambda	Instance, IP, ALB	Appliance (VMs running firewalls, IDS)
Use Case	Web apps, microservices	High-performance apps, gaming	Security appliances, traffic inspection, & security.
Sticky Sessions	Yes (App cookie)	Yes (Source IP)	No
TLS Termination	Yes	Yes	No
Health Checks	HTTP/HTTPS	TCP/HTTP/HTTPS	None (relies on appliance)
WAF Integration	Yes	No	No
IP Preservation	No (source IP hidden)	Yes (source IP preserved)	Yes
Pricing Unit	LCU + request/GB	NCU + connection/GB	Hourly + GB processed

twtech recommendation of When-to-Use-what-type of load balancer

ALB (Application Load Balancer):

Ideal for web apps, APIs, microservices.
Needed when routing by URL paths or domains.
Great for containerized apps (ECS, EKS).

NLB (Network Load Balancer):

High-performance needs, low-latency, millions of requests/sec.
Ideal for TCP/UDP traffic like gaming, VoIP, or database access.
Needed when you want to preserve the client IP.

GWLB (Gateway Load Balancer):

Used for transparent network traffic inspection.
Ideal for security appliances like firewalls, intrusion detection/prevention systems (IDS/IPS).
Routes and scales traffic to virtual appliances while maintaining original packet flow.

Application Load Balancers now support public IPv4 IP Address Management (IPAM)

You can get started with this feature by configuring IP pools in the Network mapping section.

How twtech Creates the Application Load Balancer

Concept:

The Application Load Balancer distributes incoming HTTP and HTTPS traffic across multiple targets such as Amazon EC2 instances, microservices, and containers, based on request attributes. When the load balancer receives a connection request, it evaluates the listener rules in priority order to determine which rule to apply, and if applicable, it selects a target from the target group for the rule action.

Select the vpc:

twtech may choose to enable or not the IPAM(IP address manager) to manage all twtech IP addresses in all twtech environments

Select the Availability Zones and subnets

Select at least two Availability Zones and a subnet for each zone. A load balancer node will be placed in each selected zone and will automatically scale in response to traffic. The load balancer routes traffic to targets in the selected Availability Zones only.

Assign a Security groups to the ALB

A security group is a set of firewall rules that control the traffic to your load balancer. Select an existing security group, or you can create a new security group

Create a new security group to only allow: http traffic

Add Inbound rule that: allows all http traffic from anywhere

This security group has no inbound rules.

Tags - optional

A tag is a label that you assign to an AWS resource. Each tag consists of a key and an optional value. You can use tags to search and filter your resources or track your AWS costs.

Create the security group for ALB:

Go back to ALB console, refresh Security group and select the twtech-ALB-SG created:

Make sure the default SG is removed:

Listeners and routing: assign a target group (group of ec2-instances) to the http:80 listener.

A listener is a process that checks for connection requests using the port and protocol you configure. The rules that you define for a listener determine how the load balancer routes requests to its registered targets.

Create a target group(group of ec2-instances)

Assign a Target group name:

Assign a Protocol : Port

Choose a protocol for your target group that corresponds to the Load Balancer type that will route traffic to it. Some protocols now include anomaly detection for the targets and you can set mitigation options once your target group is created. This choice cannot be changed after creation

VPC

Select the VPC with the instances that you want to include in the target group. Only VPCs that support the IP address type selected above are available in this list.

Protocol version: HTTP1

Health checks

The associated load balancer periodically sends requests, per the settings below, to the registered targets to test their status.

From:
Register instances to target: select instances and include them as pending below

To:

Create target group: twtech-alb-tg

Go back to ALB console, (listener and routing) refresh and select target group created: twtech-alb-tg

Review and create the ALB:
Review the load balancer configurations and make changes if needed. After you finish reviewing the configurations, choose Create load balancer.

Need some little time to fully provision:

From:

To: Active status

With the DNS (Domain Name service) of ALB, twtech can browser the application.

DNS: twtech-ALB-576142xxx.us-east-2.elb.amazonaws.com
If twtech-user refreshes the page, the privateIP address will change from one target (instance) to another. Traffic from twtech-users and N-users is seamlessly routing from one instance to another. This a prove that load balancing is actually happening.
twtech-insights:

When the target group displays a healthy status, it means traffic can be routed to them.
If any of the targets(instances) fails or stop to run

The target will display unused:

Therefore, traffic will on be routed to the healthy targerts. twtech-db-server
If the stopped instance (twtech-web-server) is restarted, traffic will start to route again to the target too. twtech-web-server

Give the target(instance) restarted a couple of minutes to fully initialize and become healthy again.

Refresh the tagets groups to be sure the status has been restored to: healthy
Routing to both targets(instances) is restored
And: