Published by Sascha Neumeier
Last updated on August 29, 2025
•
17 minute read
The good old days. One box to rule them all. One box to find them. One box to bring all your visitors and in the darkness bind them. Back when your entire website was served from one server, everything was simple.
Fast-forward to modern web applications that typically run on more than one EC2 instance, container, or Lambda function.
This architectural complexity creates one big question: How can you evenly distribute incoming traffic across all these resources?
Enter the world of AWS load balancers. These highly available servers direct the client requests to the most healthy compute resource that can serve the request.
ELB and ALB, which one to choose? I have thrown in NLB as well, for some good measure. It's time to make sense of it all and answer the most important questions about AWS load balancers:
- What's the differences between AWS load balancers?
- Which AWS load balancer is right for your use case?
- How to set up AWS load balancer monitoring?
Don't worry, I won't waste your time with marketing speak. I'm an AWS load balancer enthusiast. I have dealt with my share of load balancer gremlins, so read on for real-world advice on choosing and using load balancers.
Bonus: Monitor all AWS services with PRTG Network Monitor, a unified network monitoring platform. Get a 30-day free trial and start monitoring your AWS environment today!
AWS load balancers, by the name of them
Before we dig into the AWS load balancer comparison, there is one annoying naming issue that has caused quite a bit of confusion among users. The term "ELB" in itself actually refers to the AWS Elastic Load Balancing service that comprises three load balancer types:
Classic Load Balancer (CLB): Was formerly referred to as the "Elastic Load Balancer". This is the original load balancer that AWS launched back in 2009
Application Load Balancer (ALB): This is AWS's new load balancer that's designed for HTTP/HTTPS traffic. It was introduced in 2016
Network Load Balancer (NLB): The other new load balancer, designed for TCP/UDP traffic. NLB was introduced in 2017
So, when most people say "ELB vs ALB", they really mean Classic Load Balancer vs Application Load Balancer.
Got it. Okay, let's start the comparison with Classic Load Balancer vs ALB.
Classic Load Balancer vs Application Load Balancer: Comparing ALB vs ELB
AWS's original load balancer, the Classic Load Balancer, is first-generation load balancing as AWS knows it. The CLB operates at Layer 4 and Layer 7 of the OSI model. Essentially, CLB is a reliable box that does its job well. But if you're looking for some advanced features that could make your life easier, the CLB is not your friend.
The Application Load Balancer, on the other hand, sits at the application layer (Layer 7), as it's name suggests. ALB is a next-generation load balancer specifically designed to handle the needs of modern web applications.
Comparing AWS Classic Load Balancer vs ALB
Now let's compare AWS load balancers in terms of their capabilities and features. These are the things where ALB clearly outclasses the Classic Load Balancer:
Content-based routing. The ALB can route requests to different target groups based on URL path, host header, or query parameters. With this, you can run multiple microservices behind the ALB and use it to send /api requests to one target group and /admin to another. CLB can't do content-based routing – it sends the same request to all EC2 instances in a single target group
Support for containers and Lambda. While the Classic Load Balancer can only work with EC2 instances, the ALB can route traffic to EC2 instances, containers in ECS, and Lambda functions. With the ALB, you can use a single load balancer to serve an architecture that mixes different compute types. The CLB simply doesn't have this capability
WebSocket and HTTP/2 support. ALB natively supports WebSocket connections as well as the latest HTTP/2 protocol, whereas CLB only supports WebSockets
Sophisticated request routing capabilities. The ALB lets you setup advanced routing rules based on HTTP headers, methods, query parameters, and source IP address. The CLB has none of these capabilities
Better health checks. The ALB allows you to have more detailed health checks than the CLB. For example, you can check for a specific path with the ALB, as well as expect specific status code, or even search for the presence of a specific string in the response body
Stay with me, the good stuff is coming next. Let's also talk about the Network Load Balancer, because there are cases when you want to use NLB instead of ALB.
Network Load Balancer vs Application Load Balancer
We have talked about the NLB before and how it compares with ALB and CLB. Here's the NLB in a nutshell: unlike the Application and Classic Load Balancers, the Network Load Balancer operates at the transport layer (Layer 4) of the OSI model.
You need NLB in cases when you have super high performance and low latency requirements or your application uses protocols other than HTTP/HTTPS.
When to use Network Load Balancer
When exactly should you choose the NLB over the ALB? Here are a few use cases:
Need super high performance, low latency. The NLB can handle millions of requests per second, while also providing extremely low latency consistently
Using protocols other than HTTP/HTTPS. If your application traffic uses TCP, UDP, or TLS without HTTP, the NLB is the only option
Need static IP addresses. The NLB provides fixed IP addresses that you can use in DNS records or IP allow-lists. ALB assigns ephemeral IPs to its load balancers, which can change occasionally
Preserving the client's source IP address is important. With NLB, you'll always get the client's real IP address in the traffic forwarded to your backend servers
AWS load balancers in the real world: Scenarios and examples
Enough theory, now let's see the three load balancer types in action. I'll provide a few real-world scenarios with practical examples of the load balancer type that I would recommend in each case:
Scenario 1: Microservices architecture
Let's say you have built a modern application with a microservices architecture. This means that your application is made up of several smaller services, each doing its own job.
Some of these services are containers running in ECS, others are traditional EC2 instances, and you've even decided to go serverless and use Lambda for some parts of the app.
➡️ Best choice: Application Load Balancer
The ALB is perfect in this case due to its path-based routing. With ALB, you can easily route traffic to different microservices based on the URL patterns. For example, you could route /users/* to your user service, /products/* to your product service, and /checkout/* to your payment service – all from a single load balancer. It will also happily serve all your compute types – EC2, ECS, and Lambda.
Scenario 2: Database or game server with high-performance needs
In this scenario, you're either running a high-performance database server or a multiplayer game server.
In both cases, you need the NLB's performance and the UDP protocol support, as your application needs to be able to handle a lot of incoming traffic, and it needs to be able to do so with extremely low latency. Also, the load can spike up rapidly with multiplayer games.
➡️ Best choice: Network Load Balancer
The NLB will easily meet your demands here. It is not only capable of handling millions of requests per second, but it can also provide extremely consistent ultra-low latency performance.
Plus, it has UDP protocol support, which ALB doesn't have and you need for many gaming and voice applications.
Scenario 3: Traditional web application that needs SSL termination
You have a simple traditional application running on several EC2 instances. You just want to load balance the traffic to these instances and you don't want your application servers to perform SSL decryption at the instance level, so you want to terminate SSL at the load balancer level.
➡️ Best choice: Classic Load Balancer or Application Load Balancer
In this case, both ALB and CLB would do. They have all the features you need for such a simple use case. The ALB is the preferred choice, of course, as it has better health checks and a few other modern features. I would only choose CLB over ALB if you want to save a few bucks, as it's a bit cheaper.
Monitoring AWS load balancers
By the way, don't forget to set up monitoring for your load balancers. If you are using any AWS load balancer, you should at least configure CloudWatch alerts so you know when your load balancer becomes unhealthy.
PRTG Network Monitor comes with ready-to-use AWS cloud monitoring that covers all the AWS load balancer types, giving you a good starting point. But that is just the beginning, and you will be happy to know that PRTG can monitor your entire AWS environment – from the EC2 instances all the way down to load balancers, RDS database, EBS volumes, and more.
Get the whole picture and understand what is happening to your applications end-to-end. Configure PRTG to monitor your load balancer performance as well as your backend application servers, database instances, queues, etc. Correlate performance between load balancers and other AWS resources so you can easily spot the culprit when performance issues occur.
Learn more about monitoring your AWS cloud with PRTG here or jump straight to a free 30-day trial of PRTG Network Monitor. Remember, if you use PRTG Free trial, you will get all the features forever, including all the AWS cloud monitoring features and license to monitor up to 100 sensors.
FAQ around AWS load balancers
Can I convert from CLB to ALB?
No. It's not possible to convert an existing Classic Load Balancer to the Application Load Balancer. You need to create a new ALB and then migrate your traffic to it. The good news is, AWS provides a migration wizard that can assist you with the process. That said, be warned, the migration process is not entirely trivial, especially if you are doing it with a production workload.
In order to migrate, you need to create target groups (instead of a simple pool of instances like with CLB), register your instances with them, update DNS records, maybe create a new security group and more. There's also the actual traffic migration to take care of, i.e. shifting the traffic from CLB to ALB.
While this is not really a one-click operation, if you take your time, there should not be any serious blockers. There are also some online CLB-to-ALB migration guides available if you want to do it yourself.
How do AWS load balancers affect my application security posture?
In some obvious ways, and some not so obvious ways. One of the most important security features for most load balancers is SSL termination. This can be a huge benefit in terms of performance because it offloads the CPU load from your application servers.
On the other hand, ALB offers additional features, such as integration with AWS WAF, Cognito, and the ability to add custom authentication with your own OpenID Connect provider.
The security concern that's often overlooked is that load balancers can be an interesting focal point for a more advanced attack. For example, ALB access logs can contain sensitive information that can be helpful in a security analysis, but they also need to be properly secured. This also applies to security groups and NACLs – you need to ensure your load balancer is not left open to the world. A load balancer misconfiguration can accidentally make your internal services accessible from the Internet.
What's the relationship between AWS Auto Scaling and load balancers?
If you use Auto Scaling with your EC2 instances, people sometimes think that these two AWS services must be closely integrated in some way. You know, like live in the same city, wear matching socks and fight crime in their spare time.
The truth is, Auto Scaling and AWS load balancers are completely different services that just happen to be used in the same scenarios (mostly). The integration between them happens via target groups (ALB and NLB) or directly (CLB).
AWS Auto Scaling simply adjusts the number of EC2 instances that are active based on load and a pre-defined scaling policy. The AWS load balancer takes care of distributing the traffic to those active instances.
Auto Scaling automatically registers new EC2 instances in the load balancer when they are launched. When an instance is terminated, it's automatically removed from the load balancer. Easy peasy.
The subtle thing is that you can get much more granular by customizing the lifecycle hooks in Auto Scaling. For example, you can delay new instances from receiving traffic until they have "warmed up", or you can progressively drain connections from terminating instances before they are actually terminated.
These may seem like small things, but they can actually have a major impact on your application's reliability when it's dynamically scaling.
Ready to take control of your AWS infrastructure monitoring?
TRY PRTG FREE FOR 30 DAYS and see how a unified approach to cloud monitoring can help you transform the way you operate in the cloud.
You there!
