A load balancer used to be a fairly simple physical device that balanced the incoming traffic (load) across your servers. Back then, when discussing load balancer configuration, the balancer scheduling algorithm (round robin, least busy, random, etc…) was everyone’s biggest focus. Since then load balancing has become a bit more sophisticated. With cloud based deployments the load balancer, while no longer a physical device, remains a critical part of hosting web based applications.
When deploying an application on AWS you have three choices of load balancing services to use and they each offer a slightly different set of features and accompanying pros and cons. Each service also has some limitations on which AWS hosting platforms it is compatible with.
As a basic primer on load balancers you first need to understand a little bit about the OSI networking model. The OSI model describes the seven levels at which a network system can operate.
You can read all about the OSI Model here but for the purposes of discussing the AWS load balancer services we are primarily concerned with Layer 4 (Transport) and Layer 7 (Application).
The transport layer is where routing occurs based on the TCP/IP and UDP protocols. The simplest way to think about this is that Layer 4 load balancers can make decisions about where to send traffic based on IP address, port and not much else. This means if you are using a Layer 4 load balancer and you need to make routing decisions based on things like path or hostname you will need to make those decisions downstream of the load balancer.
The application layer is where you have full view of a particular request and it’s content. In this scenario, routing decisions are being made based on the HTTP and HTTPS protocols. This allows a Layer 7 load balancer to make decisions based on path, hostname, and potentially even more specific aspects of request content.
When AWS first started offering a load balancing service the only option was a hybrid Layer 4 and Layer 7 load balancer which was initially called Elastic Load Balancer (ELB). To make things a bit confusing AWS now refers to all their load balancing options as ELB and this first iteration (which is still currently available) is now referred to as the Classic Load Balancer, while still under the overall umbrella of ELB. You will often hear people refer to the Classic Load Balancer as ELB but it is technically a flavor of ELB. The Classic Load Balancer has some great features but its proxy based approach left it with some significant short-comings that make it neither a great Layer 4 load balancer nor a great Layer 7 load balancer and ultimately not a great choice for modern applications. I suspect that AWS will eventually phase out the Classic Load Balancer and thus I wouldn’t recommend choosing this option for any new deployment you are planning.
The second load balancer offering that AWS introduced was the Application Load Balancer. The ALB is a robust Layer 7 load balancer offering native support for HTTP/HTTPS and partial support for HTTP/2. ALB also offers a robust set of routing options (path, host, etc..) as well as some really nice continuous delivery features such as connection draining and highly configurable health-checks. For most web based applications that are just serving HTTP and HTTPS traffic ALB is a great choice. There are a few gotchas with ALB however. One thing to keep in mind is that all the host/path routing decisions are based on a rules table that ALB maintains and currently there is a hard limit of 100 rules. This means if you are hoping to have more than 100 domains or paths that you want to base your routing decisions on you are likely still going to have to run a secondary load balancer or proxy (such as HAProxy or Nginx) in front of your applications.
The most recent offering to come from AWS is the Network Load Balancer. NLB is an extremely robust Layer 4 load balancer. By removing the Layer 7 requirement that is present on the Classic Load Balancer, NLB does not have to act like a proxy and it can make decisions based solely on TCP/IP and UDP information. This means that not only is the load balancer completely transparent to your application (no proxy headers etc…) but it’s also extremely fast and capable of handling massive and very spiky traffic while introducing almost no overhead or latency. The major drawback of NLB is it makes no attempt to be a Layer 7 load balancer so you are left completely on your own to handle Layer 7 routing to your application.
At Convox we have lived through the entire history of AWS load balancers. For our first generation ECS based Platform as Service offering we relied on the Classic Load Balancer because it was the only option available. As we were working on our current iteration of the ECS platform ALB had become available and allowed us to introduce a great new set of features for our customers such as automatic TLS, fully managed custom domains, review applications, seamless rolling updates, and a very robust set of health checks. We have been very happy with the performance of ALB although some of our larger customers with huge microservice deployments have struggled with the rules limits, and we have had to rely on workarounds. We have also found the HTTP/2 implementation on ALB to be less than ideal because, while the load balancer can handle HTTP/2 traffic, it is downgraded to HTTP/1.1 before reaching the underlying services. That said, for the vast majority of our customers we still find ALB to be a great fit.
When we started working on our Kubernetes based platform we realized that we could have our cake and eat it too. We knew we wanted to use NLB because it offered the most flexibility and performance. Because we were now deploying to a Kubernetes cluster we had the opportunity to define our own Layer 7 load balancer within the cluster. With this configuration we are able to offer a zero configuration Platform as a Service experience and a highly configurable and customizable set of load balancing options on the same platform while achieving great scale and performance.
If you are interested in trying out either or ECS or EKS based platforms you can sign up for free here
