Application Load Balancer — How an ALB Works and When to Use One

An Application Load Balancer (ALB) distributes incoming requests across backend servers by inspecting the request itself, the HTTP host header, the URL path, cookies, methods. It works at Layer 7, which is what separates it from a Layer 4 load balancer that only sees addresses and ports.

That difference determines what you can do. A Layer 4 balancer forwards a TCP connection to a server. A Layer 7 balancer reads the request and can decide that /api/* goes to one pool and /images/* to another, from the same public address.

Layer 4 vs Layer 7

Choose Layer 4 when the protocol is not HTTP or when raw throughput and latency dominate. Choose Layer 7 for anything web-facing, the routing flexibility and meaningful health checks are worth the small latency cost.

How Requests Flow

1. A client resolves your DNS name to the load balancer’s address.
2. The ALB accepts the connection and terminates TLS, decrypting the request.
3. It matches the request against its routing rules, host, then path, then any header conditions.
4. It picks a healthy backend from the matched target group, using its balancing algorithm.
5. It opens (or reuses) a connection to that backend and forwards the request, adding X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Port.
6. The response returns through the ALB to the client.

Step 2 has a consequence worth planning for: the backend sees the load balancer’s IP, not the client’s. Applications that log client addresses, rate limit, or apply geographic rules must be configured to trust X-Forwarded-For, and to trust it only from the load balancer, or clients can forge it.

Content-Based Routing

This is the main reason to run an ALB:

Rules are evaluated in priority order and the first match wins, the same model as an ACL, and the same trap: a broad rule placed above a specific one makes the specific one unreachable.

Balancing Algorithms

Round robin is the intuitive choice and often the wrong one. If some requests take 5 ms and others take 5 seconds, round robin will keep sending work to a backend already struggling. Least outstanding requests adapts automatically.

Health Checks, Get These Right

A health check that only confirms the port is open will keep routing traffic to a server whose database connection has failed. The endpoint should verify the things the application actually needs:

GET /health

{
  "status": "ok",
  "database": "ok",
  "cache": "ok"
}

Two failure modes to avoid. A health check that hits the database on every probe multiplies database load by the number of backends times the check frequency, cache the result for a few seconds. And a check that is too deep will mark every backend unhealthy when a shared dependency has a brief problem, taking the whole service down rather than degrading it.

Sticky Sessions

Session affinity pins a client to one backend, usually with a cookie. It is sometimes necessary and is generally a symptom of an architectural problem:

• It defeats even load distribution, long-lived sessions accumulate unevenly.
• It makes deployments harder, because draining a backend disconnects its users.
• It loses session state entirely when a backend fails.

The better answer is stateless backends with session data in a shared store, Redis, Memcached, or a database. Then any backend can serve any request, and scaling, deployment and failure all become simpler. Use sticky sessions when you cannot change the application, not as a design choice.

Setting One Up

1. Create target groups, one per backend pool, with the protocol, port and health check for each.
2. Register targets, instances, containers or IP addresses.
3. Create the load balancer across at least two availability zones or sites. A single-zone load balancer is a single point of failure.
4. Add listeners, port 443 with a TLS certificate, and port 80 configured to redirect to 443.
5. Write the routing rules, most specific first, with a catch-all default at the lowest priority.
6. Configure security groups, the load balancer accepts from the internet; the backends accept only from the load balancer. Leaving backends publicly reachable defeats the point.
7. Enable access logging before you need it.
8. Point DNS at the load balancer, using an alias or CNAME rather than a fixed IP.
9. Test failure, stop a backend and confirm traffic moves without errors.

Things That Catch People Out

• Idle timeout mismatch. If the load balancer’s idle timeout is longer than the backend’s keep-alive, the backend closes a connection the load balancer still considers usable, producing intermittent 502s. Set the backend’s keep-alive higher than the balancer’s idle timeout.
• Redirect loops. The ALB terminates TLS and forwards HTTP, so an application that redirects HTTP to HTTPS will loop forever. Check X-Forwarded-Proto instead of the connection scheme.
• Client IP lost. Configure the application to trust X-Forwarded-For, and only from the load balancer’s addresses.
• No connection draining. Removing a backend without draining kills in-flight requests. Set a deregistration delay longer than your slowest request.
• Health check too shallow. Checking that the port is open tells you nothing about whether the application works.
• Certificate expiry. Automate renewal, and alert on it.

Frequently Asked Questions

What is the difference between an ALB and an NLB?

An ALB works at Layer 7 and routes on HTTP content, host, path, headers. An NLB works at Layer 4 and forwards based on address and port only. Use an ALB for web applications, an NLB for non-HTTP protocols or extreme throughput.

Does a load balancer terminate TLS?

An ALB normally does, which is what lets it read the request and route on it. You can re-encrypt to the backend if the traffic must stay encrypted internally.

Why does my application see the load balancer’s IP instead of the client’s?

Because the balancer opens its own connection to the backend. The original address is in the X-Forwarded-For header, which your application must be configured to read, and to trust only from the load balancer.

Do I need sticky sessions?

Only if the backends hold session state locally. Storing sessions in a shared cache removes the need and makes scaling and deployments much simpler.

What causes intermittent 502 errors behind a load balancer?

Most often an idle timeout mismatch, the backend closes a connection the balancer still believes is open. Set the backend keep-alive longer than the balancer’s idle timeout.

How many backends should a load balancer have?

At least two, in different availability zones or racks, so one failure does not take the service down. Beyond that, size for peak load with enough headroom that losing one instance does not overload the rest. See software load balancers for the wider comparison.