Network Load Balancer Internals: Flow Routing, IPs, and TLS

A Network Load Balancer accepts transport-layer traffic and maps each flow to a healthy target. It supports documented TCP, UDP, and TLS modes with static zonal addresses and optional TLS termination. Updated October 9, 2026. NLB chooses a target with a flow hash rather than an HTTP routing rule.

​

Request and flow path

1. The client resolves the NLB DNS name or uses a zonal address.
2. Traffic reaches a load balancer node in an enabled Availability Zone.
3. A listener matches the destination protocol and port.
4. NLB computes a flow hash and chooses a healthy target allowed by cross-zone settings.
5. Packets in that flow continue to the target until the flow ends or expires.
6. Return traffic follows the required NLB path.

For TCP, AWS documents hash inputs including protocol, source and destination IPs, ports, and initial sequence number. Separate connections from one client can therefore reach different targets. Flow affinity keeps one connection on a target; it is not application session affinity across reconnects.

​

Listeners, target groups, and protocols

Target types include instance, IP, and ALB. An ALB target lets NLB provide static addressing or PrivateLink in front of HTTP-aware routing.

​

Static addresses and DNS

NLB creates a network interface in each enabled Availability Zone with a static private IP. An internet-facing NLB can associate one Elastic IP with each enabled subnet at creation. Clients should still use DNS unless a fixed-address integration requires otherwise. DNS can remove an unhealthy zone’s record. Current NLBs can be created with security groups. You cannot later add security groups to an NLB created without them. NLB has one static address per enabled zone, not one global address.

​

Source IP behavior

NLB does not always preserve client IP. Behavior depends on protocol, target type, topology, and the preserve_client_ip.enabled target-group attribute. When preservation is disabled, targets see a load balancer node address. Proxy Protocol v2 can carry connection metadata when the application supports it. For PrivateLink traffic, AWS documents that client-IP preservation does not apply and targets see the NLB private address. Do not use network source addresses as application identity.

​

Health checks and fail-open behavior

NLB target groups support TCP, HTTP, or HTTPS checks. Distributed checks can produce more probes than one interval suggests. When all targets are unhealthy, NLB can fail open and send traffic to all targets. It can also fail open when every enabled zone has an empty target group. Traffic continuing does not prove that healthy capacity exists.

​

Cross-zone behavior

Cross-zone load balancing is disabled by default for NLB. Leaving it off preserves zonal affinity but requires healthy capacity in every enabled zone. Enabling it shares capacity across zones but changes failure boundaries and can affect transfer cost. Test zone failure, scaling, health checks, and DNS behavior either way.

​

TLS termination

A TLS listener uses ACM or IAM certificates and an NLB security policy. NLB negotiates client TLS, then establishes a separate target connection. TCP targets receive plaintext after termination; TLS targets receive a new encrypted connection. NLB still does not perform HTTP routing after TLS termination.

​

PrivateLink and metrics

PrivateLink endpoint services commonly use NLB because consumers connect through interface endpoints without public routing. Providers configure allowed principals, acceptance, and zonal availability. Monitor ActiveFlowCount, NewFlowCount, ProcessedBytes, healthy and unhealthy hosts, target and load-balancer resets, TLS errors, port allocation errors, and zonal health.

​

Frequently asked questions

​

Sources and further reading

• Network Load Balancer introduction
• NLB attributes
• NLB target groups
• NLB health checks
• NLB CloudWatch metrics