Load balancers are a ubiquitous sight in a cloud environment. As soon as you need high availability, you are likely to meet a load balancer in front of at least two instances of your app.
AWS offers three types of load balancers, adapted for various scenarios: Elastic Load Balancers, Application Load Balancers, and Network Load Balancers.
Common Features
Let’s start by taking a look at what is common for all three types of load balancers.
Obviously, all AWS load balancers distribute incoming requests to a number of targets, which can be either EC2 instances or Docker containers. They all implement health checks, which are used to detect unhealthy instances. They are all highly available and elastic (in AWS parlance: They scale up and down within a few minutes according to workload).
TLS termination is a feature available for all three as well, and they can all be either internet-facing or internal. Finally, ELB, ALB, and NLB all export useful metrics to CloudWatch and can log pertinent information to CloudWatch Logs.
Something to keep in mind is that If you anticipate a sudden spike in traffic (sale, testing, etc.), you might want to contact AWS support to “pre-warm” your load balancer. Otherwise, it might take too long for the load balancer to adapt to the surge of incoming traffic.
Let’s take a detailed look at each, starting with the first (and oldest) type of load balancer: the Classic Load Balancer, or ELB.
Classic Load Balancer
This load balancer is usually abbreviated ELB for Elastic Load Balancer, as this was its name when it was first introduced in 2009 and was the only type of load balancer available. It can be thought of as an Nginx or HAProxy instance if that makes it easier for you to understand.
ELB works at both layer 4 (TCP) and 7 (HTTP) and is the only load balancer that works in EC2-Classic, in case you have a very old AWS account. Also, it’s the only load balancer that supports application-defined sticky session cookies; in contrast, ALB uses its own cookies, and you have no control over that.
At layer 7, ELB can terminate TLS traffic. It can also re-encrypt the traffic to the targets as long as they provide an SSL certificate (a self-signed certificate is fine, BTW). This provides end-to-end encryption, which is a usual requirement in many compliance programs. Optionally, ELB can be configured to verify the TLS certificate provided by the target for extra security.
ELB has quite a few limitations. For example, it isn’t compatible with EKS containers running on Fargate. Also, it can’t forward traffic on more than one port per instance, and it doesn’t support forwarding to IP addresses—it can only forward to explicit EC2 instances or containers in ECS or EKS. Finally, ELB doesn’t support websockets; however, you may be able to work around this limitation by using layer 4.
To run an ELB in the us-east-1 region, it will cost you $0.025 per ELB-hour + $0.008 per GB of traffic.
AWS discourages the use of ELB in favor of its newer load balancers. Admittedly, there are very few scenarios where the use of an ELB would be preferable; typically, these are cases where you simply don’t have a choice. For example, your workload might still run on EC2-Classic, or you need the load balancer to use your own sticky session cookies, in which cases ELB would be the only option available to you.
The Next Step in Load Balancing
In 2016, AWS launched its Elastic Load Balancing version 2, which is made up of two offers: Application Load Balancer (ALB) and Network Load Balancer (NLB). They both use a similar architecture and concepts.
Most importantly, they both use the concept of “target groups,” which is one additional level of redirection. It can be conceptualized in this way. Listeners receive requests and decide (based on a wide range of rules) to which target group they will forward the requests. A target group then routes the requests to instances, containers, or IP addresses. Target groups manage the targets in terms of deciding how to split up the traffic and by performing health checks on the targets.
Both ALB and NLB can forward traffic to IP addresses, which allows them to have targets outside the AWS Cloud (for example: on-premises servers or instances hosted on another cloud provider).
Let’s now dive into both offers.
Application Load Balancer
An Application Load Balancer (ALB) only works at layer 7 (HTTP). It has a wide range of routing rules for incoming requests based on host name, path, query string parameter, HTTP method, HTTP headers, source IP, or port number. In contrast, ELB only allows routing based on port number. Also, contrary to ELB, ALB can route requests to many ports on a single target. Plus, ALB can route requests to Lambda functions.
A very useful feature of ALB is that it can be configured to return a fixed response or a redirection. So you don’t need a server to perform such basic tasks because it is all embedded in the ALB itself. Also very importantly, ALB supports HTTP/2 and websockets.
ALB further supports Server Name Indication (SNI), which allows it to serve many domain names. (In contrast, ELB can serve only one domain name). There is a limit, however, to the number of certificates you can attach to an ALB, namely 25 certificates plus the default certificate.
An interesting feature of ALB is that it supports user authentication via a variety of methods, including OIDC, SAML, LDAP, Microsoft AD, and well-known social identity providers such as Facebook and Google. This can help you off-load the user authentication part of your application to the load balancer.
ALB pricing is a bit more complicated than ELB. For the us-east-1 region, it would cost you $0.0225 per ALB + $0.008 per LCU-hour. The definition of an LCU can be found here. All in all, pricing is roughly equivalent to ELB.
ALBs are typically used for web applications. If you have a microservices architecture, ALB can be used as an internal load balancer in front of EC2 instances or Docker containers that implement a given service. You can also use them in front of an application implementing a REST API, although AWS API Gateway would generally be a better choice here.
Network Load Balancer
A Network Load Balancer (NLB) works at layer 4 only and can handle both TCP and UDP, as well as TCP connections encrypted with TLS. Its main feature is that it has a very high performance. Also, it uses static IP addresses and can be assigned Elastic IPs—not possible with ALB and ELB.
NLB natively preserves the source IP address in TCP/UDP packets; in contrast, ALB and ELB can be configured to add additional HTTP headers with forwarding information, and those have to be parsed properly by your application.
NLB pricing for the us-east-1 region is $0.0225 per NLB-hour + $0.006 per LCU-hour. The definition of an LCU for NLB is quite similar to that for ALB, and more information can be found here. All in all, pricing is roughly equivalent to ELB and ALB.
NLBs would be used for anything that ALBs don’t cover. A typical use case would be a near real-time data streaming service (video, stock quotes, etc.) Another typical case is that you would need to use an NLB if your application uses non-HTTP protocols.
Comparison Table
| ALB | NLB | ELB | |
Basic load balancing features | |||
| Balance load between targets | Yes | Yes | Yes |
| Perform health checks on targets | Yes | Yes | Yes |
| Highly available | Yes | Yes | Yes |
| Elastic | Yes | Yes | Yes |
| TLS Termination | Yes | Yes | Yes |
| Performance | Good | Very high | Good |
| Send logs and metrics to CloudWatch | Yes | Yes | Yes |
| Layer 4 (TCP) | No | Yes | Yes |
| Layer 7 (HTTP) | Yes | No | Yes |
| Running costs | Low | Low | Low |
Advanced load balancing features | |||
| Advanced routing options | Yes | N/A | No |
| Can send fixed response without backend | Yes | No | No |
| Supports user authentication | Yes | No | No |
| Can serve multiple domains over HTTPS | Yes | Yes | No |
| Preserve source IP | No | Yes | No |
| Can be used in EC2-Classic | No | No | Yes |
| Supports application-defined sticky session cookies | No | N/A | Yes |
| Supports Docker containers | Yes | Yes | Yes (*) |
| Supports targets outside AWS | Yes | Yes | No |
| Supports websockets | Yes | N/A | No |
| Can route to many ports on a given target | Yes | Yes | No |
(*) Except for EKS with Fargate
Conclusion
AWS has a good range of options when it comes to load balancing, and you’ll probably find anything you need there. Additionally, AWS load balancers integrate very well with the rest of the AWS services, such as AWS Certificate Manager, AWS Web Application Firewall, AWS Shield, Amazon CloudWatch, and many others.
AWS load balancers are pretty much used everywhere by everyone and have definitely stood the test of time. They are very reliable.
Their pricing is very similar, so this probably won’t be a large factor in your decision. Generally speaking, you would want to use an ALB for layer 7 load balancing and NLB for everything else.
