AWS NLB: Configure Network Load Balancer for TCP/UDP (2026)

AWS Network Load Balancer (NLB) can route traffic based on IP protocol, not just HTTP headers like Application Load Balancer.

Let’s see it in action. Imagine you have a fleet of game servers running on EC2 instances, and you want a single, stable IP address and port for players to connect to, regardless of which game server is actually handling their request. This is a classic use case for NLB.

Here’s a basic setup:

1. Create a Target Group: This group defines where your traffic will be sent.

   • Protocol: TCP or UDP (pick one for this example, let’s say TCP)
   • Port: 25565 (a common port for games like Minecraft)
   • VPC: Your VPC ID (e.g., vpc-0123456789abcdef0)
   • Target type: Instance (if your game servers are on EC2) or IP (if you’re managing IPs directly)
   • Health checks: Configure these to match your game server’s protocol. For TCP, a simple TCP health check on port 25565 is often sufficient.

2. Register Targets: Add your EC2 instances or their IP addresses to the target group. Make sure your security groups allow inbound traffic on port 25565 from the NLB’s subnet CIDR ranges.

3. Create a Network Load Balancer:

   • Scheme: Internet-facing (for public access) or Internal (for private networks)
   • IP address type: IPv4
   • VPC: The same VPC as your target group.
   • Network mapping: Select at least two Availability Zones for high availability.
   • Listeners: This is where you define how the NLB receives traffic.
     • Protocol: TCP
     • Port: 25565 (the same port players will connect to)
     • Default action: Forward to your target group (e.g., tg-tcp-25565).

Once created, AWS assigns a static IP address (or you can use an Elastic IP) and a DNS name to your NLB. Players connect to this DNS name or IP, and NLB forwards the TCP traffic to one of your healthy game servers in the target group.

The core problem NLB solves here is providing a stable, highly available entry point for protocols that don’t have the rich header information of HTTP/S. It operates at Layer 4 (Transport Layer), meaning it doesn’t inspect the application payload. It simply looks at source IP, source port, destination IP, destination port, and protocol. This makes it incredibly fast and efficient for non-HTTP traffic like TCP, UDP, and TLS.

The "Network Load Balancer" itself is a distributed system. When you create it, AWS provisions a set of network interfaces across the selected Availability Zones. These interfaces act as the entry points for your traffic. NLB uses a flow-based routing mechanism. When a TCP packet arrives at one of the NLB’s IP addresses on the listener port, NLB makes a routing decision based on a hash of flow characteristics (source IP, source port, destination IP, destination port, protocol). It then forwards the packet to a registered target. Importantly, subsequent packets belonging to the same flow will be consistently routed to the same target. This is crucial for stateful applications.

The exact levers you control are primarily the listener protocol/port and the target group protocol/port, and how you configure health checks. The hashing algorithm for flow distribution is managed by AWS and not directly configurable.

What most people don’t realize is that NLB’s TCP/UDP listeners are connectionless from the NLB’s perspective. When a TCP connection is established between a client and a target via the NLB, the NLB effectively hands off the connection. It doesn’t terminate and re-establish the TCP connection itself like an ALB would with HTTP. This is why NLB has a static IP address per AZ, and why it’s so performant. The client’s source IP is preserved and sent directly to the target.

The next thing you’ll likely encounter is needing to handle UDP traffic in a similar fashion, which requires a separate listener and target group.