UDP Support on Network Load Balancer

Use Cases

Priors to the UDP support in NLB, you have deployed services such Authentication and authorization, Directory, logging, and video streaming using either Route 53 DNS based load balancing or by deploying a proxy server fleet to ingest UDP traffic. However, DNS based load balancing caused service interruption on your server upgrades, while managing a separate proxy server fleet increased the cost and operational complexity of your application deployment. UDP support in NLB is a fully managed solution. It simplifies your network architecture by eliminating the need for proxy servers for ingesting UDP traffic

With UDP support in NLB, you can run services that rely on UDP as transport protocol such as Authentication and authorization, Directory, logging, Authoritative DNS, video streaming, IoT and online gaming behind NLB. This also naturally provides the scale and operational efficiencies offered by the Network Load Balancer.

UDP and Network Load Balancer

You can now Network Load Balancer process both TCP and UDP protocol traffic on the same port by using TCP+UDP listener. For example, if you create a listener of type TCP+UDP on port 53, NLB will process traffic for both UDP and TCP DNS requests on port 53. A TCP+ UDP listener must be associated with a TCP+ UDP type target-group.

While UDP is connectionless, the load balancer maintains UDP flow state based on 5-tuple hash -- src-ip, src-port, dst-ip, dst-port, and protocol, making sure that packets sent in the same context are consistently forwarded to the same target. The flow is considered active as long as traffic is flowing and until the idle timeout is reached. Once the timeout threshold is reached, the load balancer will forget the affinity, and incoming UDP packet will be considered as a new flow and load-balanced to a new target. Network Load Balancer idle timeout for TCP connections is is 350 seconds. For UDP flows idle timeout is 120 seconds.

NLB doesn’t support UDP based health checks. At Launch, NLB supports TCP, HTTP and HTTPS health checks. NLB routes requests only to the listening ports on the healthy targets. NLB checks the health of the service on each target, using the health check settings for the target group with which the target is registered. You can specify ping protocol and ping port at the health check creation time.