Knowing How Much to Spend on the AWS Elastic Load Balancer
Load balancing is an element of most popular web applications. The reason for this is simple: Load balancers maintain application scalability and sustainability. It’s nearly impossible to imagine a modern application handling continuous traffic or periodic traffic spikes while relying only on a single running server’s capacity. As a result, load balancers have become a critical part of software development. Thanks to modern cloud solutions, such as AWS Elastic Load Balancing (ELB), load balancing can be implemented smoothly and at a reasonable cost.
This article will briefly explain how load balancing works and touch upon the various tools that exist to achieve it. After discussing the various types of load balancers offered by AWS, we’ll look at ways to reduce your AWS Elastic Load Balancing costs.
Understanding Load Balancing
Imagine that your server-side application is running on a physical or virtual machine, responding to dozens of requests from clients all day, every day. Everything is going fine until you notice that the amount of requests has increased, leading to losses in performance. The correct solution in this scenario is to set up one or more additional servers. After you’ve made a few clones of your server, you need to distribute all of the incoming requests among them. This is where a load balancer comes into play.
Basically, load balancing is a mechanism for distributing incoming traffic among servers. A load balancer is an interlayer which provides that mechanism.
Load Balancer Types
There are three types of load balancers, described below:
Hardware load balancers are proprietary devices installed in front of physical servers. Such devices can usually be found in the data centers of big companies which may prefer to use their own infrastructures instead of third-party vendor options. Hardware load balancers are not typically used directly by engineers and developers building web services.
Software load balancers are applications which can be installed on physical or virtual servers. Similar to hardware balancers, software load balancers require proper installation, configuration, and maintenance. Software load balancers are usually set up and managed by DevOps staff and are commonly used with web applications. The most popular software load balancers on the market are HAProxy, Traefik, and NGINX.
Cloud load balancers — also called Load Balancers as a Service (LBaaS) —cloud load balancers are the cloud services that allow developers to build efficient load balancing strategies with minimum effort. These load balancers are fully managed by the major cloud providers, including Amazon Web Services.
AWS Elastic Load Balancing
In general, AWS ELB works on the same principles as other load balancers, but it also extends their basic functionality with some additional out of the box features.
AWS ELB can be used with AWS EC2 instances as well as with other AWS services, such as AWS Lambda for serverless applications, AWS WAF for application security, CloudTrail and CloudWatch for logging and monitoring, and a host of other functions.
There are three main types of AWS ELBs: classic load balancers, application load balancers, and network load balancers. Each of these is designed for various use cases, as detailed below.
Classic Load Balancers
Classic load balancers (CLBs) are connection-based, meaning that they do their jobs independently of their requests’ content. These load balancers are always considered to be a single entry point for the whole application or service. They simply pass requests to the underlying computing instances.
Currently, classic load balancers are considered to be a legacy service. It’s best to avoid using them in new projects, and existing projects should be migrated to either application or network load balancers.
Application Load Balancers
The main feature of application load balancers (ALB) is their ability to direct requests to different targets depending on parameters such as the request url and fields in the bodies of the requests.
ALBs support only HTTP/HTTPS traffic. While this level of support is usually more than enough for most regular web applications, consider using network load balancers when an app requires the handling of some other TCP/UDP or TLS traffic.
Network Load Balancers
Network load balancers (NLBs) are based on the fourth layer of the Open Systems Interconnection (OSI) model. Like classic load balancers, they distribute requests independently of their content. Network load balancers were designed to handle millions of requests per second. While they provide excellent performance, they are less configurable than application load balancers. Like ALBs, NLBs support various types of targets in multiple availability zones.
AWS ELB Pricing and Cutting Costs
AWS’ classic load balancer pricing is simple; it depends only on the balancer’s uptime and amount of traffic. NLB and ALB pricing is a bit more complicated. It introduces special load balancer capacity units (LCUs) which include such parameters as new connections per second, number of active connections per minute, amount of traffic processed, and number of rule executions (for ALBs). However, only the dimension with the highest rate of use is considered when evaluating the amount of LCU used.
Although ALB pricing looks complex, it’s actually very flexible. Using ALBs properly by implementing the three strategies below can help reduce load balancing costs.
Migrate from CLB to ALB
ALBs offer the possibility of creating up to ten rules that direct the load balancer to use specific targets based on path, body, and/or other request parameters. Classic load balancers don’t have this functionality, so developers need to either create separate balancers for each particular service in their application or configure, maintain, and continuously pay for an additional routing server, like NginX. An application consisting of 10 main services would need 10 classic load balancers; however, that same application would require just a single ALB to handle that routing.
As was previously mentioned, CLB pricing is based on uptime and traffic, while ALB pricing is based on uptime and LCU used per hour.
S3 and CloudFront for the Static Files
How an application is built can affect its load balancing costs. Usually, the front end part of a service consists of a bunch of static files and data needed to start the application on the client’s side and display its contents properly. These could be single page apps built with React or Angular or just general HTML/CSS/JS wrappers responsible for displaying content on the end user’s screen. It doesn’t make sense to serve those files and data from your servers, since the same files are always being served, regardless of the requested content or current user.
A good practice is to use AWS S3 for hosting web applications’ static files, along with AWS CloudFront to serve those files effectively to users all over the world. Properly used S3 + CloudFront CDN can dramatically decrease the load on your main servers, provide a better experience for users, and increase performance.
If this setup cannot be implemented in your app, consider adding cache-control headers to static responses in order to decrease the amount of duplicated HTTP requests from the client side.
Remove Idle Load Balancers
The last and most straightforward suggestion—and one which can be applied to any kind of AWS resources—is to monitor your system for idle load balancers and remove them. Even if there are no instances attached to the load balancer, or its attached services are unhealthy, that load balancer is still running and increasing your monthly bill. Load balancers can be removed or reconnected to healthy resources from the web console by using AWS CLI. These are both manual processes, but they can be automated using a recurrent AWS Lambda function that obtains a list of ELBs, checks their targets, and performs designated actions.
So…Is Load Balancing Worth It?
It’s definitely worth spending money on load balancing in production. Enabling the proper type of load balancer will bring your application architecture quality to a new level, increasing its durability and availability. Modern cloud solutions, such as AWS ELB, are cost-effective and relatively easy to set up. In addition, they require very little supervision. Moreover, you can configure log analysis for your ELBs in order to obtain useful statistics about your application, such as the amount of incoming and outgoing traffic, the geographic distribution of the requests, and other metrics which are helpful for diagnostics and for troubleshooting your application. Applying the tips outlined in this article will enable you to keep your ELB costs down while maximizing the efficiency of your applications.
