ALB vs NLB vs Gateway Load Balancer: When the SAA-C03 Picks Each

AWS gives you four load balancers, and the Solutions Architect – Associate exam almost always frames the question the same way: here is a workload, here are its constraints, which load balancer do you put in front of it? The answer is decided by which network layer the load balancer operates at and one or two specific requirements in the scenario — a static IP, a path-based route, a fleet of firewall appliances.

This guide covers the Application Load Balancer (ALB), the Network Load Balancer (NLB), the Gateway Load Balancer (GWLB), and the legacy Classic Load Balancer (CLB): the layer each works at, the cue that picks it, and the traps the exam sets.

The one-line identity of each

• ALB — Layer 7 (HTTP). Routes on the content of the request: hostname, URL path, headers, method, query string. Can redirect, return fixed responses, authenticate users, and send traffic to Lambda. The default choice for web apps and APIs.
• NLB — Layer 4 (TCP/UDP). Extreme throughput, ultra-low latency, a static IP per Availability Zone, and it preserves the client's real source IP. The choice when performance, a fixed IP, a non-HTTP protocol, or PrivateLink is the requirement.
• GWLB — Layer 3 (IP packets). Transparently sends all traffic through a fleet of third-party network appliances — firewalls, intrusion detection, deep packet inspection — then on to its destination. The choice when the requirement is "inspect the traffic with a security appliance."
• CLB — the legacy option. Layer 4 and basic Layer 7, no content-based routing, no target groups. If a scenario mentions an existing CLB, the answer is usually "migrate to ALB or NLB."

The decision cues

ALB in depth

The Application Load Balancer operates on HTTP and HTTPS. You define listeners with rules, evaluated by priority, that match on host, path, HTTP header, method, query string, or source IP, and forward to a target group.

Exam-relevant properties:

• Target types: EC2 instances, IP addresses, or Lambda functions.
• Content-based routing: send example.com/api/* to one target group and example.com/static/* to another; send admin.example.com somewhere else entirely.
• Actions beyond forwarding: HTTP-to-HTTPS redirects, fixed responses, and authentication via Cognito or any OIDC identity provider before the request reaches your app.
• TLS: terminates HTTPS, supports Server Name Indication (SNI) so one ALB can serve many domains each with its own certificate.
• AWS WAF attaches to an ALB for L7 filtering. Sticky sessions use a load-balancer-generated cookie.
• Source IP: an ALB does not preserve the client IP. The backend sees the ALB's IP; the real client IP is in the X-Forwarded-For header.
• No static IP. An ALB is reachable only by its DNS name. Cross-zone load balancing is on by default at no extra cost.

NLB in depth

The Network Load Balancer operates at Layer 4 — TCP, UDP, and TLS. It is built for scale and speed: it handles millions of requests per second, adds almost no latency, and is designed for volatile, spiky traffic.

Exam-relevant properties:

• Static IP per Availability Zone. Each AZ subnet gets one, and you can assign your own Elastic IP. This is why NLB is the answer whenever a scenario needs a fixed IP to allowlist elsewhere.
• Preserves the client source IP. The backend sees the real client address directly — no header parsing needed.
• Target types: EC2 instances, IP addresses, or an Application Load Balancer (you can put an NLB in front of an ALB — the pattern for "I need a static IP and Layer 7 routing").
• TLS termination is optional; you can also pass encrypted traffic straight through.
• PrivateLink: an NLB (or GWLB) is required to publish a VPC endpoint service to other accounts.
• Security groups are now supported on NLBs; older study material that says "NLB has no security group" predates that change.
• Cross-zone load balancing is off by default on an NLB, and enabling it means cross-AZ data transfer is billed.

GWLB in depth

The Gateway Load Balancer solves one problem: running a fleet of third-party virtual appliances — next-gen firewalls, IDS/IPS, packet inspection — without building the plumbing yourself.

How it works:

• Traffic is directed (via route tables) to a Gateway Load Balancer endpoint in your VPC.
• The endpoint forwards packets to the GWLB, which distributes them across the appliance fleet using the GENEVE protocol on port 6081.
• The appliance inspects the traffic and returns it; GWLB sends it on to its original destination. Source and destination addresses are preserved — it is a transparent "bump in the wire."

Exam tell: "insert a fleet of third-party firewall appliances," "inspect all traffic entering and leaving the VPC," "scale a partner security appliance" → GWLB.

The traps the exam sets

"I need a static IP and path-based routing"

An ALB has no static IP; an NLB has no Layer 7 routing. The answer is NLB in front of an ALB, or AWS Global Accelerator in front of the ALB (Global Accelerator gives you two static anycast IPs).

"Preserve the client's IP address"

ALB puts it in X-Forwarded-For; the backend must read the header. NLB preserves it natively. If the scenario says the application cannot be modified to parse headers, that rules out ALB.

"Millions of requests per second" or "sudden, massive spikes"

NLB is designed for this and needs no pre-warming. ALB scales too but a scenario that stresses raw connection volume and latency is pointing at NLB.

"Authenticate users before they reach the app"

Only the ALB can do this natively, via a Cognito or OIDC authentication action on the listener rule.

"Route traffic through a firewall appliance"

Not a security group, not a NACL, not an ALB rule — GWLB. This is the only load balancer built to insert inline appliances.

Worked scenarios

1. An API needs /orders and /inventory served by different microservice fleets behind one endpoint. → ALB with path-based routing rules.
2. A multiplayer game server backend uses UDP and must handle huge, sudden player spikes with minimal latency. → NLB.
3. A partner will only call your service if you give them a fixed IP to allowlist, and your app does HTTP routing. → NLB in front of an ALB (static IP at the edge, Layer 7 routing behind it).
4. All inbound and outbound VPC traffic must pass through a fleet of Palo Alto firewalls. → GWLB with Gateway Load Balancer endpoints and route-table redirection.
5. A SaaS provider wants to expose its application privately to customer AWS accounts. → an NLB-backed VPC endpoint service (AWS PrivateLink).
6. Users must sign in with the company identity provider before reaching an internal dashboard. → ALB with an OIDC authentication action.
7. A legacy app runs behind a Classic Load Balancer and the team wants host-based routing. → migrate to an ALB.

Locking it in

Load balancing sits inside the "Design High-Performing Architectures" and "Design Secure Architectures" domains, and the questions are rarely about definitions — they are about reading a scenario and matching constraints to the right service. That skill only develops by doing scenario questions and reviewing the ones you miss: did you pick ALB when "static IP" made it NLB? Did you forget that GWLB even exists?

CloudDojo's practice tests are built around these scenario patterns, and the AI Coach groups your misses by service and domain so you can see whether load balancing is a genuine weak spot. Start with the free readiness check to find out where you stand, then work through our 6-week SAA-C03 study plan.

Key takeaways

• ALB — Layer 7. Content-based routing, redirects, authentication, WAF, Lambda targets. No static IP; does not preserve source IP.
• NLB — Layer 4. Static IP per AZ, preserves source IP, extreme performance, TCP/UDP, required for PrivateLink endpoint services.
• GWLB — Layer 3. Transparently routes traffic through a fleet of third-party security appliances via GENEVE.
• CLB — legacy. If you see it in a scenario, the answer is usually to migrate to ALB or NLB.