Summary

The AWS undefined website content differentiates between Application Load Balancer (ALB) and Network Load Balancer (NLB), highlighting their distinct features, use cases, and the advantages of each for routing traffic in modern application architectures.

Abstract

AWS offers two types of load balancers, the Application Load Balancer (ALB) and the Network Load Balancer (NLB), each designed for different scenarios. ALB operates at Layer 7 of the OSI model, handling HTTP/HTTPS traffic with advanced routing capabilities such as host and path-based routing, and supports HTTP/2 and gRPC. It is ideal for applications requiring content-based routing and is context-aware, ensuring application availability. In contrast, NLB operates at Layer 4, handling TCP/UDP/TLS traffic with static IP addresses and is suitable for high-performance, low-latency applications. It is context-less, focusing solely on network-layer information. Both load balancers integrate with AWS services like EC2 Container Service and are essential for modern, dynamic port configurations, particularly in containerized environments. The choice between ALB and NLB depends on the specific needs of an application, such as the type of network traffic, encryption requirements, and routing complexity.

Opinions

The article suggests that ALB is a feature-rich solution for modern applications, especially those leveraging microservices and containers, due to its ability to route traffic based on content and application behavior.
NLB is portrayed as the preferred choice for scenarios demanding extreme performance and static IP addresses, such as SaaS services exposed via PrivateLink VPC Endpoint.
The integration of ALB and NLB with AWS services like EC2 Container Service is emphasized as a significant advantage for managing load balancers in sync with container lifecycle events.
The author implies that ALB provides a more robust health check mechanism by verifying content and application behavior, which is crucial for maintaining application availability.
The recent update allowing NLB to support security groups is noted as an important enhancement for network security configurations.
The article conveys a clear preference for ALB in scenarios requiring advanced routing and application-level decision-making, while NLB is recommended for situations prioritizing performance and static IP addresses.
The use of ALB for applications that need to differentiate between multiple services on the same host (virtual hosts) is highlighted as a key benefit, ensuring that traffic is routed to available and healthy applications only.

AWS — Difference between Application load balancer (ALB) and Network load balancer (NLB)

Comparisons: ALB vs NLB in AWS — Application load balancer vs Network load balancer.

Awesome Cloud — Application load balancer (ALB) and Network load balancer (NLB)

TL;DR:

ALB — Layer 7 (HTTP/HTTPS traffic), Flexible. NLB — Layer 4 (TLS/TCP/UDP traffic), Static IPs. CLB — Layer 4/7 (HTTP/TCP/SSL traffic), Legacy, Avoid.

Both Application Load Balancer and Network Load Balancer are designed from the ground up for the modern paradigm of dynamic port configurations as commonly seen in containerized deployments. Picking which load balancer is right for you will depend on the specific needs of your application, such as whether or not network traffic is HTTP, whether you need end-to-end SSL/TLS encryption, and whether or not you want host and path-based traffic routing.

If you are deploying docker containers and using a load balancer to send network traffic to them EC2 Container Service provides tight integration with ALB and NLB so you can keep your load balancers in sync as you start, update, and stop containers across your fleet.

Read AWS Elastic Load Balancer (ELB) Overview

Application Load Balancer (ALB)

This is the distribution of requests based on multiple variables, from the network layer to the application layer. It is context-aware and can direct requests based on any single variable as easily as it can a combination of variables. Applications are load balanced based on their peculiar behavior and not solely on server (operating system or virtualization layer) information.

This is a feature filled Layer-7 load balancer, HTTP, and HTTPS listeners only. Provides the ability to route HTTP and HTTPS traffic based upon rules, host-based or path based. Like an NLB, each Target can be on different ports. Even supports HTTP/2. Configurable range of health check status codes (CLB only supports 200 OK for HTTP health checks).

Protocols: HTTP, HTTPS

Protocol versions: HTTP/1.1, HTTP/2, gRPC

Target Types: Instance, IP, Lambda

With ALB, it is a requirement that you enable at least two or more Availability Zones.

Network Load Balancer (NLB)

This is the distribution of traffic based on network variables, such as IP address and destination ports. It is Layer 4 (TCP) and below and is not designed to take into consideration anything at the application layer such as content type, cookie data, custom headers, user location, or the application behavior. It is context-less, caring only about the network-layer information contained within the packets it is directing this way and that.

This is a TCP Load Balancer only that does some NAT magic at the VPC level. It uses EIPs, so it has a static endpoint unlike ALB and CLBs (by default). Each Target can be on different ports.

Protocols: TLS, TCP, UDP, TCP_UDP

Protocol versions: TLS, TCP, UDP, TCP_UDP

Target Types: Instance, IP, ALB

With NLB, Elastic Load Balancing creates a network interface for each Availability Zone that you enable.

Key Differences: ALB vs NLB

OSI Layer: Application Load Balancer (as the name implies) works at the Application Layer (Layer 7 of the OSI model, Request level). Network Load Balancer works at the Transport layer (Layer 4 of the OSI model, Connection level).
Routing: NLB just forward requests whereas ALB examines the contents of the HTTP request header to determine where to route the request. So, an ALB support advanced request (content-based) routing.
Static IP: ALB doesn’t provide support for static IP addresses whereas NLB provides support for zonal static IP addresses (in each AZ).
PrivateLink (Endpoint services): NLB provides support for PrivateLink with VPC Endpoints Service integration whereas ALB doesn’t support PrivateLink. Only NLB can be used directly as PrivateLink. Elastic Load Balancing now supports forwarding traffic directly from NLB to ALB. With this feature, you can now use AWS PrivateLink and expose static IP addresses for applications built on ALB.
AWS Load Balancer Controller for Kubernetes: controller provisions ALB when you create a Kubernetes Ingress and NLB when you create a Kubernetes service of type LoadBalancer.
Application availability: NLB cannot assure the availability of the application. This is because it bases its decisions solely on a network and TCP-layer variables and has no awareness of the application at all. Generally, NLB determines availability based on the ability of a server to respond to ICMP ping or to correctly complete the three-way TCP handshake. ALB goes much deeper and is capable of determining availability based on not only a successful HTTP GET of a particular page but also the verification that the content is as was expected based on the input parameters.
When considering the deployment of multiple applications on the same host sharing IP addresses (virtual hosts), NLB will not differentiate between Application-A and Application-B when checking availability (indeed it cannot unless ports are different) but ALB will differentiate between two applications by examining the application layer data available to it. This difference means that NLB may end up sending requests to an application that has crashed or is offline, but ALB will never make that same mistake.
Security: ALB and NLB, both support Security Groups. (Updates on Aug 10, 2023, Network Load Balancer now supports security groups)

Use Cases

Choose ALB if:

Application Load Balancer is best suited for load balancing of HTTP and HTTPS traffic and provides advanced request routing targeted at the delivery of modern application architectures, including microservices and containers.
Applications need advanced routing (host-based, URL-based, query string based).
Run multiple services (microservices) behind a single load balancer.

Choose NLB if:

Network Load Balancer is best suited for load balancing of TCP traffic where extreme performance is required. It is capable of handling millions of requests per second while maintaining ultra-low latencies, and it is optimized to handle sudden and volatile traffic patterns.
You want to share/expose your services (e.g. SaaS services) to other consumers in different VPCs using PrivateLink VPC Endpoint.
You need a static IP address that can be used by applications as the front-end IP of the load balancer.

View more from Awesome Cloud

Happy Clouding!!!