AWS ALB vs NLB Load Balancer Comparison for Exams

Choosing the right AWS load balancer is a critical design decision that directly impacts application performance, cost, and architecture. For certification exams, you must move beyond simply knowing their names to understanding the nuanced trade-offs that dictate when to use an Application Load Balancer (ALB) versus a Network Load Balancer (NLB). Mastering this comparison tests your ability to align technical capabilities with real-world business and technical requirements.

Foundational Architecture: Layer 7 vs. Layer 4

The most fundamental distinction lies in the Open Systems Interconnection (OSI) model layer at which each operates. This single difference dictates nearly all of their capabilities and use cases.

The Application Load Balancer (ALB) operates at Layer 7 (Application Layer). This means it can inspect the content of the HTTP/HTTPS request. Think of it as an intelligent concierge who reads your invitation (the HTTP request) to determine exactly which room (target) your event is in. Because it understands application-level protocols, an ALB can make routing decisions based on the content of the request itself, such as the URL path or host header.

In contrast, the Network Load Balancer (NLB) operates at Layer 4 (Transport Layer). It only sees network-level information: source and destination IP addresses, ports, and protocol (TCP/UDP). Using our analogy, the NLB is a high-speed sorting facility that routes packages based only on the ZIP code and box type on the label, without opening the box. It does not inspect the HTTP content. This focus on the connection layer allows it to handle millions of requests per second with ultra-low latency, often measured in single-digit milliseconds.

Core ALB Capabilities: Content-Based Routing

The ALB's Layer 7 intelligence enables its most powerful feature: advanced request routing. You configure listeners (for ports/protocols) and rules that define how to route incoming requests.

• Path-Based Routing: This allows you to direct traffic to different groups of targets (e.g., different Amazon EC2 instances or AWS Fargate tasks) based on the URL path. For example, requests to myapp.com/api/* can go to a backend API service, while requests to myapp.com/static/* go to a fleet of web servers. This is essential for modern microservices architectures.
• Host-Based Routing: Routing can also be based on the hostname in the Host header. This lets you use a single ALB to route blog.example.com to one target group and app.example.com to another, simplifying DNS management and infrastructure.
• Additional Routing Methods: ALBs can also route based on HTTP headers, methods, query parameters, and source IP addresses, providing immense flexibility for application traffic management.

Furthermore, ALBs natively support WebSocket and HTTP/2 protocols, which are crucial for real-time applications and performance. They also enable sticky sessions (session affinity) using application-controlled cookies, ensuring a user's session stays with a specific target instance when required.

Core NLB Capabilities: Extreme Performance and Static IPs

The NLB is engineered for raw performance, stability, and specific network-centric use cases.

• Ultra-Low Latency & High Throughput: By terminating TCP/UDP connections at the connection level and not parsing HTTP, the NLB introduces minimal processing delay. It can handle sudden, volatile traffic patterns (like millions of requests per second) while maintaining consistent performance, making it ideal for gaming, financial trading, or IoT platforms.
• Static IP Addresses & Elastic IP Support: This is a critical differentiator. When you create an NLB, you can assign an Elastic IP address to each subnet it is deployed in. These IP addresses remain static for the life of the load balancer. Many legacy or third-party applications require firewall whitelisting of specific source IPs; an NLB's static IPs make this possible. An ALB, conversely, uses a dynamic DNS name that resolves to changing IP addresses.
• Preserving Source IP Address: The NLB passes the original client IP address through to the targets without modification (unlike an ALB, which adds the client IP to the X-Forwarded-For header). This is vital for applications where security or logging depends on seeing the true source IP.
• Support for Non-HTTP Protocols: Since it operates at Layer 4, an NLB can load balance any TCP or UDP traffic, including protocols like FTP, SSH, and custom gaming protocols, which an ALB cannot handle.

Critical Operational Features for Comparison

Beyond their primary routing models, several operational features are frequently tested.

• Cross-Zone Load Balancing: This controls whether a load balancer node in one Availability Zone (AZ) can distribute traffic to targets in another AZ.
• In an ALB, this is always enabled at no extra cost. Traffic is evenly distributed across all registered targets in all enabled AZs.
• In an NLB, this is disabled by default. If disabled, each NLB node distributes traffic only to targets in its own AZ. You can enable it, but be aware that with cross-zone load balancing enabled on an NLB, you pay for data processed across AZs. You must know this cost implication for the exam.
• Target Types: Both support EC2 instances, IP addresses, and Application Load Balancers (as a target for NLBs). ALBs uniquely support Lambda functions as a direct target, allowing you to invoke serverless code in response to HTTP requests.

Exam Strategy: How to Choose in a Scenario

Exam questions won't ask for definitions; they will present a scenario. Your decision tree should follow these steps:

1. Does the scenario require routing based on the content of the request (URL path, host header, etc.)? If YES, you must choose an ALB. NLB cannot do this.
2. Does the scenario emphasize extreme performance, static IPs, or non-HTTP protocols (TCP/UDP)? If YES and content-based routing is not needed, choose an NLB.
3. Is it a classic web application (HTTP/HTTPS) with microservices, path-based routing, or Lambda integration? This is the primary domain of the ALB.
4. Is the workload a game server, financial trading platform, IoT data stream, or does it require firewall whitelisting with fixed IPs? This is the primary domain of the NLB.

Hybrid Note: Remember that you can layer these services. A common pattern is to place an NLB in front of an ALB if you need both static IPs and content-based routing, though this adds complexity and cost.

Common Pitfalls

1. Choosing NLB for Path-Based Routing: This is a guaranteed wrong answer. An NLB operates at Layer 4 and has no awareness of URL paths, HTTP headers, or hostnames. Any scenario mentioning "/api" or "route based on the URL" immediately points to ALB.
2. Overlooking the Static IP Requirement: If a question mentions "third-party firewall," "partner system whitelisting," or "requires a fixed IP address," an ALB cannot fulfill this requirement. Its DNS name resolves to dynamic IPs. The NLB with Elastic IPs is the correct solution.
3. Misunderstanding Cross-Zone Load Balancing Cost: Forgetting that enabling cross-zone load balancing on an NLB incurs inter-AZ data transfer costs, while it's free and always on for ALB, can lead to incorrect cost-optimization answers.
4. Using ALB for Non-HTTP Traffic: If the scenario describes load balancing raw TCP, UDP, or a custom protocol, an ALB is not an option. You must select NLB (or the Classic Load Balancer, though NLB is the modern preference).

Summary

• ALB is the content-aware router at Layer 7. Use it for HTTP/HTTPS traffic when you need advanced routing (path-based, host-based), native WebSocket/HTTP/2 support, or Lambda integration.
• NLB is the high-performance, low-latency forwarder at Layer 4. Use it for extreme performance needs, static IP/Elastic IP requirements, preserving source IP, or load balancing any TCP/UDP traffic (including non-HTTP).
• Cross-zone load balancing is always on and free for ALB. For NLB, it's optional and has cost implications for cross-AZ data transfer.
• Exam success hinges on carefully parsing the scenario for keywords that signal the need for content inspection, static IPs, protocol type, or extreme scale.