You are putting a public HTTPS API in front of a fleet of containers on AWS. When would you choose an Application Load Balancer (ALB) over a Network Load Balancer (NLB), and what can an ALB do that an NLB cannot?

## The one distinction everything else follows from An Application Load Balancer is an HTTP proxy. It accepts the client's TCP connection, completes the TLS handshake itself, reads and parses the HTTP request, and then sends that request to a target over a separate connection that it owns and reuses. A Network Load Balancer operates at layer 4: it forwards TCP or UDP flows to a target without looking inside them. Every capability difference below is a consequence of that single fact - the ALB can act on the request because it has the request in its hands. ## What reading the request buys you **Content-based routing.** An ALB listener holds an ordered set of rules. Each rule matches on some combination of host header, URL path, an arbitrary HTTP header, the HTTP method, the query string, or the connection's source IP, and forwards to a target group. One load balancer and one DNS name can therefore front many services: `api.example.com` to one target group, `/static/*` to another. **Actions that never reach a target.** A rule can answer the request itself with a `redirect` action (the standard HTTP-to-HTTPS redirect on port 80 is exactly this) or a `fixed-response` action returning a status code and a short body - useful as a maintenance page or to cheaply reject unknown hosts. **Authentication at the edge.** The `authenticate-oidc` and `authenticate-cognito` actions make the ALB run the OIDC login flow before forwarding, so an internal tool gets single sign-on without any application code. **WAF.** An AWS WAF web ACL can be associated with an ALB, because inspecting SQL-injection patterns or rate-limiting by URI requires parsing HTTP. There is nothing to associate a web ACL with on an NLB. **Stickiness.** Cookie-based session affinity needs cookies, which means HTTP. **Modern protocols to the target.** A target group can be set to speak HTTP/1.1, HTTP/2 or gRPC to targets, so an ALB can front a gRPC service and even health-check it with a gRPC status matcher. **Per-request telemetry.** ALB access logs and CloudWatch metrics are per request: you get status codes split into `HTTPCode_ELB_5XX_Count` (the load balancer generated it) versus `HTTPCode_Target_5XX_Count` (your app did), plus target response time. An NLB can only tell you about flows and bytes. ## What you give up by choosing the ALB **The source IP.** The target's socket sees the private IP of an ALB node, not the caller. The client address arrives in the `X-Forwarded-For` request header instead, so any allow-listing, rate-limiting or geo-logic in the application has to read that header rather than the connection. **A stable address.** An ALB is reachable only by its DNS name; its underlying addresses change as it scales. If a partner's firewall needs a fixed IP to allow, an ALB alone will not give you one - that is a classic reason to reach for an NLB. **Protocol breadth.** An ALB carries HTTP, HTTPS, WebSocket upgrades and gRPC. It cannot carry SMTP, MQTT, a database wire protocol, or anything over UDP. **A hop of latency and a scaling curve.** Full termination and parsing costs a little more latency than layer-4 forwarding, and the ALB scales its own capacity in response to traffic, so an instantaneous vertical spike can outrun it. ## How I actually decide Ask three questions in order. Is the traffic HTTP? If not, the ALB is out. Does anything - routing, auth, WAF, stickiness - need to look at the request? If yes, the ALB is in. Does something outside your control need a fixed IP or the true client IP on the socket? If yes, either use an NLB or put an NLB in front of the ALB to get static addresses while keeping layer-7 features. ## Where it bites in production The ALB's idle timeout defaults to 60 seconds (`idle_timeout.timeout_seconds`, adjustable). Long-polling endpoints, server-sent events and slow report downloads get cut at exactly one minute and the team blames the application. Second, a 502 from the ALB is not the same failure as a 502 from your service - the ELB-generated code usually means the target closed the connection or returned something unparseable, so always split the two metrics before debugging. Third, remember that the scheme (internet-facing or internal) is fixed when the load balancer is created; you cannot flip a public ALB to private later.