Application Load Balancer vs Network Load Balancer vs Gateway Load Balancer

Concepts Covered

• Elastic Load Balancing
• Application Load Balancer
• Network Load Balancer
• Gateway Load Balancer
• Listeners
• Target groups
• Layer 7 routing
• Layer 4 forwarding
• Static IP needs
• Virtual appliance insertion

1. Plain-English Mental Model

Elastic Load Balancing distributes incoming traffic across healthy targets. The hard part is choosing the right load balancer type.

An Application Load Balancer, or ALB, understands HTTP and HTTPS. It can route based on request content such as host, path, headers, methods, query strings, and source IP conditions.

A Network Load Balancer, or NLB, works at the transport layer. It is designed for very high performance, low latency, static IP support, and protocols such as TCP, UDP, TLS, and related variants.

A Gateway Load Balancer, or GWLB, is for virtual appliances. It helps insert, scale, and manage fleets of firewalls, intrusion detection systems, inspection tools, and similar appliances.

The short model is:

ALB = HTTP/HTTPS application routing
NLB = Layer 4 high-performance transport routing
GWLB = transparent appliance traffic inspection

2. Why This Service Exists

The service family exists because high availability needs more than one target.

Without a load balancer, users might connect directly to one EC2 instance. That instance becomes a single point of failure and a scaling bottleneck. A load balancer gives clients a stable entry point, runs health checks, and sends traffic only to healthy targets.

Different traffic types need different routing behavior. A web application often needs HTTP routing rules, TLS termination, host-based routing, path-based routing, authentication integration, and target groups per service. That is ALB territory.

A low-latency TCP service, game backend, IoT ingestion endpoint, or service that needs static IP addresses may not need HTTP awareness. It needs fast Layer 4 forwarding. That is NLB territory.

A security architecture may need all traffic to pass through a fleet of third-party inspection appliances without making the app tier know about those appliances. That is GWLB territory.

For SAA-C03, load balancer type is a frequent decision point because exam answers often differ by one phrase: HTTP path routing, static IP, UDP, TLS pass-through, appliance inspection, or host-based routing.

3. The Naive Approach And Where It Breaks

The naive approach is to use "a load balancer" without caring about traffic layer.

If you choose NLB for path-based routing, it cannot inspect the HTTP path the way an ALB can. If you choose ALB for UDP traffic, it is the wrong tool. If you choose ALB or NLB when the requirement is to route traffic through virtual firewalls transparently, you miss the GWLB pattern.

Another naive approach is direct instance exposure:

users -> one public EC2 instance

That breaks on instance failure, deployment, scaling, TLS management, and health checks.

A healthier web architecture is:

users -> ALB -> target groups -> private app instances

A healthier Layer 4 architecture may be:

clients -> NLB -> TCP or UDP targets

An appliance inspection architecture may be:

traffic route -> GWLB endpoint -> GWLB -> appliance fleet -> return path

4. Core Primitives

All modern Elastic Load Balancing designs use a few recurring primitives.

A load balancer is the client-facing entry point. It spans enabled Availability Zones through load balancer nodes.

A listener checks for connection requests on a protocol and port. ALB listeners can use rules to route by HTTP content. NLB listeners forward transport-level traffic. GWLB listens for IP packets and forwards them to appliance targets.

A target group contains registered targets and health check settings. Targets can be instances, IP addresses, Lambda functions for ALB, or appliance instances for GWLB depending on load balancer type.

Health checks decide whether a target should receive traffic.

ALB operates at OSI Layer 7. NLB operates at Layer 4. GWLB operates at Layer 3 and uses GENEVE encapsulation for appliance traffic.

5. Architecture Use Cases

Use ALB for web applications, microservices, host-based routing, path-based routing, redirects, HTTP header routing, HTTPS termination, authentication integration, and routing to Lambda targets.

Use NLB for TCP, UDP, TLS, static IP addresses, preserving client IP in many designs, very high throughput, low latency, and traffic that should not be interpreted as HTTP.

Use GWLB for centralized inspection with virtual appliances: firewalls, intrusion detection and prevention, deep packet inspection, and traffic analysis. GWLB is often paired with Gateway Load Balancer endpoints and route table changes.

In a common three-tier architecture, ALB sits in public subnets and forwards traffic to private app targets. In a private service architecture, an internal NLB can expose a service privately to other VPCs or services. In a security architecture, GWLB endpoints can steer traffic through inspection VPCs.

7. Security Model

ALB supports security groups, which makes it easy to allow internet traffic to the ALB and then allow app traffic only from the ALB security group.

NLB behavior around security groups depends on configuration and generation; the core exam idea is that NLB is closer to transport-level forwarding and is often selected for static IPs, client IP preservation, or non-HTTP protocols.

GWLB security includes route table design, endpoint placement, appliance trust, and the security posture of the appliance vendor. AWS can operate the load balancing mechanism, but customers are responsible for selecting and trusting the appliance software.

TLS design differs by type. ALB is common for HTTP/HTTPS termination. NLB can support TLS listeners and transport-layer patterns. Choose based on where the protocol should be terminated and inspected.

8. Reliability And Resilience

Load balancers improve resilience by routing only to healthy targets and supporting multiple Availability Zones.

For ALB and NLB, enable multiple AZs and place targets across those AZs. Auto Scaling groups can register and deregister instances automatically.

For NLB, be aware of cross-zone load balancing behavior and whether each enabled AZ has healthy targets. DNS may remove an AZ's IP when no healthy targets exist there.

For GWLB, appliance fleet health matters. If inspection appliances fail or route symmetry breaks, traffic can be disrupted. Appliance insertion designs require careful route table planning and testing.

The load balancer is managed, but the architecture around it still needs healthy targets, enough subnet IPs, proper security rules, and monitoring.

9. Performance And Scaling

ALB scales for application traffic and gives rich HTTP routing. Its power is request awareness, not raw Layer 4 minimalism.

NLB is designed for very high performance and can handle millions of requests per second. It is often the answer for low latency, volatile traffic, static IPs, TCP, UDP, or TLS transport patterns.

GWLB scales appliance fleets by distributing traffic across registered appliance targets, but appliance throughput and inspection cost must be included in capacity planning.

Load balancer costs and capacity metrics differ by type. Watch target response time, healthy host count, rejected connections, processed bytes, new connections, active flows, and load balancer capacity units depending on type.

10. Cost Model

Load balancer cost includes hourly usage and usage dimensions such as capacity units, processed bytes, new connections, or rules depending on type.

ALB can reduce infrastructure complexity by serving many hostnames, paths, and services through one load balancer, but listener rules and traffic volume still matter.

NLB can be cost-effective for simple high-throughput transport forwarding, but data volume and cross-zone behavior can matter.

GWLB adds cost for the load balancer path and for the appliance fleet. It is not chosen because it is the cheapest load balancer. It is chosen because the architecture requires transparent inspection or appliance insertion.

Cost questions usually include a stronger requirement than "cheap." Use the requirement to choose the type first, then optimize.

12. SAA-C03 Exam Signals

"Path-based routing" or "host-based routing" points to ALB.

"HTTP headers, query strings, redirects, or authentication" points to ALB.

"TCP, UDP, static IP, or very high performance Layer 4" points to NLB.

"Preserve client IP" often points to NLB, depending on target type and configuration.

"Firewall appliances, IDS/IPS, deep packet inspection, transparent traffic inspection" points to GWLB.

"Route traffic through appliances across VPC boundaries" points to GWLB endpoints and PrivateLink-style patterns.

13. Common Exam Traps

Do not choose ALB for UDP.

Do not choose NLB for HTTP path-based routing.

Do not choose GWLB for normal web app load balancing. It is for appliance fleets.

Do not expose application instances directly when a load balancer can be the public entry point.

Do not forget target health checks. A load balancer can only route correctly when target health is configured correctly.

Do not ignore subnet and AZ placement. A load balancer spanning multiple AZs still needs healthy targets in the design.

15. Related Topics

Review Public vs Private Subnets before load balancer placement questions. Public ALBs and private targets are a recurring pattern.

Review Security Groups vs NACLs because load balancer traffic must pass both route and security controls.

Official AWS references:

• Application Load Balancers
• Network Load Balancers
• Gateway Load Balancers