Cargando...
Cargando...
Pick the right load balancer the first time — every time — with this definitive AWS comparison guide
Layer, protocol, and use case determine which load balancer wins
| Feature | ALB Layer 7 HTTP/HTTPS intelligent routing | NLB Layer 4 ultra-low latency TCP/UDP | CLB Legacy Layer 4/7 EC2-Classic relic | Gateway LB Layer 3 inline virtual appliance traffic |
|---|---|---|---|---|
OSI Layer This is the single most tested differentiator. Know the layer for each LB cold. | Layer 7 (Application) | Layer 4 (Transport) | Layer 4 & 7 (hybrid, limited) | Layer 3 (Network) + Layer 4 |
Protocols Supported GENEVE protocol on port 6081 is unique to GWLB — a frequent exam detail. gRPC support is ALB-only. | HTTP, HTTPS, gRPC, WebSocket | TCP, UDP, TLS, TCP_UDP | TCP, SSL/TLS, HTTP, HTTPS | GENEVE (port 6081), IP |
Primary Use Case For DOP-C02 context: ALB is the default answer for modern web workloads; GWLB for security appliance insertion. | Microservices, containers, web apps, path/host-based routing | Real-time gaming, IoT, financial trading, static IP requirements | Legacy EC2-Classic applications (do not use for new workloads) | Inline traffic inspection via 3rd-party virtual appliances (IDS/IPS, firewalls, DPI) |
Target Types ALB is the ONLY load balancer that can target Lambda functions directly. NLB can front an ALB (a common architecture pattern). | Instance, IP, Lambda, ALB (via NLB) | Instance, IP, ALB | Instance only | Instance, IP (virtual appliances) |
Static / Elastic IP Support Static IP requirement = NLB. This is a critical exam trigger. Whitelisting IPs for firewall rules? Use NLB. | No static IP (DNS only); workaround: put NLB in front | Yes — supports Elastic IPs per AZ | No static IP (DNS only) | No static IP (transparent pass-through) |
SSL/TLS Termination GWLB never terminates TLS; the virtual appliance behind it handles all decryption if needed. | Yes — terminates at LB, re-encrypts optionally to targets | Yes — TLS termination supported (or pass-through) | Yes — basic SSL termination | No — transparent pass-through only |
WebSocket Support | Yes — natively supported | Yes — as TCP pass-through | Limited / not recommended | N/A |
gRPC Support gRPC = ALB. Only ALB understands gRPC at the application layer. | Yes — native gRPC routing | Pass-through only (TCP) | No | No |
Host-Based Routing | Yes — route by Host header (e.g., api.example.com vs www.example.com) | No | No | No |
Path-Based Routing Content-based routing (path, host, header, query string, HTTP method) is exclusively ALB. | Yes — route by URL path (e.g., /api/* vs /images/*) | No | No | No |
Query String / Header Routing | Yes — route by HTTP headers, query strings, HTTP methods, source IP | No | No | No |
Sticky Sessions (Session Affinity) ALB sticky sessions use cookies; NLB/GWLB use IP-based hashing. Different mechanisms — different exam questions. | Yes — application-based (custom cookie) or duration-based cookies | Yes — source IP affinity (5-tuple or 3-tuple hash) | Yes — duration-based sticky sessions | Yes — 5-tuple or 3-tuple hash |
Health Checks | HTTP, HTTPS health checks (can inspect response body/codes) | TCP, HTTP, HTTPS health checks | TCP, HTTP, HTTPS health checks | TCP, HTTP health checks on virtual appliances |
Cross-Zone Load Balancing ALB = cross-zone ON by default, free. NLB = OFF by default, costs money when enabled. Classic exam trap! | Enabled by default (no charge) | Disabled by default (can enable; charges apply for inter-AZ data) | Disabled by default (can enable; no charge when enabled) | Disabled by default (can enable; charges apply) |
Preserve Source IP Need to see client IP at the application layer with ALB? Read X-Forwarded-For header. NLB preserves it natively. | No — uses X-Forwarded-For header; target sees LB IP | Yes — source IP preserved natively (instance targets); uses Proxy Protocol v2 for IP targets | No — uses X-Forwarded-For (HTTP) or Proxy Protocol (TCP) | Yes — transparent; original packet preserved |
AWS WAF Integration WAF = ALB only among the four LB types. For DOP-C02 security scenarios, this is critical. | Yes — native WAF integration | No | No | No (uses 3rd-party appliances instead) |
AWS Shield Advanced Integration | Yes | Yes | Yes | Yes |
Connection Draining / Deregistration Delay | Yes — configurable deregistration delay (default 300s) | Yes — configurable deregistration delay | Yes — connection draining | Yes — configurable |
Slow Start Mode Slow start is ALB-only — useful for warming up application servers. | Yes — gradually ramp up traffic to new targets | No | No | No |
Lambda as Target ALB → Lambda is a serverless architecture pattern. Very commonly tested. | Yes — only LB that supports Lambda targets | No | No | No |
ECS / EKS / Fargate Integration | Preferred — dynamic port mapping, path routing per service | Supported | Legacy support only | Not applicable |
PrivateLink / VPC Endpoint Service PrivateLink requires NLB as the backing load balancer. This is a critical exam fact. | No (cannot be endpoint service directly) | Yes — NLB is required to expose services via AWS PrivateLink | No | Yes — GWLB endpoints used for appliance insertion |
Performance / Latency Extreme performance / millions of requests per second = NLB. | Milliseconds (Layer 7 processing overhead) | Sub-millisecond (Layer 4, no HTTP parsing) | Milliseconds (older, less efficient) | Near-transparent (bump-in-the-wire) |
Pricing Model CLB pricing is simpler (per GB). ALB/NLB/GWLB use capacity unit pricing. CLB is often more expensive at scale. | Hourly rate + LCU (Load Balancer Capacity Units) based on: new connections, active connections, processed bytes, rule evaluations | Hourly rate + NLCU (Network Load Balancer Capacity Units) based on: new TCP flows, active TCP flows, processed bytes, TLS connections | Hourly rate + data processed per GB (simpler, older model) | Hourly rate + GLCU (Gateway Load Balancer Capacity Units) based on: new connections, active connections, processed bytes |
Idle Timeout NLB TCP idle timeout of 350 seconds is fixed and cannot be changed — a common exam trap. | Configurable (default 60 seconds) | TCP: 350 seconds (fixed for established connections); UDP: 120 seconds | Configurable (default 60 seconds) | Varies by appliance |
HTTP/2 Support | Yes — HTTP/2 between client and ALB; HTTP/1.1 to targets by default | Pass-through only | No | N/A |
Redirect Rules HTTP→HTTPS redirect without EC2 instances = ALB listener rule. No need for a separate server. | Yes — HTTP to HTTPS redirects, URL redirects natively | No | No | No |
Fixed Response (Return custom HTTP response) | Yes — return 200/404/503 etc. directly from listener rule | No | No | No |
Weighted Target Groups Weighted target groups enable blue/green and canary deployments at the LB level — relevant for DOP-C02 deployment strategies. | Yes — weighted routing across target groups (blue/green, canary) | Yes | No | No |
Multi-Value Header Support | Yes — multiple values for same query string key forwarded | N/A | No | N/A |
VPC Peering / On-Premises Targets | Yes — IP targets can be in peered VPCs or on-premises (via DX/VPN) | Yes — IP targets support on-premises via DX/VPN | No — EC2 instances in same VPC only | Yes — virtual appliances can be in peered VPCs |
Dual-Stack / IPv6 | Yes — dualstack DNS, IPv4 and IPv6 | Yes — dualstack DNS, IPv4 and IPv6 | Limited | IPv4 only |
Access Logs | Yes — detailed HTTP request logs to S3 | Yes — TLS listener logs to S3 | Yes — access logs to S3 | Yes — flow logs via CloudWatch |
CloudWatch Metrics SurgeQueueLength and SpilloverCount are CLB-specific metrics — if you see these, the answer involves CLB. | Rich HTTP metrics: RequestCount, TargetResponseTime, HTTPCode_ELB_5XX, etc. | TCP metrics: ActiveFlowCount, NewFlowCount, ProcessedBytes, TCP_ELB_Reset_Count | Basic metrics: RequestCount, Latency, SurgeQueueLength, SpilloverCount | ActiveFlowCount, ProcessedBytes, HealthyHostCount |
Deletion Protection | Yes — enable to prevent accidental deletion | Yes | No | Yes |
AWS Global Accelerator Compatible Global Accelerator works with ALB and NLB endpoints, not CLB or GWLB. | Yes | Yes | No | No |
Recommended for New Workloads? AWS officially recommends against using CLB for new applications. If a question asks for 'modern' or 'best practice', eliminate CLB. | Yes — preferred for HTTP/HTTPS workloads | Yes — preferred for TCP/UDP/TLS workloads | No — legacy, AWS recommends migrating away | Yes — for virtual appliance insertion use cases |
Summary
Use ALB for all HTTP/HTTPS and microservices workloads needing content-based routing, WAF, or Lambda targets. Use NLB when you need static IPs, ultra-low latency, TCP/UDP protocols, or PrivateLink. Use Gateway LB exclusively for inserting third-party virtual security appliances (firewalls, IDS/IPS) inline into your traffic path. Avoid CLB entirely for new architectures — it exists only for legacy EC2-Classic compatibility.
🎯 Decision Tree
Need HTTP/HTTPS routing, WAF, Lambda targets, or path/host routing? → ALB | Need static IP, PrivateLink, TCP/UDP, sub-millisecond latency, or millions of req/sec? → NLB | Need to insert a 3rd-party firewall/IDS/IPS appliance inline using GENEVE? → Gateway LB | Running legacy EC2-Classic workloads (don't start new ones here)? → CLB | Need NLB + HTTP routing? → NLB in front of ALB (NLB→ALB chaining)
LAYER IS EVERYTHING: ALB=Layer 7 (HTTP/HTTPS/gRPC), NLB=Layer 4 (TCP/UDP/TLS), CLB=Layer 4+7 (legacy), GWLB=Layer 3+4 (GENEVE/IP). Every routing capability, protocol support, and use case flows from this. If a question mentions 'path-based routing', 'host-based routing', 'HTTP headers', or 'WAF' → ALB. If it mentions 'TCP', 'UDP', 'static IP', 'PrivateLink', or 'millions of connections' → NLB.
STATIC IP + PRIVATELINK = NLB ALWAYS: Two of the most commonly tested NLB scenarios are (1) needing a static/Elastic IP per AZ for IP whitelisting, and (2) exposing a service via AWS PrivateLink. Both require NLB — no other load balancer supports these. If you see 'whitelist IP', 'firewall rules require fixed IP', or 'VPC endpoint service' in a question, the answer is NLB.
GWLB = BUMP IN THE WIRE FOR SECURITY APPLIANCES: Gateway Load Balancer's entire purpose is to transparently insert third-party virtual appliances (Palo Alto, Fortinet, CheckPoint firewalls; Suricata IDS/IPS) into traffic flows using GENEVE encapsulation on port 6081. Traffic goes: Source → GWLB Endpoint → GWLB → Appliance → GWLB → GWLB Endpoint → Destination. The appliance inspects/filters traffic transparently. If a question mentions 'third-party firewall', 'IDS/IPS', 'inline inspection', or 'GENEVE' → GWLB.
CROSS-ZONE LOAD BALANCING DEFAULTS AND COSTS: ALB has cross-zone enabled by default at no extra charge. NLB has it disabled by default, and enabling it incurs inter-AZ data transfer charges. CLB has it disabled by default but enabling it is free. GWLB has it disabled by default with charges when enabled. This combination of default state + cost is a frequent exam question, especially in cost-optimization scenarios.
DOP-C02 DEPLOYMENT STRATEGIES WITH LBs: For blue/green and canary deployments, ALB and NLB weighted target groups allow you to shift traffic percentages between target groups (e.g., 90% to blue, 10% to green) without DNS changes. ALB listener rules with weighted forwarding are the AWS-native way to implement canary releases at the load balancer layer. This is directly relevant to DOP-C02's deployment domain.
NLB TCP IDLE TIMEOUT IS FIXED AT 350 SECONDS: Unlike ALB where you can configure the idle timeout, NLB's TCP idle timeout is hardcoded at 350 seconds. You cannot change it. UDP timeout is 120 seconds. Applications that expect shorter or longer TCP idle timeouts may behave unexpectedly behind NLB. ALB default is 60 seconds but is configurable. This difference appears in troubleshooting questions.
CLB IS LEGACY — ELIMINATE IT FOR NEW WORKLOADS: AWS officially recommends migrating from CLB to ALB or NLB. CLB cannot target IP addresses or Lambda, doesn't support path/host-based routing, lacks weighted target groups, and has no WAF integration. In any question asking for 'modern best practice', 'cost-effective solution', or 'new architecture', CLB should be eliminated first. The only reason CLB appears as a correct answer is in questions specifically about EC2-Classic or legacy migrations.
The #1 exam trap is confusing when to use ALB vs NLB for 'performance' scenarios. Candidates assume ALB is always the answer for web traffic and NLB is only for non-HTTP workloads. In reality, NLB is the correct answer whenever you need: (a) a static/Elastic IP address, (b) PrivateLink endpoint service, (c) sub-millisecond latency at massive scale, or (d) source IP preservation at the network level — even if the underlying traffic is HTTP. A common question pattern: 'Your application needs to be exposed via AWS PrivateLink AND handle HTTPS traffic' — the answer is NLB (with TLS termination or pass-through), NOT ALB, because PrivateLink requires NLB as the backing service.
CertAI Tutor · DOP-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns