ALB vs. NLB: Which AWS load balancer fits your needs?

Which load balancer fits my workload best? As is often the case, AWS offers more than one solution. Read on to learn whether to use the Application Load Balancer (ALB) or the Network Load Balancer (NLB) to distribute incoming requests among a fleet of virtual machines or containers.

This is a cross-post from the Cloudcraft blog.

I created the following diagram showing an ALB and an NLB both distributing incoming requests among two EC2 instances:

The components

The components are the same for both the ALB and the NLB. The following figure illustrates the components.

• The load balancer acts as the entry point into your system.
• The listener listens for incoming connections
• The load balancer forwards requests to a target group.
• The target group consists of one or multiple targets.
• A target might be an EC2 instance, container, or internal service.
• The health check monitors the targets.

As the components are the same, it is not a big deal to switch from an ALB to an NLB -or vice versa. Of course, you can only do so if you do not use any features of the ALB that the NLB does not provide.

The default

When in doubt, choose the ALB. There are two main reasons for that:

1. The ALB comes with a lot of built-in features. See the comparison table at the end of the article.
2. The NLB comes with a few rough edges and requires more experience and care.

So when deciding between an ALB and an NLB, choose the ALB unless one of the points we discuss next applies to your scenario.

The exceptions

If the answer to one of the following questions is “yes”, consider an NLB for your workload.

Do clients connect via UDP or non-HTTP?

The ALB only supports HTTP/1.1, HTTP/2, or gRPC. So when clients use a different protocol to connect with your application, you need to use the NLB instead. For example, all scenarios that are using UDP do require an NLB. Also, when you want to use HTTP/3, the NLB is currently your only choice.

Do you need to optimize for performance?

The ALB operates on layer 7, which means the ALB inspects the details of every incoming HTTP request. In contrast, the NLB works on layer 4. All the NLB cares about is forwarding the incoming TCP or UDP connection to a target. The NLB does not inspect an incoming HTTP request, for example.

Therefore, the NLB has much less work to do than an ALB. As a result, the NLB needs significantly less time to forward an incoming request. So when performance is crucial to your workload, you should consider using an NLB to reduce latency.

Do you expect unpredictable and huge traffic spikes?

The ALB adapts to an increase of connections and requests automatically. However, it takes minutes to do so. So, when expecting substantial traffic spikes, the ALB might not be able to scale fast enough to handle all incoming requests immediately. AWS advises informing their support team when you expect a huge traffic spike in the future to allow them to pre-warm the ALB for you. However, this approach only works when you can predict traffic spikes.

In contrast, the NLB does not need to scale the number of nodes processing incoming connections. Instead, the NLB is designed to handle unpredicted and huge traffic spikes.

So, when you expect unpredicted and substantial traffic spikes, the NLB is a better fit. Unfortunately, AWS does not define what “huge traffic spike” means. Most applications will never reach the limits of an ALB. Think of traffic spikes caused by a super-bowl ad hitting your web application or the new Playstation becoming available at your online shop as scenarios where this becomes an issue.

Do you require static IP addresses for inbound traffic?

To connect to an ALB, a client needs to resolve its DNS name. For example, one of my load balancers is reachable via jenkins-YC728XLHQAVF-1237735722.eu-west-1.elb.amazonaws.com resolves to 52.17.44.105 and 34.248.155.206. The IP addresses are subject to change. For example, when the ALB needs to scale, the name would point to additional IP addresses.

So when you need static IP addresses for inbound traffic, the ALB is not an option. Luckily, that’s something the NLB comes with out-of-the-box. Typical scenarios are: a third party that insists on static IP addresses to create firewall rules, or a client that does not come with the ability to resolve hostnames.

The comparison

The following table compares the ALB and NLB in detail.

The mental model

When it comes to AWS, it helps to have a mental model of the provided building blocks.

Think about the ALB as a reverse proxy distributing incoming requests among a fleet of virtual machines or containers. Besides that, the ALB provides features like request-based routing, authentication, and security. The ALB is like a fully-managed, scalable, and highly available version of NGINX, HAProxy, or Caddy.

In contrast, think about the NLB as a way to route traffic to a fleet of virtual machines or containers on the network layer. You get static anycast IP addresses pointing to a dynamic pool of targets. Similar services are the AWS Global Accelerator and the Google Cloud Load Balancer.

Summary

If you have to pick a load balancer, choose the ALB unless you can find a good reason to go with an NLB. Typical reasons for selecting an NLB instead of an ALB are:

• The workload requires UDP or a non-HTTP protocol.
• Latency is very crucial, and you have to optimize for every millisecond.
• Unexpected and huge traffic spikes are likely to happen.
• Static IP addresses are required for inbound traffic.