Application Load Balancer (ALB) Version 2 (Introduced in 2016) | Overview & Hands-On.

An overview & Hands-On for Application Load Balancer (ALB) Version 2 (Introduced in 2016).

Focus:

• Tailored for Devops, DevSecops & Cloud Engineers.

Breakdown:

• Intro,
• The concept:  Load Balancers, 
• Types of Load Balancers, 
• Layer 4 Load Balancer (Transport Layer),
• Layer 7 Load Balancer (Application Layer),
• Global Load Balancer / DNS-Based Load Balancer,
• Hardware Load Balancer,
• Software Load Balancer,
• Application Load Balancer (ALB) Architecture in detail,
• key features of Application Load Balancers (ALB),
• Benefits of Using appplication load balancer in modern infrastructure,
• Real-World Scenario for ALB,
• Target Groups & use cases,
•  twtech Target Group Creation (AWS CLI),
• Health Check Configuration,
• Key differences between:  ALB, NLB and GWLB,
• Recommendation of When-to-Use-what-type of Load balancer,
• Project: Hands-On.

Intro:

The concept:  Load Balancers

• An AWS Application Load Balancer (ALB) is a service that operates at the application layer (layer 7 of the OSI model).
•  An AWS Application Load Balancer (ALB) distributes incoming HTTP, HTTPS, and gRPC traffic across multiple targets, such as EC2 instances, containers, IP addresses, and Lambda functions. 
• An AWS Application Load Balancer (ALB) intelligently routes requests based on the content of the request, which is ideal for modern application architectures like microservices.
• An AWS Application Load Balancer (ALB) distribute incoming network traffic across multiple servers or resources to ensure reliability, high availability, and optimal performance.

 Types of Load Balancers

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Application Load Balancer (ALB) Architecture in detail.

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.

  ALB 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.

Use Case of ALB

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.

Benefits of Using appplication load balancer in modern infrastructure.

 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. Automated Scalability (Elasticity)

• As traffic grows, twtech can add more backend servers (ALP is Automated / Responsive)
• 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

• twtech 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.

Real-World Scenario for ALB:

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 Server fails, others pick up the load, ensuring seamless user experience.

NB:

• In AWS Application Load Balancer (ALB), the there is Target Group.  
• The Target Groupis 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

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:

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

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.

NB:

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

Project:  Hands-on

How twtech creates the Application Load Balancer(ALB) /Target-groups (TG) and use to distributes incoming HTTP, HTTPS, gRPC traffic across multiple targets, such as EC2 instances, containers, IP addresses, and Lambda functions. 

Step-1:

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

Step-2:

Configure Bootstrap user-data for application:  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 3:

• Use the PrivateIP address to verified that the httpd service was was bootstrapped and enabled

• Verify that Both instances have: httpd service successfully bootstrap

Yes: httpd was bootstrapped in both instances seamlessly

Step 4:

• Navigate to EC2 UI and navigate to Load Balancer to Create a load balancer from: ec2 console: ALB

• Select Application Load Balancer.

Step 5:

• Create ALB
• twtech assign a name: twtech-alb

Step 6:

• 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  

Step 7:

• twtech Selects 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.

Step 8:

• 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: twtech-alb

Step 9:

• Go back to ALB UI (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.

Step 10:

• twtech Creates a target group (group of ec2-instances)

• Assign a Target group name: twtech-alb-tg

• Assign a Protocol : Port
• Choose a protocol for twtech 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 twtech can set mitigation options once its target group is created. 
• This choice cannot be changed after creation

Select the 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.

• Select the Protocol version: HTTP1

• Configure 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

Step 11:

• twtech Goes back to ALB console (UI) refresh and select target group created: twtech-alb-tg

Step 12:

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

NB:

• ALB Needs a couple of minutes to fully provision:

From: Provisioning

To: Active (status)

Step 13:

• twtech accesses the DNS created with the ALB
• With the DNS (Domain Name service) of ALB, twtech can browser its applications seamlessly.

Step 14:

• with the DNS, twtech and N-users can access the application from the internet,
• DNS: twtech-ALB-576142xxx.us-east-2.elb.amazonaws.com

NB:

• As twtech-user refreshes the Application page, the privateIP address changes from one target (instance) to another.  
• Meaning that traffic from twtech-users and N-users is seamlessly routing from one instance to another. 
• This a prove that Application Load balancing is actually  Balancing traffic.

Step 15:

• twtech-insights:
• When the target group displays a healthy status, it means traffic can be routed to them and vice versa.

NB

• If for any reasons any of the targets(instances) fails or stop to run, a health check will be immediately perform and traffic routed or switche to another health instance within the target group

• Step 14:

• twtech stops one of the instance in the target group to verify whether a failover will occure (traffic will be routed to another healthy instance within the target group),
• stop one instane.

• The target will display the instance as: unused

 

Step 16:

• twtech refreshes the application UI and notice that: traffic is only routed to the targets (instances in the target group) which are healthy.
• Therefore, traffic will on be routed to the other healthy targerts. twtech-db-server

• when the stopped instance (twtech-web-server) is restarted, traffic will again to the target too. (twtech-web-server)
• twtech must Give the target(instance) restarted,  a couple of minutes to fully initialize and become healthy again.

• Step 17:

• twtech should Refresh the tagets groups UI,  to be sure the status of the restarted target has been restored to:  healthy

• Evently, Routing to both targets(instances) is restored

And: