Almost every SAA-C03 practice set has a question that describes a workload in careful detail and then asks which load balancer to put in front of it. The wording rarely names a load balancer — it names a requirement: “preserve the client’s source IP,” “route based on the URL path,” “expose a static IP address,” “inspect traffic with a third-party firewall appliance.” Each of those phrases maps to exactly one right answer, and the exam is testing whether you can translate requirement into service without hesitating.
This guide covers the three load balancers you must be able to tell apart for the SAA-C03: the Application Load Balancer (ALB), the Network Load Balancer (NLB), and the Gateway Load Balancer (GWLB). We will map each to the OSI layer it operates at, walk the routing and health-check machinery they share, and — most usefully for the exam — build a table of keyword triggers so that when you read a scenario, the correct choice is already obvious. It builds naturally on the resilient architectures guide, where load balancing sits alongside Auto Scaling and Multi-AZ as a pillar of availability, and the high-performing architectures guide. If you are still planning your prep, start with the SAA-C03 study guide for 2026.
Why Elastic Load Balancing Matters on the SAA-C03
Elastic Load Balancing (ELB) is the front door to resilient, scalable architectures on AWS. A load balancer distributes incoming traffic across multiple targets — EC2 instances, containers, IP addresses, or Lambda functions — in one or more Availability Zones, so no single target is a bottleneck and no single AZ failure takes the application down. That makes ELB a recurring character across at least three of the four SAA-C03 domains: it is core to resilience, central to performance, and it shows up in secure-architecture questions through TLS termination and integration with WAF.
The exam’s real test is discrimination: given a scenario, can you pick the one load balancer whose feature set fits? The four ELB types are the Classic Load Balancer (CLB, legacy — avoid it as an answer unless the question is explicitly about migrating away from it), plus the three modern ones this guide focuses on. Getting the modern three straight is worth a meaningful number of marks.
The Three Load Balancers at a Glance
The single most important distinction is the OSI layer each operates at, because that determines what it can and cannot see about the traffic.
| Feature | Application (ALB) | Network (NLB) | Gateway (GWLB) |
|---|---|---|---|
| OSI layer | Layer 7 (HTTP/HTTPS) | Layer 4 (TCP/UDP/TLS) | Layer 3/4 (IP) |
| Best for | Web apps, microservices, HTTP APIs | Extreme performance, TCP/UDP, static IP | Deploying third-party virtual appliances |
| Routing | Path, host, header, query string | Port/protocol (connection-level) | Transparent bump-in-the-wire |
| Static IP | No (use DNS name; can front with Global Accelerator) | Yes — one Elastic IP per AZ | N/A (uses GENEVE) |
| Preserves source IP | No (adds X-Forwarded-For) | Yes | Yes |
| Targets | Instances, IP, Lambda | Instances, IP, ALB | Appliance instances/IPs |
| Typical use case | Path-based routing to microservices | Millions of requests/sec, gaming, IoT | Inline firewalls, IDS/IPS, DPI |
Read that table as three decisions. Is this HTTP traffic that needs smart, content-aware routing? ALB. Is this raw TCP/UDP that needs extreme throughput, ultra-low latency, or a static IP? NLB. Are you inserting a third-party security appliance into the traffic path? GWLB. Everything below fills in the detail behind those three questions.
Application Load Balancer (ALB): Layer 7 Intelligence
The ALB operates at Layer 7, which means it understands HTTP and HTTPS. Because it can read the request, it can make routing decisions based on the content of that request — something the NLB, which only sees connections, fundamentally cannot do.
ALB routing rules can match on:
- Path —
/api/*goes to one target group,/images/*to another. - Host header —
api.example.comandshop.example.combehind one ALB. - HTTP headers, methods, query strings, and source IP — finer-grained rules for canary releases or A/B routing.
This makes the ALB the natural front end for microservices and container workloads, where a single entry point fans out to many backend services. It integrates tightly with ECS and EKS, supports Lambda as a target (turning an HTTP request into a function invocation), and can terminate TLS so your backends do not have to.
Client → ALB (HTTPS, terminates TLS)
├── path /api/* → target group: api-service
├── path /images/* → target group: image-service
└── default → target group: web-frontendTwo exam-relevant behaviours to remember:
- The ALB does not preserve the client’s source IP at the application layer; it inserts the original IP into the
X-Forwarded-Forheader instead. If a question demands the backend see the real client IP at the network layer, that is a nudge toward NLB. - The ALB integrates with AWS WAF for Layer 7 protection (SQL injection, XSS, rate limiting). “Protect a web app from common web exploits” almost always means ALB + WAF.
Network Load Balancer (NLB): Layer 4 Speed
The NLB operates at Layer 4. It routes by connection — TCP, UDP, and TLS — without inspecting the payload, which is precisely why it is fast. It is built to handle millions of requests per second at ultra-low latency, making it the right tool for high-throughput, latency-sensitive workloads: gaming backends, IoT ingestion, financial tick data, and any non-HTTP protocol.
The NLB’s defining exam triggers:
- Static IP address. The NLB provides one static IP per Availability Zone, and you can assign an Elastic IP to each. When a scenario says “the firewall team needs to allow-list a fixed IP” or “clients hardcode an IP address,” that is NLB, not ALB (whose IPs change).
- Source IP preservation. The NLB preserves the client’s source IP by default, so backends see the real caller without needing
X-Forwarded-For. - Extreme performance / TCP or UDP. Any mention of UDP immediately rules out the ALB (which is HTTP-only) and points to NLB.
Client (fixed source IP visible to backend)
→ NLB (static EIP per AZ, TCP:443 passthrough)
→ target group: high-throughput-backendOne elegant pattern the exam sometimes probes: you can register an ALB as a target of an NLB. That combines the NLB’s static IP and PrivateLink compatibility with the ALB’s Layer 7 routing — useful when you need both a fixed IP and content-based rules.
Gateway Load Balancer (GWLB): Inline Appliances
The GWLB is the specialist of the three, and it exists for one job: deploying, scaling, and managing third-party virtual appliances — firewalls, intrusion detection/prevention systems, and deep-packet-inspection tools — transparently in the traffic path. It operates at Layer 3, acting as a “bump in the wire”: traffic is routed through the appliance fleet for inspection and then continues to its destination, all invisibly to the source and target.
GWLB uses the GENEVE protocol on port 6081 to encapsulate traffic and hand it to the appliances, and it pairs with GWLB endpoints to insert inspection into a VPC’s routing without re-architecting the application.
The exam trigger is unmistakable and narrow: any scenario about inserting a third-party security/inspection appliance inline — “centralise egress inspection through a fleet of firewall appliances,” “scale a partner IDS/IPS solution” — is GWLB. If the question is not about virtual appliances, GWLB is a distractor.
The Shared Machinery: Listeners, Target Groups, Health Checks
All three load balancers share the same core vocabulary, and the exam expects you to use it precisely.
- Listener — checks for connection requests on a configured protocol and port (e.g. HTTPS:443). Listener rules (ALB) decide where matching traffic goes.
- Target group — a logical set of targets (instances, IPs, Lambda, or another ALB) that the load balancer forwards to. Health checks are configured per target group.
- Health check — the load balancer periodically probes each target; only healthy targets receive traffic. An ALB health check can hit a specific HTTP path (
/healthz) and expect a200; an NLB health check is typically a TCP connection test. When a target fails its checks, it is drained out of rotation until it recovers.
Load Balancer
└── Listener (HTTPS:443)
└── Rule → Target Group (/healthz, expect 200)
├── i-0a1b (healthy) ✅ receives traffic
└── i-0c2d (unhealthy) ❌ drained until healthyIf a question describes “some users get errors intermittently” behind a load balancer, suspect a health check that is misconfigured — wrong path, wrong port, or too-aggressive thresholds marking healthy targets as unhealthy.
Two Features That Trip Candidates Up
Cross-Zone Load Balancing
By default, a load balancer node in one AZ distributes traffic only to targets in its own AZ. Cross-zone load balancing lets each node distribute across targets in all enabled AZs, evening out load when AZs have unequal target counts.
The catch the exam loves:
| ALB | NLB | |
|---|---|---|
| Cross-zone default | On (and free) | Off (enable it; inter-AZ data charges apply) |
So “traffic is unevenly distributed across AZs behind an NLB” points to cross-zone load balancing being disabled — the default — and the fix is to enable it.
Sticky Sessions (Session Affinity)
Sticky sessions bind a client to the same target for the duration of a session, so stateful applications keep a user on the server holding their session data. The ALB implements this with a cookie (either an application-generated cookie or an ALB-generated AWSALB duration cookie). If a scenario mentions a shopping cart or user session breaking when requests hit different servers, and the constraint rules out externalising state, sticky sessions on the ALB is the answer. (The architecturally cleaner fix — moving session state to DynamoDB or ElastiCache — is often the better answer when the question asks for a scalable design rather than a quick fix, so read the intent carefully.)
Reading the Question: Keyword-to-Answer Triggers
Under exam time pressure, you want the mapping to be automatic. These triggers resolve the majority of ELB questions:
| Scenario keyword | Right answer |
|---|---|
| ”Route based on URL path / host / header” | ALB |
| ”HTTP/HTTPS web application, microservices” | ALB |
| ”Protect against SQL injection / XSS” | ALB + WAF |
| ”Invoke a Lambda function via HTTP” | ALB (Lambda target) |
| “Static IP address” / “Elastic IP” / “allow-list a fixed IP” | NLB |
| ”Preserve the client source IP” | NLB |
| ”Millions of requests per second / ultra-low latency” | NLB |
| ”UDP” or “TCP passthrough” | NLB |
| ”Expose a service via PrivateLink / VPC endpoint service” | NLB |
| ”Third-party firewall / IDS / IPS appliance inline” | GWLB |
| ”GENEVE / transparent traffic inspection” | GWLB |
| ”Global static anycast IP / route to nearest Region” | Global Accelerator (not an ELB — a common distractor) |
That last row matters: Global Accelerator frequently appears as a wrong-but-tempting option. It provides static anycast IPs and routes users over the AWS backbone to the optimal Region — a global concern — whereas ELB distributes traffic within a Region. If the scenario is multi-Region routing, think Global Accelerator or Route 53; if it is distributing traffic across targets in a Region, think ELB.
A Worked Exam Pattern
A company runs a real-time multiplayer game backend on EC2. Clients connect over UDP, the partner network team requires a fixed set of IP addresses to allow-list, and the backend must see each player’s real source IP for anti-cheat logging. Which load balancer should the architect choose?
Walk the triggers: UDP rules out ALB immediately (HTTP-only). Fixed IP addresses to allow-list points to the NLB’s Elastic IPs. See the real source IP confirms it — the NLB preserves source IP by default. Three independent clues all converge on the same answer: Network Load Balancer. That convergence is the signal you have read the scenario correctly; when two requirements pull toward different services, re-read, because one is usually a distractor phrased to look decisive.
Turn Recognition Into Reflex
Knowing the table is necessary but not sufficient. The exam packs the discriminating detail into a single clause buried in a paragraph of context, and the pressure is in spotting it fast enough to leave time for the harder questions. That speed only comes from repetition against realistically worded scenarios.
That timed discrimination is exactly what the AWS Solutions Architect Associate (SAA-C03) Mock Exam Bundle drills. Its questions mirror the exam’s layered phrasing — where “static IP,” “source IP,” and “path-based routing” sit among plausible wrong choices — with detailed explanations for why each option is right or wrong. Pair it with the resilient architectures guide for how load balancing fits the availability pillar, the VPC concepts guide for the networking context around subnets and security groups, and the SAA-C03 cheat sheet for a fast pre-exam refresh.
Frequently Asked Questions
What is the main difference between an ALB and an NLB?
The ALB operates at Layer 7 (HTTP/HTTPS) and can route based on request content — path, host header, and more — making it ideal for web apps and microservices. The NLB operates at Layer 4 (TCP/UDP/TLS), routing by connection at extreme performance and ultra-low latency. Choose NLB when you need a static IP, source-IP preservation, UDP support, or millions of requests per second; choose ALB when you need content-aware HTTP routing.
When should I use a Gateway Load Balancer?
Use a Gateway Load Balancer only when you are deploying and scaling third-party virtual appliances — firewalls, IDS/IPS, or deep-packet-inspection tools — transparently inline with your traffic. It uses the GENEVE protocol to route traffic through an appliance fleet for inspection. If the scenario is not about inserting a security appliance into the traffic path, GWLB is a distractor.
Which load balancer provides a static IP address?
The Network Load Balancer. It provides one static IP per Availability Zone and lets you assign an Elastic IP to each. The Application Load Balancer does not offer static IPs — you reach it via its DNS name, or front it with AWS Global Accelerator if you need a fixed global anycast IP.
Is cross-zone load balancing on by default?
It depends on the type. For the Application Load Balancer, cross-zone load balancing is enabled by default and free. For the Network Load Balancer, it is disabled by default and enabling it incurs inter-AZ data transfer charges. Uneven distribution across AZs behind an NLB is usually a sign cross-zone is off.
Can an ALB and NLB be used together?
Yes. You can register an Application Load Balancer as a target of a Network Load Balancer. This combines the NLB’s static IP and PrivateLink compatibility with the ALB’s Layer 7, content-based routing — a useful pattern when you need both a fixed IP and path- or host-based rules.
What are sticky sessions and when are they needed?
Sticky sessions (session affinity) bind a client to the same target for the duration of a session, so stateful applications keep a user on the server holding their session data. The ALB implements this with a cookie. They solve broken shopping carts or sessions when requests land on different servers — though externalising session state to DynamoDB or ElastiCache is often the more scalable design the exam prefers when it asks for a long-term architecture.