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.
ELB vs HAProxy: ELB concepts
Load balancer types
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.
ELB vs HAProxy
There may be times when you won’t want to use a load balancer provided by AWS. For instance,
- You may prefer an open source solution.
- You may wish to avoid vendor lock in.
- You don’t want to give up control over load balancer management and security.
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:
- When comparing ELB vs HAProxy, the former can feel a bit limited as far as load balancing algorithms are concerned. It supports only round robin and session stickiness. But consider cases where you need to load the balancer based on incoming URL, or on the number of connections to be handled by individual underlying severs. HAProxy can handle those, and more.
- An Elastic Load Balancer can’t be associated with a static IP address – or even a range of IPs. It can therefore be difficult to create a whitelist to filter traffic coming through an ELB balancer. On the other hand, you could always set up HAProxy on an EC2 instance and assign an Elastic IP address to that instance. That IP can then easily be used in your firewall to whitelist requests.
- Pricing may or may not be a big deal for you, but it can’t hurt to bring it up. AWS charges you for each hour or partial hour that your Elastic Load Balancer is running, and for each GB of data transferred through your Elastic Load Balancer. Since HAProxy is open source, on the other hand, setting it up and running it on an EC2 instance will cost you nothing more than the normal instance usage.
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.