Complete Overview of AWS Application Load Balancer Version 2

After launching a basic web app using EC2 and Route 53, Arjun was feeling good. Traffic was picking up. Features were getting added. Users were happy... until things started to break.

“My app works fine... until it doesn’t.”

He realized that as more people used different parts of the app—like login, user search, and mobile access—he needed a smarter way to handle incoming traffic.

That’s when he was introduced to the Application Load Balancer (ALB v2)—a powerful tool in AWS designed for modern web applications.

📘 What Is ALB v2? (Layer 7 Load Balancing Explained)

An Application Load Balancer is a Layer 7 (HTTP/HTTPS) load balancer. An Application Load Balancer (ALB) is a Layer 7 load balancer in AWS that routes HTTP and HTTPS traffic based on content of the request (URLs, headers, hostnames, query strings, etc.). This means it understands and inspects web traffic—URLs, headers, cookies, and more.

With ALB, you can:

Distribute traffic across multiple applications
Use smart rules to route traffic
Terminate HTTPS connections
Support HTTP/2 and WebSockets

“It’s like having a smart traffic cop who reads every sign and sends each car the right way.”

🛣️ Path-Based Routing in ALB

Path-based routing lets ALB route incoming requests based on the URL path (everything after the domain).

Arjun’s app had:

/users → user profiles
/search → search functionality

With path-based routing, ALB v2 can route requests based on the URL path.

So:

Requests to /users go to Target Group A
Requests to /search go to Target Group B

Each group has its own EC2 instances or services behind it.

🌐 Host-Based Routing in ALB

Host-based routing allows ALB to route requests based on the Host header in the HTTP request—typically the domain or subdomain used.

Later, Arjun wanted to serve:

Requests to api.arjunapp.com → API Target Group
Requests to admin.arjunapp.com → Admin Target Group

This is helpful when multiple subdomains need to be handled by different applications or environments behind a single load balancer.

🔍 Query String & Header-Based Routing

Arjun wanted to customize routing based on device type or user preferences.

ALB v2 supports advanced routing using:

Query strings: ?platform=mobile
Headers: User-Agent, Authorization, etc.

Use case examples:

Mobile traffic (?platform=mobile) → Mobile backend
User-Agent: iPhone → iOS-specific service
Header: X-Beta-User: true → Canary deployment target group

Arjun loved this flexibility for A/B testing, device-specific routing, and experimentation.

🧱 ALB Target Groups & Supported Backends

A target group is just a collection of servers or services (like EC2 instances, containers, or Lambda functions) that handle incoming traffic.

When someone makes a request to your website, the Application Load Balancer (ALB) looks at the request and decides which target group to send it to, based on rules you set (like path or hostname).

Think of it like this:
The ALB is the traffic controller, and target groups are the destinations where traffic gets sent.

Each rule in the load balancer (called a listener rule) says:

“If someone visits /login, send them to Target Group A. If they go to /search, send them to Target Group B.”

Supported targets:

Target Type	Description
EC2 instances	Traditional backend servers
ECS tasks	Containerized services
Lambda functions	Serverless APIs
IP addresses	On-prem servers or hybrid architectures

Each target group can be independently monitored with health checks.

Arjun used EC2, ECS, and Lambda targets—all in one load balancer.

🧩 ALB with Microservices, Containers & Lambda

ALB is ideal for microservices, as each microservice can have its own path or hostname and route to a unique target group.

/user → EC2-based app
/search → ECS containers
/status → Lambda function
/data → On-premise backend

All these ran behind a single ALB, with smart rules to route traffic to the right backend.

This flexibility made ALB ideal for microservices, hybrid environments, and serverless apps. This pattern is scalable, modular, and aligned with cloud-native best practices.

💓 ALB Health Checks per Target Group

Each target group has its own health check settings.

Example:

Protocol: HTTP
Port: 8080
Path: /health

If a target doesn’t return a healthy response (e.g., 200 OK), ALB stops sending traffic to it—automatically.

This improves reliability and prevents downtime from affecting users.

🔐 HTTPS & Redirect Rules at ALB Level

Arjun wanted all users to access his site via HTTPS.

With ALB, he could:

Use SSL certificates from AWS Certificate Manager (ACM)
Set up redirect rules from HTTP to HTTPS
Handle encryption at the load balancer level (SSL termination)

This made his setup secure, centralized, and easy to manage.

📬 Preserving Client IPs: X-Forwarded Headers

Since ALB acts as a middleman between the client and backend, backend servers don’t directly see the client’s IP. To fix this, ALB adds special headers:

Header	What It Contains
`X-Forwarded-For`	Client’s real IP address
`X-Forwarded-Port`	Original request port (e.g., 443)
`X-Forwarded-Proto`	Protocol used (HTTP or HTTPS)

Arjun made sure his app logged real client IPs by reading the X-Forwarded-For header.

🧠 ALB v2 Features Recap

Here’s a summary of what Arjun implemented:

Feature	Description
Layer 7 Routing	Inspects full HTTP request
Path/Host Routing	Split traffic based on URL or hostname
Query/Header Rules	Advanced routing logic
Target Groups	EC2, ECS, Lambda, IPs
HTTPS Termination	With ACM integration
Health Checks	For high availability
X-Forwarded Headers	Preserve client context
Redirects & Fixed Responses	Instant responses or secure redirects

🎉 ALB in Action: Arjun’s Final Setup

In the end, Arjun configured one smart Application Load Balancer to:

Route traffic to multiple apps and services
Handle secure HTTPS connections
Balance load based on paths, hosts, and query parameters
Monitor health and avoid broken services
Keep infrastructure scalable, modular, and modern

🚀 Why Use ALB v2 in Modern Architectures?

For SAA students and cloud practitioners alike:

ALB v2 is ideal for web apps, microservices, and APIs
It’s fully managed, scalable, and secure
You gain advanced routing, observability, and automation

“ALB isn’t just a traffic splitter—it’s the traffic brain of your application.”