AWS Application Load Balancer (ALB): What It Is and When to Use It

Definition

The Application Load Balancer (ALB) is an Elastic Load Balancing (ELB) type that operates at the application layer (OSI Layer 7). It understands HTTP and HTTPS traffic, inspects requests, and routes them to target groups based on content — host name, path, headers, method, query string, or source IP. ALB is the default choice for modern web applications, microservices, containerized workloads, and serverless backends on AWS.

Unlike the legacy Classic Load Balancer, ALB is request-based (not connection-based), supports HTTP/2 and gRPC end-to-end, and can invoke AWS Lambda functions directly as a target.

How It Works

An ALB is made up of a small set of building blocks:

• Load Balancer — an internet-facing or internal endpoint registered to two or more Availability Zones. Its DNS name resolves to one or more IPs managed by AWS; there is no static IP.
• Listener — a process that checks for connection requests on a configured protocol and port (e.g., HTTPS:443). Each listener contains an ordered list of rules.
• Listener Rules — evaluate in priority order. A rule matches conditions and forwards the request to a target group, redirects to another URL, returns a fixed response, or authenticates via Cognito / OIDC.
• Target Groups — pools of backend targets (EC2 instances, IP addresses, Lambda functions, or another ALB via ALB-type targets) with their own health-check configuration.
• Health Checks — per target group, using HTTP / HTTPS probes against a configurable path; unhealthy targets are automatically removed.

When a request arrives, the ALB terminates the TCP/TLS connection, parses the HTTP request, walks the rules in priority order, matches the first rule whose conditions are satisfied, and forwards the request to a target chosen by the target group's algorithm (round-robin by default, least-outstanding-requests optional). The client IP is preserved in the X-Forwarded-For header, while the underlying TCP connection appears to the target as coming from the ALB itself.

Key Features and Limits

• Advanced routing — host-based, path-based, HTTP header, HTTP method, query-string, and source-IP conditions. Up to 5 condition values per rule.
• Target types — instance, IP (including on-premises over Direct Connect/VPN), Lambda, and ALB-as-target (for NLB → ALB chaining).
• Protocols — HTTP/1.1, HTTP/2, gRPC, WebSockets, server-sent events.
• TLS termination — ACM or IAM-managed certs; SNI for multiple certificates per listener (25 certs per listener default, raisable).
• Authentication — built-in integration with Amazon Cognito user pools or any OIDC-compliant IdP (Okta, Auth0, Azure AD).
• AWS WAF integration — attach a WebACL directly to the ALB for Layer 7 protection.
• Access logs — per-request logs written to S3; optional connection logs capture TLS details.
• Sticky sessions — application-based (custom) or load-balancer-generated cookies.
• Outposts / Local Zones — ALB is available in Local Zones and on Outposts.
• Limits — 100 rules per ALB (raisable), 5,000 targets per load balancer, 1,000 targets per target group.

Common Use Cases

1. Microservices routing — one ALB with many target groups, path-based rules (/orders/*, /users/*) split traffic across services.
2. Host-based virtual hosting — api.example.com vs admin.example.com on the same ALB using different rules and target groups.
3. Blue/green and canary deployments — weighted target groups shift a small percentage of traffic to a new version, controlled by CodeDeploy or manually.
4. Serverless HTTP APIs — ALB forwards requests directly to Lambda (cheap alternative to API Gateway for simple back-ends).
5. Auth at the edge — offload authentication to Cognito / OIDC before the request hits your application.
6. WAF-protected web apps — WAF WebACL + ALB + WAF-aware rate limits and managed rules.
7. Container workloads — ECS / EKS register tasks as IP targets; dynamic port mapping works cleanly with ALB.

Pricing Model

ALB pricing has two components:

• Load balancer hours — a fixed per-hour rate while the ALB exists.
• Load Balancer Capacity Units (LCU) — measured on the highest of four dimensions per hour: new connections (per second), active connections (per minute), processed bytes (per hour), and rule evaluations (per second). You pay only for the dominant dimension.

Typical web workloads land in the LCU-cheap zone, making ALB cost-effective for steady HTTP traffic. Access logs to S3 incur standard S3 storage charges; WAF adds its own per-request and WebACL fees.

Pros and Cons

Pros

• Rich Layer 7 routing without deploying proxies (NGINX/HAProxy).
• Native Lambda targets — HTTP → Lambda with no API Gateway needed.
• Cognito / OIDC auth built in.
• Deep AWS integration: ACM, WAF, CloudWatch, Shield, EventBridge.
• gRPC and HTTP/2 end-to-end for modern microservices.

Cons

• No static IPs (clients must use DNS). Use NLB-fronted-ALB when allowlisting is required.
• No native support for non-HTTP protocols (no TCP/UDP).
• Does not preserve the client's TCP source IP — applications must read X-Forwarded-For.
• Slightly higher latency than NLB (milliseconds, vs sub-ms).

Comparison with Alternatives

| Feature | ALB | NLB | API Gateway | CloudFront | | --- | --- | --- | --- | --- | | Layer | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 7 (HTTP/REST/WebSocket) | 7 (HTTP + edge cache) | | Routing | Host/path/header/query | Flow hash | Resource/method | Host/path at edge | | Static IPs | No | Yes (per AZ) | No | Yes (anycast) | | Source IP | X-Forwarded-For only | Preserved | Header | Header | | Auth | Cognito / OIDC | None | IAM / Cognito / Lambda Auth | Signed URLs / Lambda@Edge | | WAF | Yes | No | Yes | Yes | | Lambda targets | Yes | No | Yes | Yes (Lambda@Edge) | | Price model | Hour + LCU | Hour + NLCU | Per-request | Per-request + GB |

Choose NLB for non-HTTP traffic, static IPs, or PrivateLink. Choose API Gateway for public REST/WebSocket APIs with strong throttling/auth needs. Choose CloudFront when you need a global CDN in front of your ALB for caching and DDoS protection.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — huge topic: path/host-based routing, ALB + Lambda, Cognito auth, sticky sessions, target types, SSL termination at ALB.
• Developer Associate (DVA-C02) — deploying apps behind ALB, understanding X-Forwarded-For, Lambda-as-target, WebSockets.
• DevOps Engineer Professional (DOP-C02) — blue/green with weighted target groups, ALB + CodeDeploy traffic shifting.
• Advanced Networking Specialty (ANS-C01) — ALB internals, SG implications, ALB-as-target, cross-zone load balancing, hybrid IP targets.

Classic exam traps: ALB has a security group (unlike older NLB). ALB does not support TCP/UDP — use NLB. ALB can authenticate users via Cognito/OIDC without writing code. ALB targets can be Lambda functions or IP addresses on-premises (via Direct Connect/VPN).

Frequently Asked Questions

Q: Can an ALB route to AWS Lambda functions?

A: Yes. Lambda can be registered directly as an ALB target — ALB transforms the HTTP request into a Lambda event and forwards the function's response back to the client as an HTTP response. This pattern is often cheaper than API Gateway for simple serverless HTTP endpoints, and it supports the same Layer 7 routing rules (path, host, headers) as any other target. Note that Lambda targets carry a 1 MB request/response body limit when used with ALB.

Q: Does ALB preserve the client's source IP?

A: Not at the TCP layer — because ALB terminates the connection, targets see the ALB as the TCP peer. However, ALB adds the original client IP to the X-Forwarded-For HTTP header (and also X-Forwarded-Proto and X-Forwarded-Port). Applications must read this header for analytics, rate limiting, or geo-blocking. If true TCP-level source-IP preservation is required, use a Network Load Balancer instead.

Q: How does ALB differ from the Classic Load Balancer?

A: ALB is request-based (Layer 7) with content-based routing, Lambda and IP targets, HTTP/2, gRPC, WebSockets, and Cognito/OIDC auth. The Classic Load Balancer is connection-based, supports only basic round-robin across EC2 targets, and is considered legacy — AWS recommends migrating to ALB (for HTTP) or NLB (for TCP/UDP). New deployments should always choose ALB or NLB; the Classic Load Balancer is retained for backward compatibility.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Application Load Balancer documentation before making production decisions.