Elastic Load Balancer ELB Explained: ALB vs NLB vs Gateway Load Balancer

Elastic Load Balancer is AWS managed traffic distribution for applications that need scale, fault tolerance, and clean separation between clients and back-end targets. The hard part is not whether to use ELB. The hard part is picking the right type: Application Load Balancer, Network Load Balancer, or Gateway Load Balancer.

AWS documentation lists four ELB types: Application Load Balancer, Network Load Balancer, Gateway Load Balancer, and Classic Load Balancer. For new designs, ignore Classic Load Balancer unless you are keeping an older system alive. ALB, NLB, and GWLB are the modern choices.

What Elastic Load Balancer Does

Elastic Load Balancing spreads incoming traffic across registered targets such as Amazon EC2 instances, containers, IP addresses, and Lambda functions in supported cases. It can send traffic across multiple Availability Zones, run health checks, and stop routing requests to unhealthy targets.

That sounds simple. In production it matters a lot. A failed container, a bad deployment, or one overloaded instance should not take down your public endpoint. ELB gives you a managed control point for that traffic instead of asking every application team to build its own failover logic.

ALB vs NLB vs Gateway Load Balancer: The Short Version

Here is the practical rule. Use ALB for HTTP-aware routing. Use NLB for fast transport-level traffic. Use GWLB when you need to insert network security appliances into the path.

Application Load Balancer: Best for HTTP Applications

Application Load Balancer works at Layer 7, so it understands application traffic. It can inspect HTTP hostnames, paths, headers, methods, and other request attributes before deciding where to send traffic.

Choose ALB when you need:

• Host-based routing, such as api.example.com and app.example.com
• Path-based routing, such as /api, /checkout, and /admin
• HTTP to HTTPS redirection
• WebSocket support
• HTTP/2 and gRPC support
• Integration with ECS, EKS, and microservice target groups
• Authentication at the load balancer using supported identity providers

For most websites and public APIs, ALB is the right default. It is not the fastest option in raw packet terms, but it hands you routing features that save application code and infrastructure work.

Where ALB Shines

Picture a single domain serving three services: a React front end, a payment API, and an admin service. With ALB listener rules you can route / to the front end, /api/payments to one target group, and /admin to another. Each service deploys independently while you keep one public entry point.

ALB also fits Kubernetes Ingress on Amazon EKS. The AWS Load Balancer Controller commonly provisions an ALB for Ingress resources, which matches the Layer 7 nature of HTTP routing.

ALB Gotchas You Should Know

ALB has defaults that catch teams during real deployments. The idle timeout default is 60 seconds. If you run long-lived WebSocket connections, streaming responses, or slow gRPC calls, that timeout can produce confusing 504 responses unless you tune the client, target, and ALB settings together.

Another common headache is a 502 from ALB while your app logs look clean. In ALB access logs you may see elb_status_code=502 and target_status_code=-. That usually means the target closed the connection, returned a malformed HTTP response, or failed TLS negotiation before ALB received a valid response. This is exactly the kind of operational detail that AWS certification candidates and working engineers both need to understand.

Network Load Balancer: Best for TCP, UDP, and Low Latency

Network Load Balancer works at Layer 4. It does not parse HTTP paths or headers. It routes connections using transport-level information such as IP address, port, and protocol.

Choose NLB when you need:

• TCP, UDP, or TLS traffic that is not standard HTTP routing
• Very high throughput with low latency
• Static IP addresses or Elastic IPs for allowlisting
• TLS pass-through to targets
• Client IP preservation for supported target configurations
• Lift-and-shift migrations where applications expect direct network connections

AWS describes NLB as capable of handling millions of requests per second while holding very low latency. That does not mean every app needs it. If your app needs routing by URL path, NLB is the wrong tool. Use ALB.

Where NLB Fits Best

NLB suits multiplayer game servers, MQTT-style IoT backends, custom TCP protocols, real-time trading systems, and legacy applications moving to AWS with minimal code change.

It also helps when external partners require fixed IP addresses for firewall rules. An internet-facing NLB can use one static IP per enabled Availability Zone, and you can associate Elastic IPs when needed. ALB does not offer that same static IP model directly.

NLB Trade-Offs

NLB is fast because it does less at the application layer. That is the trade. You do not get path-based routing, rich HTTP rules, or request-aware authentication at the load balancer. Your application, service mesh, or another layer has to handle those concerns.

Cost can also favor NLB at very high scale because it performs simpler packet and connection distribution. But do not pick it just because it sounds cheaper. If you rebuild ALB features inside your app, the operational cost comes back quickly.

Gateway Load Balancer: Best for Security Appliances

Gateway Load Balancer is different. It is not a normal app front door. GWLB is built to deploy, scale, and manage fleets of virtual network appliances such as firewalls, intrusion detection systems, intrusion prevention systems, and deep packet inspection tools.

GWLB acts as a transparent gateway and sends traffic to appliances using GENEVE encapsulation. AWS uses GENEVE on UDP port 6081 between the Gateway Load Balancer and appliance targets. The appliance can inspect traffic, allow it, modify it, or drop it depending on its function.

Choose GWLB when you need:

• Inline firewall inspection across VPCs
• Centralized security inspection in a multi-account AWS environment
• Scalable third-party appliances from vendors such as Palo Alto Networks, Fortinet, or Check Point
• Traffic steering without changing client and server application code

Where GWLB Is the Right Choice

Suppose your company runs many application VPCs but wants all north-south or east-west traffic inspected through a central security VPC. GWLB inserts inspection appliances without forcing every application team to redesign its networking. Security teams get centralized control. App teams keep shipping.

Do not use GWLB for a normal website. It does not replace ALB. It does not give you HTTP routing. It solves a network security insertion problem.

Health Checks and Resilience

All modern ELB types support health checks, but the meaning shifts by load balancer type. ALB can run HTTP and HTTPS checks against specific paths, such as /health. NLB can perform TCP, HTTP, or HTTPS health checks depending on configuration. GWLB checks appliance health before sending flows to those appliance targets.

Deploy across at least two Availability Zones for production. Single-zone designs are fragile, and the small savings rarely justify the risk. Review deregistration delay too. For ALB target groups the default deregistration delay is 300 seconds. During blue-green deployments that five-minute drain period can make old tasks look like they receive traffic longer than a new engineer expects.

How ELB Works with Containers and Kubernetes

For Amazon EKS, a common pattern holds up:

• Ingress resources map well to ALB because Ingress is usually about HTTP host and path routing.
• Service type LoadBalancer often maps to NLB when you need a stable Layer 4 endpoint.

For Amazon ECS, ALB gets used for services behind HTTP routes, especially when each service has its own target group. NLB is better when the container exposes a non-HTTP protocol or when static IP requirements drive the design.

If you are building your AWS skills through Global Tech Council, connect this topic with cloud architecture, DevOps, Kubernetes, and cybersecurity learning paths. Load balancing questions often test whether you understand layers, protocols, health checks, and failure behavior rather than whether you can recite service names.

ALB, NLB, or GWLB: Decision Checklist

1. Is the traffic HTTP, HTTPS, gRPC, or WebSocket? Start with ALB.
2. Do you need routing by hostname, path, header, or method? Use ALB.
3. Is the traffic raw TCP or UDP? Use NLB.
4. Do you need static IPs for partner allowlists? Use NLB.
5. Do you need TLS pass-through to the target? NLB is usually the better fit.
6. Are you inserting firewalls or IDS/IPS appliances? Use GWLB.
7. Are you starting a new design with Classic Load Balancer? Do not. Pick ALB or NLB unless you have a specific legacy constraint.

Cost and API Gateway Context

ALB and NLB both carry baseline hourly charges plus usage-based dimensions. They make sense for services that run continuously. API Gateway, though not part of ELB, is often compared with ALB for APIs. It adds features such as throttling, request transformation, API keys, and caching, but it can cost more per request at sustained high volume.

My practical view: use API Gateway when you need API management features. Use ALB when you need web routing for always-on services. Use NLB when the protocol or latency requirement makes Layer 7 processing unnecessary.

What You Should Do Next

If you are designing a web application on AWS, start with ALB and prove it cannot meet your requirements before moving lower in the stack. If you are exposing TCP or UDP services, use NLB and keep the application-layer logic in your service. If your project involves inspection appliances, bring the security and network teams into the design early and evaluate GWLB.

For hands-on practice, build a small VPC with two Availability Zones, deploy one ALB with path-based routing, one NLB for a TCP echo service, then review the access logs and target health states. Map those observations to your AWS and cloud architecture study plan with Global Tech Council.