πŸŽ‰ We are launching a new weekly show: Hot off the Cloud

πŸŽ‰ We are launching a new weekly show

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

Andreas Wittig – 24 Jun 2022

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.

ALB vs. NLB

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:

ALB and NLB distributing incoming requests

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.


Looking for a new challenge?

  • tecRacer

    Cloud Consultant • AWS Migrations

    tecRacer β€’ Premier AWS Consulting Partner β€’ Germany, Austria, Portugal, and Switzerland
    Assessment Transformation Change Management
  • DEMICON

    Senior Lead Full Stack Developer

    DEMICON β€’ AWS Advanced Consulting Partner β€’ Remote
    AWS JavaScript/TypeScript Angular React

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.

ALB NLB
Protocols HTTP/1, HTTP/2, gRPC TCP, UDP
Performance Low Latency Very Low Latency
Traffic Spikes ⚠️ Inform AWS Support about huge traffic spikes βœ… Deals with huge and unexpected traffic spikes
Static IP Addresses ❌ No. However, you could place an NLB in front of an ALB. βœ… Yes
TLS Termination βœ… Yes βœ… Yes
Targets EC2 Instance, IP Address, Lambda EC2 Instance, IP Address, ALB
Client IP preservation Use HTTP header X-Forwarded-For Optional, but comes with limitations
Routing Algorithm Round Robin or Least Outstanding Requests Random
Deregistering targets ALB stops sending requests and waits for open requests NLB stops opening new connections, but the application needs to terminate connections properly
Multiplexing βœ… Yes, reuses connections to targets ❌ No, does not reuse connections to targets
Maximum number of targets 1000-5000 500-1000
Security Group Security group of ALB controls inbound traffic, targets reachable from ALB only Security group of targets control inbound traffic, targets reachable from clients
Request based routing βœ… Yes, based on hostname, path, header, … ❌ No
WAF βœ… Yes ❌ No
Authentication βœ… Yes (OpenID Connect, SAML, …) ❌ No
Slow Start Mode βœ… Yes ❌ No
Sticky Session βœ… Yes ❌ No
IPv6 βœ… Yes βœ… Yes
Costs πŸ’°πŸ’°πŸ’° πŸ’°πŸ’° (But causes more connections and therefore higher load on targets.)

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.

Become a cloudonaut supporter

Andreas Wittig

Andreas Wittig ( Email, Twitter, or LinkedIn )

We launched the cloudonaut blog in 2015. Since then, we have published 360 articles, 49 podcast episodes, and 48 videos. It's all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.

Please support us

Have you learned something new by reading, listening, or watching our content? With your help, we can spend enough time to keep publishing great content in the future. Learn more

$
Amount must be a multriply of 5. E.g, 5, 10, 15.

Thanks to Alan Leech, Alex DeBrie, ANTHONY RAITI, Christopher Hipwell, Jaap-Jan Frans, Jason Yorty, Jeff Finley, Jens Gehring, jhoadley, Johannes GrumbΓΆck, Johannes Konings, John Culkin, Jonas Mellquist, Juraj Martinka, Kamil Oboril, Ken Snyder, Markus Ellers, Ross Mohan, Ross Mohan, sam onaga, Satyendra Sharma, Shawn Tolidano, Simon Devlin, Thorsten Hoeger, Todd Valentine, Victor Grenu, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt.