Distributing and efficiently balancing incoming traffic is a basic and critical requirement for most web applications. Load balancers help to distribute and balance traffic based on different algorithms to filter for effects like round robin, session affinity, geographical location, and latency. Load balancers have been around for long enough that they’re part of a fully matured market. Both hardware and software balancers are widely available.
Still, while placing a load balancer in front of your application will definitely improve performance, it does carry some overhead, including setup and maintenance costs, and the need to ensure high availability and properly handle failure.
In Amazon’s architectural design, a Virtual Private Cloud (VPC) is an isolated network into which you can launch compute resources. If you have Internet-facing instances in a public availability zone within a VPC, you would place an external load balancer on top of your resources to manage traffic. For devices inside a VPC’s private availability zone (for a corporate intranet, for example), you could deploy an internal load balancer.
ELB supports SSL termination at the load balancer itself, removing the need to manage SSL certificates at the application instance level. Flexible cipher support allows you to control the ciphers and protocols the load balancer presents to clients.
Sticky sessions are central to the design of many web applications, and developers will usually need to write extra code to implement the feature. ELB can take over this task, allowing you to configure session stickiness in just a few steps…again, at the load balancer level.
Monitoring a load balancer can help you to identify all kinds of performance related issues related to metrics like request latency, request counts, and failed request counts. The data provided by Amazon CloudWatch can greatly simplify the monitoring process, leaving you free to concentrate on application development.
Using access logs to properly analyze web traffic or to diagnose application behavior is obviously very important. However, since AWS manages ELB – effectively keeping you away from the underlying hardware – you can’t get to your logs the way you normally would on servers that you manage directly. Enabling Access Logs and pointing to the S3 bucket where you’d like your logs stored will cause all relevant log data to be transferred to S3. From there, you’ll be able to analyze away to your heart’s content.
Before a load balancer can redirect requests to a server, it’s important to determine the availability (or health) of the underlying server/application. By pointing your balancer’s health check to a custom application endpoint, its status will be regularly monitored. Health checks will then try to ping, say, your index.html page. If it receives a “200” response code, then it will assume everything is fine. “400” responses would mean there’s trouble, and traffic could be routed away from that server.
There may be times when you won’t want to use a load balancer provided by AWS. For instance,
For such scenarios you should be able to intelligently compare ELB vs HAProxy, a widely-adopted open source (software-based) load balancer. Besides being fairly simple to configure, here are some of the things that HAProxy does well:
You definitely shouldn’t think I’ve got anything against AWS ELB. In fact, they’re constantly improving their product. Rather, I’ve simply tried to present various scenarios that can have more than one possible solution. It’s up to you to compare ELB vs HAProxy (along with other options) and choose whatever will work best for you.
Therefore, if your business doesn’t require complex load balancing algorithms, and is fine with simple round robin patters then I would recommend ELB for its simplicity. Similarly, if your applications are deployed across different availability zones within an AWS region and the servers are running as part of an auto scaling group, then it will be much easier to seamlessly integrate your AWS resources if you use ELB.
Trying to get the same just done with HAProxy might not be quite so simple.
This post was intended to help you understand some key ELB features and, at the same time, introduce you to an important open source load balancer solution (HAProxy). The rest is up to you.
If you’d like to add your own thoughts on the ELB vs HAProxy conversation, please leave a comment.
If you want to get a jump start on ELB, check out Cloud Academy’s Introduction to ELB course.
It's Flash Sale time! Get 50% off your first year with Cloud Academy: all access to AWS, Azure, and Cloud…
In this blog post, we're going to answer some questions you might have about the new AWS Certified Data Engineer…
This is my 3rd and final post of this series ‘Navigating the Vocabulary of Gen AI’. If you would like…