It’s time to ditch that old load balancer! Compare your options. | Itoc

It’s time to ditch that old load balancer! Compare your options.

Written by It’s time to ditch that old load balancer! Compare your options., .

Posted November 8, 2017

How to choose your AWS Load Balancer

It’s not terribly often that Amazon Web Services (AWS) recommends that you replace one of its services, and this time we are talking about your trusty Elastic Load Balancer (ELB). These ELBs (now named “Classic” Load Balancers) have been the mainstay of highly available architectures on AWS since their release in 2009, faithfully serving us and distributing our traffic.

AWS has all but deprecated these classic load balancers in favour of their next gen (v2) load balancers, and now you’re given a choice of two. There is the Application Load Balancer (ALB) offering full Layer 7 (application) functionality and the Network Load Balancer (NLB) operating at Layer 4 (transport). The load balancer to select depends on which layer of the networking stack (per the Open Systems Interconnection (OSI) model) you need your load balancer to operate at for your workload. Both have their use cases and features so let’s dive in and compare them to your old Classic Load Balancer!

Application Load Balancer

The ALB gives you the ability to perform Content-Based Routing on traffic headers so you can direct traffic destined for to one target group and to a different group. ALB currently supports up to 10 of these rules, so we’re seeing many microservice based architectures simplifying their load balancer configurations down to one ALB (think of those cost savings!!).

Not only that, but your microservices can now live in separate Auto Scaling Groups allowing you to easily scale them independently behind the same load balancer! Why scale up and consume compute resources for /admin when you only need to scale up /api? Efficiency!

Under the Classic load balancer if you wanted to share it (think cost minimisation) you were limited to separating your services by ports (all services running on all instances but listening on known, “hard-coded” ports). If you wanted to achieve advanced routing based upon the URL or other headers you simply can’t do it. Common architectural patterns included creating and maintaining a reverse proxy (such as NGINX) to perform this layer 7 routing! If this rings true with you, by adopting the Application Load Balancer there is a good chance you can now remove that reverse proxy as well.

The Application Load Balancer provides improved support for ECS and containers by facilitating service load balancing with dynamic host port mappings. In short, dynamic host ports for your containers are no longer an issue and these can be registered with the ALB via ECS’ Service Load Balancing. We no longer have to maintain those static port mappings between the load balancer and the instances.

Application Load Balancers also provide better health checks, increased performance, and native support for HTTP/2 and Websockets. Try doing that with your Classic Load Balancer!

Network Load Balancer

Most recently released, the Network Load Balancer (NLB) should now be your primary choice for load balancing on AWS if you don’t require the layer 7 functionality of the Application Load Balancer. This new load balancer is the closest match for the Classic Load Balancer and has almost entirely removed the previous issues, challenges and shortcomings of the previous version.

Where your Classic Load Balancer has dynamic IP addresses which could (and do) change over time, the new Application and Network Load Balancers have static IP addresses deployed as network interfaces in each enabled Availability Zone. This means no more DNS cache flushing or trickery for those apps which don’t support DNS lookups for your service endpoints. You’re also able to associate Elastic IPs to your Load Balancer’s network interfaces and get those whitelisted - yep, it is easy to work with that third party provider now! :)

Convinced yet? Network Load Balancers support zonality to help keep requests within an Availability Zone for lower latency and performance without sacrificing the high availability with being deployed across Availability Zones. This zonality, backed by Route53 health checks for failover and availability is a great, highly performant and available combination.

But wait, there’s more, the Network Load Balancer preserves source IP addresses, meaning your servers, applications and associated logs now get the source IP natively. No longer will you see the need to remap the X-Forwarded headers so your application can see the source IP as is the case with the Classic load balancer. By making the shift to the Network Load Balancer you just removing extra processing and configuration from your environment… you’re welcome!

Network Load Balancers also bring support for your long-running connections, just send your TCP heartbeats and watch that connection persist. Magic. Do that with your Classic load balancer!

Now couple your load balancers with Amazon Certificate Manager (ACM) and you have free, automatically renewing, domain validated TLS certificates!

So go and revisit that architecture of yours and give it some much needed love!

For more information, check out the following links for related AWS documentation:

Need help migrating your workload across to using the new load balancers? Contact Itoc and we’d be happy to assist! Oh, and if you just need that quick pointer, here’s a free tool from AWS which might help:

It’s time to ditch that old load balancer! Compare your options.

Need help migrating your workload?