ALB vs. NLB: The AWS Load Balancer Decision the SAA-C03 Tests Every Time

Here is a scenario you will see on the SAA-C03:

A financial services company exposes a REST API and a WebSocket notification service from the same domain. The compliance team requires that partner banks whitelist the load balancer by IP address — the IP must never change. A solutions architect is redesigning the architecture. What should they recommend?

Four answer choices: ALB with path-based routing. NLB with TCP listeners. NLB in front of ALB. CloudFront with an ALB origin.

The correct answer is NLB in front of ALB — but only if you understand why any single-service answer fails. ALB alone cannot provide a static IP. NLB alone cannot do path-based routing. GWLB solves a completely different problem. And CloudFront adds a CDN, which the scenario never asked for.

The application load balancer vs network load balancer decision is one of the SAA-C03's most reliably recurring networking topics. AWS Elastic Load Balancing gives you three distinct services — ALB, NLB, and GWLB — each operating at a different OSI layer and solving a different architectural problem. This guide gives you the mental model, the decision tree, and the exact exam signal words for all three.

---

Three AWS Load Balancers, Three OSI Layers

AWS retired the classic CLB (Classic Load Balancer) for new deployments in 2022. Today, Elastic Load Balancing offers three current-generation services:

• Application Load Balancer (ALB) — Layer 7 (HTTP/HTTPS). Understands application-layer content.
• Network Load Balancer (NLB) — Layer 4 (TCP/UDP/TLS). Routes on IP and port; never inspects payloads.
• Gateway Load Balancer (GWLB) — Layer 3 (Network). Transparently routes traffic through virtual appliances.

They are not interchangeable. The exam exploits every difference between them, so you need a precise model for each — not a vague sense that "ALB is for web apps."

---

Application Load Balancer vs Network Load Balancer: Core Architecture

Application Load Balancer (ALB)

ALB operates at Layer 7. It reads every HTTP request — the URL path, the Host header, other headers, query string parameters, and HTTP method — and applies listener rules to decide which target group receives the request.

What ALB uniquely provides:

• Content-based routing. A single ALB can route /api/* to a microservices target group, /images/* to an S3-backed target group, and everything else to a monolith — all on port 443 from one DNS name. NLB cannot do this.
• Host-based routing. api.example.com and www.example.com can share one ALB and route to completely separate fleets.
• HTTP/2, gRPC, and WebSocket. ALB terminates HTTP/2 and gRPC and can forward gRPC to containers. WebSocket connections are upgraded transparently.
• AWS WAF integration. ALB is the only Elastic Load Balancer that integrates natively with AWS WAF for Layer 7 protection against SQL injection, XSS, and rate limiting.
• Lambda targets. ALB can invoke a Lambda function directly as a target group — the only load balancer that supports Lambda.
• User authentication. ALB listener rules support OIDC and Amazon Cognito authentication before forwarding, offloading auth from application code.
• Redirect and fixed-response actions. HTTP-to-HTTPS redirects or a custom 503 maintenance page are implemented directly in ALB listener rules without any backend instance.

What ALB does not provide:

ALB is identified only by its DNS name — there is no static IP. AWS manages a pool of IP addresses behind the scenes that can change as ALB scales. If a firewall rule or a partner network requires a fixed IP to whitelist, ALB alone cannot satisfy that requirement.

ALB also terminates TLS at the load balancer. The connection your EC2 instance or container sees originates from ALB's private IP, not the client. The real client IP is carried in the X-Forwarded-For header — readable by application code, but not visible at the network layer.

---

Network Load Balancer (NLB)

NLB operates at Layer 4. It never looks inside a TCP or UDP payload. It routes based on the destination IP and port, selecting a target from its target group using a flow hash algorithm. Once a connection is established, all packets for that flow go to the same target (connection-level persistence — not cookie-based like ALB's sticky sessions).

What NLB uniquely provides:

• Static Elastic IP per Availability Zone. Each NLB node in an AZ can be assigned a static or Elastic IP address. Partners, firewalls, and DNS allow-lists can reference a stable IP that never changes. This is the single most tested NLB capability on the SAA-C03.
• Source IP preservation. Because NLB does not terminate TCP connections (it proxies at Layer 4), the target instance sees the real client IP directly in the socket connection — no header parsing required.
• UDP support. ALB does not support UDP. NLB supports UDP listeners for protocols like DNS, syslog, RADIUS, and gaming traffic.
• TLS offloading at Layer 4. NLB can terminate TLS without understanding HTTP — useful for protocols that run over TLS but aren't HTTP (custom binary protocols, database proxies).
• Extreme throughput. NLB is designed for millions of connections per second with sub-millisecond latency additions. It adds virtually no processing overhead because it never parses payloads.
• ALB as a target. You can register an ALB as a target in an NLB target group. This is the pattern for getting a static IP and path-based routing: NLB receives on the static IP, forwards to ALB, ALB routes by path. Both are provisioned and managed independently.

What NLB does not provide:

NLB has no concept of HTTP paths, headers, or query strings — routing is purely IP+port. AWS WAF cannot be attached to NLB. Lambda cannot be a target for NLB. Cookie-based sticky sessions do not apply (NLB uses flow-hash persistence).

Cross-zone load balancing is disabled by default on NLB (unlike ALB, where it is enabled by default). This matters on the exam: enabling cross-zone on NLB incurs inter-AZ data transfer charges; on ALB it does not.

---

Gateway Load Balancer (GWLB)

GWLB operates at Layer 3 using the GENEVE protocol (port 6081). It is not a "load balancer" in the user-facing traffic sense — it is infrastructure for transparently routing packets through a fleet of third-party virtual network appliances before they reach your application.

GWLB architecture: Traffic enters your VPC, is intercepted by a GWLB endpoint (via a VPC Endpoint Service), forwarded to the appliance fleet in a separate inspection VPC, inspected by the appliance (a firewall, IDS/IPS, deep packet inspection tool), and returned through the same GWLB endpoint to its original destination. The source and destination IPs are preserved throughout — the appliance sees the real traffic exactly as it would on a physical network tap.

The exam signal for GWLB: Any scenario that mentions:

• "Route all traffic through a third-party firewall before it reaches the application"
• "Deploy Palo Alto / Fortinet / Check Point appliances in a centralized security VPC"
• "Centralized inspection architecture" / "security inspection VPC"
• "Transparent inline traffic inspection"

None of ALB, NLB, or traditional routing can do this transparently at scale. GWLB is the purpose-built answer.

---

The AWS Load Balancer Decision Tree

Work through this in order when a load balancer scenario appears:

1. Does the workload use HTTP/HTTPS, and does routing need to differentiate by URL path, hostname, header, or query string? → YES: ALB. This is the core ALB use case. No other load balancer has content-aware routing.

2. Does the scenario require a static IP address, UDP, or the client IP preserved at the socket level? → YES: NLB. These are NLB-exclusive capabilities. If you also need HTTP path routing, deploy NLB in front of ALB.

3. Does the scenario mention third-party virtual firewalls, IDS/IPS, or transparent traffic inspection through network appliances? → YES: GWLB. This is GWLB's only purpose — no other load balancer provides transparent bump-in-the-wire appliance insertion.

4. None of the above, TCP workload, maximum throughput priority? → Default to NLB. For TCP workloads where HTTP features are irrelevant and static IP is not required, NLB is still the right answer over ALB — less overhead, lower latency.

---

Exam Scenario Drills

Scenario 1: An IoT platform collects sensor readings from 50,000 devices using a proprietary binary protocol over TCP. Devices are programmed with a fixed IP address that cannot be changed. Which load balancing solution should the architect recommend?

→ NLB. Key signals: non-HTTP protocol (binary over TCP), fixed IP address requirement, no routing logic needed. ALB only supports HTTP/HTTPS — it cannot handle a proprietary binary TCP protocol. The static IP requirement rules ALB out even if the protocol were HTTP.

Scenario 2: A company is deploying a microservices application with three services: an authentication service at /auth, a product API at /products, and a static asset service at /static. All three must be reachable on a single domain and port 443. Which service handles the routing?

→ ALB. Path-based routing is the defining ALB capability. One ALB with three listener rules routes each path prefix to a separate target group. NLB cannot inspect URL paths — a different port or different DNS name would be required for each service, defeating the requirement.

Scenario 3: A bank requires that all outbound traffic from their on-premises data center to their AWS VPC passes through a fleet of third-party next-generation firewalls running in a dedicated inspection VPC. The firewalls must scale automatically and be managed by the security team independently of the application teams.

→ GWLB. The firewalls are third-party virtual appliances in a dedicated VPC. Traffic must be transparently inspected without source/destination NAT. GWLB is the only AWS service that enables this centralized security insertion architecture at scale.

Scenario 4: A SaaS provider needs to expose an HTTPS API to enterprise customers. Customers require IP addresses to whitelist in their outbound firewall policies. The API also uses path-based routing to version its endpoints (/v1/ and /v2/). What architecture should the solutions architect recommend?

→ NLB in front of ALB. NLB provides the static Elastic IP per AZ for whitelisting. ALB behind it handles path-based versioning. This is a legitimate two-tier ELB architecture and a common SAA-C03 scenario pattern.

Scenario 5: A gaming company runs a multiplayer server that communicates over UDP. During peak hours, 500,000 UDP packets per second arrive from players worldwide. Which load balancer should the architect configure?

→ NLB. ALB does not support UDP at all — this alone makes it the wrong answer regardless of performance. NLB supports UDP listeners, handles millions of packets per second, and preserves source IPs (important for UDP-based game servers that need to track client sessions by IP).

---

The Load Balancer Signal Word Map

Keep this reference in memory — it reduces any load balancer question to pattern recognition:

The scenario contains "path-based routing," "host-based routing," "/api/*," "WebSocket," "gRPC," "Lambda target," "WAF," or "user authentication at the load balancer" → ALB

The scenario contains "static IP," "Elastic IP," "UDP," "preserve source IP," "binary TCP protocol," "non-HTTP protocol," "firewall whitelist by IP," or "millions of connections per second" → NLB

The scenario contains "third-party firewall," "IDS/IPS," "deep packet inspection," "network appliance," "inspection VPC," "transparent inline inspection," "Palo Alto / Fortinet / Check Point" → GWLB

The scenario says NLB and ALB features are both needed (static IP + path routing) → NLB in front of ALB

---

The Cross-Zone Loading Balancing Exam Trap

Cross-zone load balancing affects how traffic distributes across Availability Zones when target counts are uneven:

• ALB: Cross-zone is enabled by default. Traffic distributes evenly across all registered targets in all AZs regardless of how many AZ nodes the load balancer has. No extra data transfer charge.
• NLB: Cross-zone is disabled by default. Without it, each NLB node in an AZ distributes traffic only to targets in that AZ. Enabling it incurs inter-AZ data transfer charges.

The exam scenario for this: "An NLB has 2 targets in us-east-1a and 10 targets in us-east-1b. Targets in us-east-1a are handling 50% of the traffic despite having fewer resources. What is the likely cause?" — Cross-zone load balancing is disabled, so each AZ node handles 50% of incoming traffic regardless of target count. The fix is enabling cross-zone load balancing.

---

Security Groups and Load Balancers

ALB supports security groups — you attach a security group directly to the ALB and control which source IPs can reach it. This integrates naturally with the VPC security model covered in the Security Groups vs. NACLs guide.

NLB historically did not support security groups on the load balancer itself (traffic was controlled via target instance security groups, using the NLB's IP ranges). As of November 2023, NLB now supports security groups when it is internet-facing or internal — a change that appears in recent SAA-C03 question pools. The exam still tests the traditional flow where target security groups must allow the NLB's IP ranges.

GWLB endpoints are controlled through VPC endpoint policies, not security groups on the GWLB itself.

---

Practice Makes the Signal Words Automatic

Load balancer questions on the SAA-C03 follow reliable patterns — once you've seen 10–15 of them, the signal words map to answers automatically. The free 10-question diagnostic takes 10 minutes and shows exactly which networking sub-domains need work before exam day. If load balancing is a gap, the SAA-C03 practice question set has a full Elastic Load Balancing module with scenario-based questions at exam difficulty.

The DVA-C02 tests ALB in the context of Lambda targets and Cognito-based authentication at the load balancer level — both uniquely ALB capabilities not available on NLB.

---

Summary: Application Load Balancer vs Network Load Balancer

The decision rule is one sentence: choose ALB when the routing decision depends on what's inside the HTTP request; choose NLB when you need a static IP, UDP, source IP preservation, or raw TCP throughput at scale.

GWLB is its own domain — it appears only in security architecture questions about third-party appliances and never competes with ALB or NLB in a routing decision.

Get the three-way split right, and load balancer questions on the SAA-C03 stop being traps and start being free points.