AWS Network Load Balancer (NLB): What It Is and When to Use It

Definition

The Network Load Balancer (NLB) is an Elastic Load Balancing type that operates at the transport layer (OSI Layer 4). It forwards TCP, UDP, and TLS connections to registered targets with ultra-low latency — typically sub-millisecond — and scales to millions of requests per second without pre-warming. NLB is the go-to choice for non-HTTP protocols, latency-sensitive workloads, static-IP requirements, and exposing services via AWS PrivateLink.

Where ALB inspects HTTP content, NLB makes routing decisions based on a flow hash of source IP, source port, destination IP, destination port, and protocol — making it protocol-agnostic above TCP and perfectly suited for database, gaming, IoT, and VoIP traffic.

How It Works

NLB is built from the same listener/target-group primitives as ALB, but the behavior underneath is very different:

• Listener — accepts connections on TCP, UDP, TCP_UDP, or TLS. Unlike ALB, there are no content-based rules; a listener forwards to a single default target group.
• Target Group — a pool of EC2 instances, IP addresses, ALBs (ALB-as-target), or containers. Health checks can be TCP, HTTP, or HTTPS.
• Static IPs — NLB automatically provisions one static IP per Availability Zone in which it is deployed. You can assign an Elastic IP to each AZ's node for a fixed address that persists across re-creation.
• Cross-zone load balancing — off by default (different from ALB). When off, each AZ's node only sends to targets in its own AZ.
• Security groups (SG) — NLBs now support security groups (launched 2023). Previously, NLB had no SG of its own and targets had to allow traffic from client IPs directly.
• Source IP preservation — the client's true IP is preserved end-to-end for instance and IP targets. For IP targets outside the VPC, preservation may require proxy protocol v2.

Because NLB is connection-based and stateless at the flow level, it achieves extreme throughput with minimal compute, and it can handle sudden traffic spikes without the warm-up that older Classic balancers required.

Key Features and Limits

• Protocols: TCP, UDP, TCP_UDP, TLS.
• Performance: sub-millisecond latency; tens of millions of requests per second per NLB.
• Static IPs: one per AZ, with optional Elastic IPs for each.
• TLS termination or passthrough: NLB can terminate TLS with ACM certificates or pass encrypted traffic straight through to targets.
• PrivateLink: NLB is the only load balancer you can expose as a VPC Endpoint Service (PrivateLink provider side).
• Security groups: supported as of 2023; choose at NLB creation.
• Connection draining / deregistration delay: graceful removal of targets.
• Cross-zone load balancing: optional; additional data-transfer charges apply when enabled.
• Health checks: TCP, HTTP, HTTPS; faster detection intervals than CLB.
• Targets: EC2, IP (including on-premises over DX/VPN), ALB-as-target, containers.
• Limits: 50 listeners, 3,000 targets per AZ per NLB, 200 IP addresses per target group (IP type).

Common Use Cases

1. Non-HTTP protocols — MQTT, SMTP, SSH, RDP, game protocols, custom TCP/UDP services.
2. Databases — TCP frontends for PostgreSQL, MySQL, Redis, or Kafka clusters.
3. Static-IP allowlisting — third-party firewalls or partners that require a fixed IP; NLB's Elastic IPs satisfy this requirement.
4. PrivateLink providers — SaaS providers expose their service as a VPC Endpoint Service, which must front an NLB.
5. Latency-sensitive workloads — real-time bidding, high-frequency trading, multiplayer gaming.
6. High-throughput event ingestion — millions of IoT device connections terminating on NLB.
7. Hybrid architectures — targets are on-premises IPs reachable over Direct Connect; NLB load-balances to them exactly as it would to EC2.
8. NLB-fronted ALB — place an NLB in front of an ALB when you need both a static IP and Layer 7 routing.

Pricing Model

NLB pricing mirrors ALB's structure:

• Load balancer hours — a fixed per-hour rate per NLB.
• Network Load Balancer Capacity Units (NLCU) — measured on the highest of four dimensions per hour: new flows (per second), active flows (per minute), processed bytes (per hour), and TLS connections (for TLS listeners). Only the dominant dimension is billed.

For workloads with sustained high throughput or millions of concurrent connections, NLCU pricing tends to be more economical than ALB's LCU for the same data volumes. Cross-zone load balancing adds inter-AZ data transfer charges.

Pros and Cons

Pros

• Ultra-low latency and extreme throughput.
• Static IPs per AZ with optional Elastic IPs.
• Preserves the client's source IP end-to-end.
• Supports TCP, UDP, and TLS.
• Required for PrivateLink provider endpoints.
• Scales instantly — no pre-warming needed.

Cons

• No Layer 7 features: no path/host routing, no auth, no WAF.
• No HTTP-specific observability (access logs are limited; use VPC Flow Logs).
• Cross-zone load balancing is off by default, which can surprise architects coming from ALB.
• Because source IP is preserved, target security groups must allow the full internet (or expected client CIDRs) when NLB is public — unless NLB SGs are used.

Comparison with Alternatives

| Feature | NLB | ALB | GWLB | Global Accelerator | | --- | --- | --- | --- | --- | | Layer | 4 (TCP/UDP/TLS) | 7 (HTTP/HTTPS) | 3/4 (GENEVE for appliances) | 4 (anycast) | | Static IPs | Yes (per AZ, EIPs) | No | No | Yes (2 anycast IPs globally) | | Latency | Sub-millisecond | Millisecond | N/A (traffic mirroring) | Lowest (AWS backbone) | | Source IP preserved | Yes | No (XFF header only) | Yes | Yes | | PrivateLink provider | Yes | No | No | No | | Auth / WAF | No | Yes | No | No | | Protocols | TCP/UDP/TLS | HTTP/HTTPS/WS/gRPC | All (via appliances) | TCP/UDP | | Use case | Non-HTTP, static IP, PrivateLink | Web apps, microservices | Inline security appliances | Global non-HTTP accel. |

Global Accelerator is sometimes confused with NLB but is complementary: Global Accelerator gives you two global anycast IPs that route to regional NLBs or ALBs via the AWS backbone, improving global client latency and providing faster failover than DNS.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — choosing NLB vs ALB, static IP requirements, sticky sessions with source IP, TLS termination vs passthrough, PrivateLink provider architecture.
• Developer Associate (DVA-C02) — exposing services internally via NLB + PrivateLink, health checks.
• Advanced Networking Specialty (ANS-C01) — NLB internals, flow-hash behavior, source IP preservation caveats, cross-zone load balancing costs, NLB-in-front-of-ALB patterns.
• Security Specialty (SCS-C02) — when to use NLB with security groups, inspecting traffic via Gateway Load Balancer.

Classic exam traps: NLB is required for PrivateLink provider endpoints. NLB preserves source IP (no X-Forwarded-For needed). NLB supports static/Elastic IPs — ALB does not. NLB cross-zone load balancing is OFF by default, unlike ALB. NLB can terminate or pass through TLS — useful when the target must see encrypted traffic (regulatory or custom crypto).

Frequently Asked Questions

Q: When should I choose NLB instead of ALB?

A: Choose NLB when you need non-HTTP protocols (TCP, UDP, TLS), ultra-low latency, static IP addresses, true client source-IP preservation, or you are exposing a service via AWS PrivateLink (NLB is the only supported front-end). Choose ALB when you need Layer 7 routing (path/host/header), WebSockets with HTTP routing, gRPC, Cognito/OIDC authentication, WAF protection, or Lambda targets. For scenarios requiring both, put an NLB in front of an ALB using the ALB-as-target feature.

Q: Does NLB support static IP addresses?

A: Yes. NLB automatically provisions one static IP per Availability Zone it is deployed in. You can optionally assign an Elastic IP to each AZ's node for a fully fixed address that persists across NLB re-creation. This makes NLB the standard choice when a corporate firewall or a partner requires IP allowlisting, or when clients cannot rely on DNS (e.g., DNS-less IoT devices). ALB does not offer this.

Q: Why is cross-zone load balancing off by default on NLB?

A: NLB disables cross-zone load balancing by default to avoid implicit inter-AZ data transfer charges and to preserve ultra-low latency. When disabled, each AZ's NLB node only distributes traffic to targets in the same AZ. If AZ target counts are uneven, this can cause imbalance — turn cross-zone on (at the NLB or target group level) to spread load evenly, accepting the inter-AZ data-transfer fees. ALB has cross-zone always on and included in the price.

---

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