Listen up, because this is important. If you're running anything on AWS—or hell, even thinking about it—you need to understand load balancing. You can't just throw traffic at a single server and hope for the best. That’s amateur hour. AWS gives you four different types of load balancers, and if you don’t know what they do, you're basically walking into a gunfight with a butter knife.

So let’s break this down in a way that actually makes sense. No corporate jargon, no fluff. Just raw, aggressive knowledge so you can make smart choices.

The Four Load Balancers You Need to Know

AWS doesn’t have just one load balancer. Oh no, that would be too easy. Instead, they give you four, and each of them serves a different purpose. Let’s get into it.

1. Classic Load Balancer (CLB) – The Old Grandpa of Load Balancers

How CLB Works (or Barely Works)

The Classic Load Balancer (CLB) is the dinosaur of AWS. It operates at Layer 4 (Transport Layer) and Layer 7 (Application Layer) and just kind of throws traffic at EC2 instances based on very basic health checks. This was great in 2010. Now? It’s basically on life support.

Here’s what happens when you send traffic to a CLB:

The CLB gets your request and checks which backend EC2 instances are still alive.
It distributes traffic using round-robin (if it’s HTTP) or least outstanding requests (for TCP).
If an instance dies, it stops sending traffic to it.

Why CLB is Garbage (But Sometimes Necessary)

No smart routing. It doesn’t know or care what’s in your HTTP headers.
No WebSockets or HTTP/2. Welcome to 2010, baby.
Slower and more expensive than ALB or NLB.

When Would You Use This?

If you're maintaining an ancient AWS setup.
If you literally have no other option.
If you enjoy suffering.

2. Application Load Balancer (ALB) – The Smart One

How ALB Works

The Application Load Balancer (ALB) is the load balancer you actually want for web apps and APIs. It operates at Layer 7 (Application Layer), which means it actually understands HTTP and can route traffic intelligently. Basically, Sherlock Homes of Load Balancers.

Here’s what happens when a request hits the ALB:

ALB inspects the HTTP request, looking at the URL, headers, and parameters.
It decides which backend should handle it based on pre-set rules.
If the backend is down, it automatically redirects traffic elsewhere.
It supports WebSockets, HTTP/2, and TLS termination, making it a beast for modern web apps.

Why ALB is a No-Brainer

Path-based routing (e.g., /api goes one place, /blog goes another).
Host-based routing (e.g., shop.example.com and api.example.com can go to different places).
Header, Query String-based routing. Want to send mobile users to one server and desktop users to another? Done.
Integrated authentication.

When Should You Use ALB?

Web apps, REST APIs, and microservices.
Kubernetes (EKS) and container-based workloads.
Anytime you need intelligent request routing.

3. Network Load Balancer (NLB) – The Speed Demon

How NLB Works

The Network Load Balancer (NLB) is all about raw speed. It operates at Layer 4 (Transport Layer - TCP/UDP) and doesn’t give a damn about HTTP requests. It just forwards traffic as fast as humanly possible.

Here’s what happens when a request hits the NLB:

It picks a backend server based on flow hash algorithms (which keeps requests from the same client going to the same server).
It forwards the request with single-digit millisecond latency.
It supports millions of connections per second. Yes, millions.

Why NLB is a Beast

Handles TCP, UDP, and TLS connections with almost zero overhead.
Has static IP addresses (unlike ALB, which uses DNS-based routing).
Scales like a monster.

When Should You Use NLB?

Real-time apps like VoIP, gaming, and financial trading.
Any high-performance, low-latency app that needs static IPs.
If you need to handle millions of connections.

4. Gateway Load Balancer (GWLB) – The Security Bouncer

How GWLB Works

The Gateway Load Balancer (GWLB) is a different beast. It doesn’t balance traffic for web apps—it acts as a traffic cop for security appliances like firewalls, IDS, and deep packet inspection tools. It operates at Layer 3 (Network Layer).

Here’s what happens when traffic hits a GWLB:

It forwards traffic to a security appliance (like a firewall or intrusion detection system).
The security appliance inspects the traffic for threats.
If it’s safe, GWLB forwards it to the destination.

Why GWLB is a Game-Changer

Centralized security.
Seamless integration with AWS security tools.
Ensures all traffic is inspected before hitting your applications.

When Should You Use GWLB?

If you need enterprise-grade network security.
If you’re running compliance-heavy workloads.
If you want deep packet inspection before traffic hits your VPC.

Here’s Something Extra about GWLB

Gateway Load Balancer (GLB)—the only one in the load balancing family that actually uses route tables. Why? Because it operates at Layer 3 (network layer) and, unlike its other Load balancer siblings, GLWB needs to read this so this so that it can ensure everything flows smoothly at the network gateway level between cloud, on-prem, and across regions.

Meanwhile, Application Load Balancer (ALB) and Network Load Balancer (NLB)? They don’t bother with route tables because, well, they don’t have to. ALB is living the high life at Layer 7, routing traffic based on content like HTTP headers and SSL session IDs—it’s basically the load balancer equivalent of a food critic, analyzing every detail before making a decision. NLB, down at Layer 4, keeps things more straightforward, handling traffic based on ports and IP addresses, just distributing connections like a robot with a checklist. So they already know how to do their job and not have to bother with reading ‘route table’ manual.

So, while GLB is just trying it’s best, ALB and NLB are just out here vibing!

Which Load Balancer Should You Use?

AWS doesn’t give you four load balancers just for fun. Each one has a specific purpose. Here’s what you should use:

ALB → If you need smart HTTP routing.
NLB → If you need ultra-fast, low-latency TCP/UDP balancing.
GWLB → If you need security inspection before traffic hits your apps.
CLB → If you’re stuck in the past (or migrating away from it).

Load balancing isn’t optional—it’s how you keep your applications from dying under load. Now you know which one to use. No excuses.

A Deep Dive into AWS Load Balancers: CLB, ALB, NLB, and GWLB