AWS ALB vs NLB: Which Load Balancer Should You Use?

In This Article

• What is AWS Application Load Balancer (ALB) ?
• What is AWS Network Load Balancer (NLB) ?
• What are the Similarities Between ALB and NLB?
• Internet-Facing or Internal Scheme
• Security Group Support
• IPv6 Support
• TLS Termination
• Session Persistence (“sticky session”)
• Integration with AWS Services
• What are the Differences Between ALB and NLB?
• OSI Layer 7 vs Layer 5
• Target Types
• Supported Protocols
• Round-Robin vs Flow Hash Routing Algorithm
• WAF Support
• Authentication
• Static IP Address Support
• Latency
• AWS PrivateLink Support
• Zonal Isolation
• Cost
• When to Use Each?

What is AWS Application Load Balancer (ALB)?

The main function of the Application Load Balancer (ALB) is to distribute incoming traffic across multiple targets, which can be:

• EC2 instances (e.g., traditional compute servers, EKS worker nodes, ECS worker nodes).
• IP addresses (e.g., on-premises servers, third-party services, cross-VPC instances).
• Lambda functions (e.g., for serverless applications, an alternative to API Gateway, hybrid architectures).

The above example visualizes one ALB with three target groups attached, where each group represents a specific target type, such as EC2 instances, IP addresses, and Lambda functions.

The traffic can be distributed to minimum two or more availability zones. When you create an ALB, you must specify in which availability zones (one subnet per availability zone) you will "enable" it. This means that the ALB will only be able to distribute traffic to the enabled availability zones.

If we go into more detail, each availability zone you enable for the ALB actually creates one instance for that specific ALB. As you can see below, we have enabled the ALB in 3 public subnets to distribute traffic to EC2 instances, and 3 network interfaces have been created (one in each enabled subnet):

An interesting fact is that if there are no targets assigned to a specific ALB, then initially only one network interface will be created; of course, this is completely managed by AWS and does not impact the performance of the ALB in any way.

What is AWS Network Load Balancer (NLB) ?

Network Load Balancer can distribute incoming traffic to multiple targets:

• EC2 instances (e.g., traditional compute servers, EKS worker nodes, ECS worker nodes).
• IP addresses (e.g., on-premises servers, third-party services, cross-VPC instances).
• Application Load Balancer (e.g., TCP/UDP traffic offloading to more advanced HTTP/HTTPS routing, hybrid architectures).

Similarly to the ALB, when you create an NLB and enable it in specific availability zones, one load balancer instance is created in each availability zone. Each instance is represented by one network interface:

What are the Similarities Between ALB and NLB?

Besides their main purpose of distributing incoming traffic to your back-end infrastructure, there are several other similarities between ALB and NLB that I would like to discuss in more detail. This will help you understand the supported functionalities common to both load balancers.

Internet-Facing or Internal Scheme

Both load balancers support the following schemes:

• Internet-Facing: This means that your load balancer will be public and available for clients to send requests over the internet. Essentially, whenever you build an application that needs to be publicly accessible, you must create an internet-facing load balancer.
• Internal: This means that the load balancer will only be accessible privately, and requests will be routed using private IP addresses (e.g., accessible only from the specific VPC, from other VPCs connected via VPC peering / transit gateway, or from on-premises using a site-to-site VPN connection).

Security Group Support

Both load balancers support security groups, which you can use to control the traffic allowed to reach your targets (such as EC2 instances, IP addresses, etc.). For example, you can configure the traffic to be received only from specific IP addresses, enabling you to control who can access your internet-facing or internal load balancers.

IPv6 Support

The popularity of using IPv6 addresses has been growing for a while, which is why both ALB and NLB support IPv6. You can choose the type of IP addresses supported when creating a new load balancer:

TLS Termination

TLS termination refers to the process where encrypted traffic from clients is terminated or decrypted at the load balancer level.

The Application Load Balancer (ALB) performs TLS termination when you create an HTTPS listener. Similarly, the Network Load Balancer (NLB) performs TLS termination when you create a TLS listener. Keep in mind that if you use a different listener, such as TCP, then encrypted traffic will be forwarded (pass-through) to the targets, and traffic decryption will occur there.

You can see in the diagram above the visualized HTTPS traffic flow for Client <-> ALB and NLB <-> EC2 Instances and TLS termination. It is important to know that when TLS termination occurs at the load balancer, you have two options:

• Send unencrypted traffic to the EC2 instance by using HTTP (for ALB) or TCP (for NLB) target groups.
• Send re-encrypted traffic to the EC2 instance by using HTTPS (for ALB) or TLS (for NLB) target groups. This means that encrypted traffic will need to be decrypted at the EC2 instance. Typically, for Load Balancer <-> EC2 Instance traffic encryption/decryption, self-signed certificates are used because the load balancer does not validate whether the certificate is valid or expired.

Session Persistence (“sticky session”)

Session persistence, also known as a "sticky session”, ensures that specific client traffic is routed to the same target (e.g., an EC2 instance) within the target group. This functionality is useful for stateful applications where user-specific data is stored locally on the target instances, ensuring that traffic is consistently routed to the same specific target.

To enable session persistence for an ALB, you need to update the target group and choose between:

• A load balancer-generated cookie, which is managed by ALB.
• An application-based cookie, which provides a flexible option to define your own criteria for identifying a specific client session.

To enable session persistence for an NLB, you need to update the target group and enable the stickiness setting. The Network Load Balancer uses the client's IP address to consistently route traffic to a specific target instance. Be aware that if multiple clients “sit” behind the same router or NAT gateway and share a single public IP address, traffic may not be distributed evenly.

Integration with AWS Services

Both load balancers are tightly integrated with other AWS services, providing nearly everything you need to build highly available, scalable applications. Key integrations that enable the distribution of load balancer traffic to various target AWS services include Amazon EC2, Amazon ECS, Amazon EKS, and AWS Lambda.

Most popular ALB Integrations:

• Amazon EC2: Target groups, Auto Scaling.
• Amazon ECS: Service discovery, task definitions.
• Amazon EKS: AWS Load Balancer controller
• AWS Lambda: Event source for HTTP(S) requests.
• AWS WAF: Web application firewall.
• Amazon Route 53: Hosted zone records.
• Amazon CloudWatch: Monitoring.
• Amazon S3: Logging.
• AWS Certificate Manager (ACM): SSL/TLS certificates.
• AWS Global Accelerator: Global traffic management.

Most popular NLB Integrations:

• Amazon EC2: Target groups, Auto Scaling.
• Amazon ECS: Service discovery, task definitions.
• Amazon EKS: AWS Load Balancer controller
• Amazon Route 53: Hosted zone records.
• Amazon CloudWatch: Monitoring.
• Amazon S3: Logging.
• AWS Certificate Manager (ACM): SSL/TLS certificates.
• AWS Global Accelerator: Global traffic management.
• VPC Endpoint Services: AWS Private Link.

What are the Differences Between ALB and NLB?

While there are many similarities between ALB and NLB, both load balancers have significant differences that are important to understand when choosing the right one for your use case. Let’s now take a closer look at these differences to help you decide which one to choose.

OSI Layer 7 vs Layer 5

ALB operates at the application layer (Layer 7) of the Open Systems Interconnection (OSI) model. Why is this important? Application-level routing allows for traffic manipulation and more advanced routing capabilities. For example, routing for ALB can be based on:

• Host header (ex. app.cloudviz.io)
• Path (ex. /users/settings)
• HTTP request method (ex. POST)
• Source IP (ex. 131.254.118.47)

However, NLB operates at the transport layer (Layer 4) and does not support advanced routing rules like ALB. Traffic for NLB is managed based on ports and IP addresses.

Target Types

Both load balancers as targets where to route incoming traffic support:

• EC2 instances. (e.g., traditional compute servers, EKS worker nodes, ECS worker nodes).
• IP addresses. (e.g., on-premises servers, third-party services, cross-VPC instances).

Additionally, ALB supports Lambda functions as targets for routing traffic. This makes the Application Load Balancer a good option, for example, when you want to build a serverless application but prefer not to use API Gateway for various reasons, such as the limited maximum timeout (30 seconds for edge endpoints) or higher costs for high-throughput applications.

However, NLB additionally supports routing traffic to another ALB. Why would I use an additional load balancer and increase the overall cost? The answer is simple – there may be scenarios where you want to receive TCP traffic while still utilizing the advanced routing capabilities of ALB.

Supported Protocols

ALB supports following protocols:

• HTTP (unencrypted traffic).
• HTTPS (encrypted traffic via TLS, TLS termination at ALB).

NLB supports following protocols:

• TCP (passes TCP traffic directly to targets).
• TLS (encrypted traffic, TLS termination at NLB).
• UDP.
• TCP_UDP.

Almost all protocols differ between ALB and NLB and are used for different use cases. The only similarity is when using HTTPS (ALB) and TLS (NLB), where both load balancers support encrypted traffic and TLS termination at the load balancer level.

Round-Robin vs Flow Hash Routing Algorithm

The default load balancing algorithm used for ALB is round-robin. This algorithm routes traffic evenly across all healthy targets and is most commonly used when requests are similar in complexity.

There are two other ALB routing algorithms that can be used and changed in target group settings:

• Least outstanding requests. This routes traffic to the targets (ex. EC2 instances) with lowest number of on-going tasks.
• Weighted random. This evenly routes traffic to the targets in random order.

For NLB, there is only one default algorithm called flow hash. This algorithm routes traffic based on the hash of the source and destination. The hash is generated using the following attributes:

• Protocol (e.g., TCP, TLS, UDP).
• Source IP address and source port (e.g., 67.52.121.1:443)
• Destination IP address and destination port (e.g., 7.16.98.12:443)
• TCP sequence number (e.g., 305419896)

By using this hash, the algorithm routes traffic to the same target for the duration of the connection.

WAF Support

ALB supports AWS Web Application Firewall to block incoming requests based on specific rules. For example, you can create a rate-limiting rule that allows a maximum of 500 requests from a specific IP address within 5 minutes, after which any additional requests will be blocked. You can create your own rules or use AWS managed rules, such as IP reputation list rules, known bad inputs rules, and more.

NLB doesn’t support AWS WAF.

Authentication

ALB supports the following authentication methods:

• Amazon Cognito, using user pools supported by Amazon Cognito.
• OpenID Connect, using an identity provider that is OpenID Connect compliant.

Authentication is only supported when using the HTTPS protocol for the load balancer listener. When authentication is configured for specific ALB listeners, the load balancer will always authenticate requests before routing traffic to targets. By implementing authentication at the load balancer level, you can focus more on business logic in your target instances.

NLB does not support authentication.

Static IP Address Support

Network Load Balancer supports static IP addresses (IPv4), which you can associate with the load balancer when creating it. This can be useful for various use cases:

• Multi-region deployments: Simplifies cross-region failover and load balancing.
• Third-party integrations: Facilitates integration with third-party services that require IP whitelisting.
• Regulatory requirements: Meets regulatory frameworks that require static IP addresses for auditing and compliance purposes.

ALB doesn’t support static IP addresses.

Latency

When comparing latency between the two load balancers, NLB is the clear winner. However, it's important to note that for most web-based applications, the latency provided by ALB is perfectly sufficient. But if you require extremely low latency for real-time applications, such as gaming, video streaming or financial transactions, NLB is the better choice.

What causes this difference in latency? The main difference lies in how the load balancers are built. ALB operates at the application level (OSI Layer 7), while NLB operates at the network level (OSI Layer 4). This means ALB must inspect and process the content of HTTP/HTTPS requests and additionally decrypt and re-encrypt HTTPS traffic (see TLS Termination). These extra processes increase latency.

AWS PrivateLink Support

NLB supports integration with AWS PrivateLink, enabling private connectivity (without data leaving the AWS network) with other VPCs (consumer VPCs) or third-party services. To enable AWS PrivateLink integration, you need to create a VPC endpoint service pointing to your Network Load Balancer and a VPC interface endpoint in the consumer VPC.

By combining NLB with AWS PrivateLink, you can ensure secure, private, and high-performance access to your services.

ALB doesn’t support AWS PrivateLink.

Zonal Isolation

Network Load Balancer is designed to work within a single availability zone. If one availability zone goes down, NLB will route traffic to other available zones. NLB can be created in only one availability zone, whereas with ALB, a minimum of two availability zones must be enabled to create a load balancer.

Why would you enable NLB in only one availability zone? Certain application architectures may require zonal isolation. For example, single-AZ web applications may need traffic to be distributed only within a specific availability zone to minimize latency and avoid data transfer costs.

Cost

ALB main pricing consists of:

• Hourly usage: $0.0252
• LCU-hour: $0.008

LCU stands for:

• New connections (25 new connections per second)
• Active connections (3000 active connections per minute)
• Processed bytes (1GB per hour)
• Rule evaluations (1000 rule evaluation per second)

NLB main pricing consists of:

• Hourly usage: $0.0252
• NLCU-hour: $0.006

NLCU stands for:

• New connections (25 new connections per second)
• Active connections (3000 active connections per minute)
• Processed bytes (1GB per hour)

When we look at the main pricing for both load balancers, we can see that the NLB will be a little bit cheaper, assuming that we use only one LCU or NLCU per hour:

• ALB monthly price: $23.90
• NLB monthly price: $22.46

When to Use Each?

I would use ALB for almost any web application where HTTP/S traffic needs to be distributed to different targets like EC2 instances, IP addresses, or Lambda functions. Yes, it costs a little bit more, but it’s purpose-built (the word “application” isn’t there by coincidence) to serve various types of web applications (e.g., three-tier web applications, microservices, container-based services, etc.). Even if you initially have simple routing requirements or don’t need the additional security provided by using a Web Application Firewall — which I would recommend enabling — you may benefit later from greater flexibility, such as advanced routing and multiple routing algorithms available for delivering traffic to target instances.

As I mentioned previously, like ALB, NLB also serves a specific purpose. AWS wouldn’t provide two similar load balancers that essentially do the same thing at the same cost. I would use NLB for any application where pure TCP/UDP traffic needs to be load balanced, providing extremely low latency, high performance and supporting unpredicted traffic spikes. A few exceptions for using it with HTTP/S traffic would be if you need to expose your service to other consumer VPCs using AWS PrivateLink or if you need to use static IP addresses for your NLB.