Network Load Balancer (NLB)

## Two different jobs Elastic Load Balancing is a family, not one product. The **Application Load Balancer (ALB)** operates at layer 7: it accepts an HTTP or HTTPS connection, parses each request, and decides where the request goes based on what is inside it. The **Network Load Balancer (NLB)** operates at layer 4: it sees a flow — a source address and port talking to a destination address and port — and forwards that flow to a target. It never parses a request, because at layer 4 there is no such thing as a request; there is only a connection carrying bytes. That single difference generates every practical consequence below. ## Where NLB wins **Non-HTTP protocols.** NLB listeners speak `TCP`, `UDP`, `TCP_UDP` and `TLS`. If the workload is a game server on UDP, a syslog collector, an MQTT broker, an SMTP relay or a database endpoint, ALB simply cannot front it. This is the most common reason an interview answer lands on NLB. **A stable address.** NLB provisions one IP address per enabled subnet, and you can supply your own Elastic IP for each subnet in the subnet mapping when you create the load balancer. Those addresses stay put for the life of the load balancer, which is what makes them allowlistable by a partner's firewall. ALB is addressed by DNS name only; the addresses behind that name are drawn from the AWS pool and change. **The client's source IP arrives natively.** Because NLB does not rewrite the source address for instance targets, the target's own socket reports the real client IP. A layer-7 proxy has to tell you the client address out of band, in a header. **Scale and latency profile.** NLB is designed for very high flow counts and adds very little latency, since it does no per-request work. For a service handling enormous connection volume, that is a measurable difference rather than a marketing line. **PrivateLink.** A VPC endpoint service — the provider side of AWS PrivateLink — is backed by a Network Load Balancer or a Gateway Load Balancer. If your service must be consumed privately from other VPCs or accounts, this alone can decide the load balancer type. ## What you give up Everything that requires understanding HTTP: - Listener rules that route on host, path, HTTP method, header or query string. - Redirect and fixed-response actions handled by the load balancer itself. - Built-in authentication actions that sit in front of your application. - `X-Forwarded-For` and the other forwarding headers a layer-7 proxy inserts. - AWS WAF association: WAF attaches to ALB, CloudFront and API Gateway, not to NLB. - Rich access logs. NLB access logs are produced only for TLS listeners, and describe TLS connections rather than HTTP requests, so "which URL was slow" is not a question an NLB log answers. ## The composite answer Senior answers rarely pick one. NLB targets can be an ALB, so a very common production shape is: NLB at the edge holding the Elastic IPs and the endpoint service, ALB behind it doing host and path routing, WAF on the ALB. You pay for two load balancers and add a hop, and in exchange you get static addressing and layer-7 features at the same time. ```bash # One NLB address per AZ, each pinned to an Elastic IP you already own aws elbv2 create-load-balancer \ --name payments-nlb --type network --scheme internet-facing \ --subnet-mappings \ SubnetId=subnet-0a1b2c3d,AllocationId=eipalloc-11111111 \ SubnetId=subnet-0e4f5a6b,AllocationId=eipalloc-22222222 ``` ## How to reason out loud Ask one question first: *does the routing decision need to see inside the request?* If yes, you want layer 7 and the conversation is about ALB. If no — and especially if the protocol is not HTTP at all, or the requirement is an address rather than a hostname — you want layer 4 and the conversation is about NLB. Both cost an hourly charge plus a capacity-unit charge, so cost is rarely the deciding factor; capability and addressing are.