AWS has a few different load balancers, and picking the right one can feel like a game of 20 questions.
Let’s see what happens when we actually send traffic through them. Here’s a simple setup: two EC2 instances behind an Application Load Balancer (ALB), and we’re hitting it with HTTP requests.
# On one client machine
while true; do
curl -s http://your-alb-dns-name.us-east-1.elb.amazonaws.com/ | grep "Instance ID:"
sleep 0.1
done
If you run this, you’ll see the output from grep rapidly alternating between the instance IDs of your two EC2 machines. That’s the ALB doing its job, distributing incoming HTTP requests at the application layer. It looks at the request itself – the hostname, the path, even headers – and decides where to send it. This is powerful because it lets you route traffic based on what the request is asking for. For example, you could send requests to /api/* to one set of servers and /images/* to another, all through the same ALB.
The Application Load Balancer (ALB) operates at Layer 7 (the application layer) of the OSI model. This means it can inspect the content of the HTTP/HTTPS request. It’s ideal for microservices architectures, web applications, and situations where you need advanced routing based on request details like URL path, hostname, HTTP headers, and query parameters. ALBs can also handle WebSockets and HTTP/2, and they offer features like sticky sessions, SSL termination, and integration with AWS WAF for security.
The Network Load Balancer (NLB), on the other hand, operates at Layer 4 (the transport layer). It forwards TCP/UDP/TLS traffic directly to your instances based on IP protocol data. NLBs are designed for extreme performance, low latency, and high throughput. They can handle millions of requests per second while maintaining very low latency. Unlike ALBs, NLBs don’t inspect the content of the traffic; they simply forward the connection to a target. This makes them faster and more efficient for raw network traffic. NLBs also preserve the client’s source IP address, which can be crucial for certain applications.
The Classic Load Balancer (CLB) is the original AWS load balancer. It can operate at both Layer 4 (TCP/SSL) and Layer 7 (HTTP/HTTPS). While it offers some of the routing capabilities of an ALB (like host-based and path-based routing), it’s generally less performant and lacks many of the advanced features of ALBs and NLBs. AWS recommends migrating from CLBs to ALBs or NLBs for new applications due to their superior features, performance, and cost-effectiveness. CLBs are considered legacy and are being phased out.
When you’re deciding, think about what you’re load balancing. If it’s raw TCP or UDP traffic where you need maximum speed and don’t care about the request content, NLB is your go-to. If you’re running web applications, APIs, or microservices and need intelligent routing based on HTTP details, ALB is the clear winner. CLB is generally for older applications that haven’t been migrated yet.
The one thing most people don’t realize is that NLBs can route based on destination IP address and port. When you create an NLB, you define listeners for specific ports (e.g., TCP 80, TCP 443). Traffic arriving at the NLB’s IP address on one of these ports is then forwarded to a target group. The NLB itself gets a static IP address (or can use Elastic IPs), and this IP remains constant even if you update the underlying targets. This static IP is a key feature for certain use cases, like migrating existing applications that expect a fixed IP endpoint.
Once you’ve mastered routing, you’ll want to look into how AWS Certificate Manager integrates with these load balancers for SSL/TLS termination.