ALB vs NLB vs GLB: When to Use Which

Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets—EC2 instances, containers, Lambda functions, or IP addresses. ELB is a managed service, meaning AWS handles provisioning, scaling, and availability of the load balancer itself across multiple AZs.

AWS offers three types of load balancers under the ELB umbrella: Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB). Each operates at a different layer of the OSI model and is optimised for different use cases.

The ALB operates at Layer 7 (HTTP/HTTPS) of the OSI model. It can inspect HTTP headers, paths, query strings, hostnames, and cookies to make intelligent routing decisions. ALB is the go-to choice for web applications, microservices, and API endpoints that need content-based routing.

Key ALB features: path-based routing (/api/* to one target group, /static/* to another), host-based routing (different virtual hosts to different backends), HTTP header and query string routing, WebSocket support, and HTTP/2 support. ALB can route to EC2 instances, containers (ECS/EKS), Lambda functions, and IP addresses.

The NLB operates at Layer 4 (TCP/UDP/TLS). It routes packets based on IP protocol data without inspecting application content. NLB is designed for extreme performance: it handles millions of requests per second with ultra-low latency (typically under 100 microseconds).

Key NLB features: static IP addresses per AZ (one Elastic IP per subnet), TLS pass-through (forward encrypted traffic without decrypting), preservation of the client IP address, and support for UDP protocols (e.g., DNS, RADIUS, game servers). NLB cannot perform content-based routing or inspect HTTP headers.

The GWLB operates at Layer 3 (network layer) and is designed exclusively for deploying, scaling, and managing third-party virtual network appliances—firewalls, intrusion detection and prevention systems (IDS/IPS), and deep packet inspection systems.

GWLB uses the GENEVE protocol (port 6081) to encapsulate traffic and send it to your appliance fleet. The appliance inspects the packet and returns it through the same GWLB endpoint. Traffic flows transparently without requiring routing changes in the source VPC. This is the standard pattern for inserting centralised security inspection into AWS VPC traffic flows.

Choose ALB when:

• You need HTTP/HTTPS content-based routing (path, host, header, query string)
• Your backend includes Lambda functions or ECS containers
• You need WebSocket or HTTP/2 connections
• You want to integrate with AWS WAF for web application security at the load balancer layer
• You are building a microservices architecture with many services on different URL paths
• You need SSL/TLS termination at the load balancer

ALB is the correct answer for most web application and REST API load balancing questions on the SAA-C03 exam.

Choose NLB when:

• You need extreme performance (millions of requests per second, sub-millisecond latency)
• You require static IP addresses that partners or firewalls can allowlist
• You need to handle UDP traffic (gaming, DNS, RADIUS, IoT)
• You want TLS pass-through without decrypting at the load balancer (end-to-end encryption to the target)
• You need to preserve the client source IP natively at the TCP level
• You are using AWS PrivateLink to expose services to other VPCs or accounts (NLB is required for PrivateLink)

Choose GWLB when you need to:

• Insert third-party firewall appliances (Palo Alto, Fortinet, Check Point) into your network traffic flow
• Perform deep packet inspection at the VPC level for all inbound or outbound traffic
• Scale a fleet of IDS/IPS appliances horizontally with automatic load balancing

Architecture: Traffic flows from source VPC → GWLB endpoint → appliance VPC (where GWLB distributes traffic across appliance instances) → appliance returns traffic to GWLB → GWLB forwards to original destination. The source and destination are unaware of the inspection in between.

Cross-zone load balancing distributes traffic evenly across all registered targets in all enabled AZs, regardless of which AZ the load balancer node received the request in. Without cross-zone load balancing, each AZ's node only distributes traffic to targets in its own AZ.

ALB has cross-zone load balancing enabled by default at no extra cost. NLB has cross-zone load balancing disabled by default—enabling it incurs inter-AZ data transfer charges. GWLB has cross-zone load balancing disabled by default. Enable cross-zone LB when target counts are uneven across AZs to avoid hot spots.

Quick comparison table for the exam:

• OSI Layer: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protocols: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = all IP protocols via GENEVE
• Static IP: ALB = No (use NLB + ALB pattern); NLB = Yes (1 per AZ); GWLB = N/A
• WAF integration: ALB = Yes; NLB = No; GWLB = No
• Lambda target: ALB = Yes; NLB = No; GWLB = No
• Connection draining: all three support deregistration delay

ALB integrates natively with AWS WAF for regional protection (as opposed to WAF on CloudFront for global edge protection). By attaching a WAF Web ACL to an ALB, you can filter HTTP requests before they reach your application—blocking SQL injection, XSS, known malicious IPs, and rate-abusing clients.

Use ALB + WAF when you want security inspection at the load balancer layer (e.g., to protect APIs that are not served through CloudFront). WAF Web ACLs attached to ALBs must be in the same Region as the ALB and must have REGIONAL scope (unlike CloudFront WAF which requires CLOUDFRONT scope in us-east-1).

AWS PrivateLink uses NLB to expose services in one VPC to consumers in other VPCs or AWS accounts without requiring VPC peering, an internet gateway, or NAT. The service provider creates an NLB in front of their service and creates a VPC Endpoint Service. Consumers create an Interface VPC Endpoint in their VPC that points to the service.

Traffic flows over AWS's private network, never traversing the internet. PrivateLink is the standard pattern for SaaS providers on AWS and for exposing shared services (e.g., a centralised security service) to multiple internal AWS accounts.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: ALB routes at Layer 7 (HTTP) with content-based rules, WAF integration, and Lambda targets, NLB routes at Layer 4 (TCP/UDP) with static IPs and extreme throughput, and GWLB deploys virtual network appliances at Layer 3 using GENEVE. Match the load balancer to the protocol and feature requirements. Next up we explore target groups and health checks.