Amazon recently announced a new load balancing option, the Network Load Balancer (NLB). In their words, it is “designed to handle millions of requests per second while maintaining ultra-low latencies.” Here are some of its key characteristics and features:
- It operates at the layer 4 level
- It uses a single static IP address per AZ (EIPs are supported too)
- It supports network AND application target health checks
- It supports long-lived TCP connections (open for months or even years). This makes it ideal for WebSocket, IoT, gaming, etc.
- Like the ALB, IP addresses can be used as targets (not just instances in EC2)
- It’s great for volatile traffic patterns (no more calling AWS ahead of time to pre-warm a load balancer)
- It’s CloudFormation-ready out of the gate
Level 4 Advantages
Because the NLB operates at layer 4, you will see a couple differences:
- The client IP address is preserved, so you don’t have to use HTTP headers such as X-Forwarded-For to retrieve it
- Security groups can be used to refer to client traffic rather than specifying the load balancer itself as the source. As a side note, you actually cannot specify a security group for the NLB.
Limitations
The NLB does have some limitations:
- Cross-zone load balancing is not supported. In other words, each AZ will receive the same amount of traffic, even if you have more targets in one AZ.
- No SSL offloading/termination
Routing Algorithm
One interesting thing I’ve noticed is that the NLB actually uses a different routing algorithm when selecting which target receives traffic. Before that happens though, it selects a load balancer node as described below:
“Before a client sends a request to your load balancer, it resolves the load balancer’s domain name…The Amazon DNS servers return one or more IP addresses to the client, which are the IP addresses of the load balancer nodes…The client determines which IP address to use to send requests to the load balancer.”
It’s at this point that the NLB differs. The load balancer node that receives the connection uses a “flow hash” routing algorithm to decide which target to send traffic to. While there isn’t much out there published on this, the documentation does point out that NLBs “attempt to route a series of requests from a particular source to targets in a single subnet.” This seems to indicate that the flow hash algorithm is based somewhat on the flow of traffic and where it originates from. I was able to confirm this by generating a large amount of test traffic from one source and noticing that only one AZ was being used.
ALBs, on the other hand, use a round robin routing algorithm, and classic load balancers use round robin routing for TCP listeners and the least outstanding requests algorithm for HTTP/HTTPS.
Pricing
As far as pricing, NLBs are billed based on the hours the load balancer is running as well as Load Balancer Capacity Units (LCU) — which are calculated based on a combination of new connections, active connections, and bandwidth.
Amazon has said that “most applications are bandwidth-bound and should see a cost reduction (for load balancing) of about 25% when compared to Application or Classic Load Balancers.”
Which Load Balancer Should I Use?
With three options to choose from now and features that do overlap somewhat, here are some guidelines for choosing the right solution:
- NLB: good for TCP traffic and applications that require high throughput, low latency, scalability that is immediately responsive, and a static IP per AZ. It also has the potential for being slightly cheaper in some cases.
- ALB: great for advanced request routing of HTTP/HTTPS traffic, and a good fit for microservices/container-based workloads.
- ELB: with the introduction of the NLB, this is now probably only a good fit for workloads that are still operating on the EC2-Classic platform.
For a more detailed comparison, check out the product page.
With the release of the NLB, a lot of the advanced capabilities of the ALB are now available for TCP load balancing scenarios.
If you have additional questions about Load Balancers (or anything AWS-related), let us know! Schedule a consultation. We’d love to chat with you about how 1Strategy can help your business with your journey into or through the AWS cloud.
