Application Load Balancer (ALB)

An Application Load Balancer (ALB) is a Layer 7 load balancer that routes incoming HTTP and HTTPS requests based on the actual content of the request — the URL path, hostname, HTTP headers, or query parameters — rather than just distributing raw network connections, which is what Layer 4 load balancers do.

Why Layer 7 Routing Matters

Because an ALB can inspect the actual HTTP request, it can make much more sophisticated routing decisions than a simple round-robin distribution of connections: requests to /api/* can be routed to one backend service while requests to /images/* go to a completely different one, all behind the same load balancer and domain name. This makes ALBs a natural fit for microservices architectures, where a single public-facing domain often needs to route different paths to entirely different backend services, and for A/B testing or canary deployments, where header- or weight-based routing rules can split traffic between application versions.

Additional Layer 7 Capabilities

Operating at the HTTP level also lets an ALB perform tasks that require understanding the request content: terminating SSL/TLS and forwarding decrypted traffic to backends, handling WebSocket connections, performing health checks against a specific HTTP path and expected response code, and adding or modifying HTTP headers as requests pass through.

ALB vs. Network Load Balancer

The tradeoff for this added intelligence is some additional processing latency compared to a Layer 4 Network Load Balancer, which doesn’t inspect request content at all and can therefore forward raw TCP/UDP connections with minimal added latency. In practice, most standard web applications default to an ALB for its routing flexibility, reserving an NLB for cases needing the absolute lowest latency or handling non-HTTP protocols.

ALB Target Groups and Health Checks

An ALB routes traffic to backend resources organized into target groups, each with its own configurable health check that determines which registered targets are currently eligible to receive traffic — an unhealthy target is automatically removed from rotation without requiring any manual intervention or DNS change. This same target group mechanism is what enables weighted routing between application versions for blue-green or canary deployments: a single ALB listener rule can split traffic across two target groups by percentage, giving teams fine-grained control over a gradual rollout without needing a separate specialized deployment tool.

ALBs also support sticky sessions via cookies for applications that need a given user routed consistently to the same backend instance across requests, a feature that becomes necessary when backend servers maintain per-user session state locally rather than in a shared external session store.