Amazon AWS announces load balancing

On May 17 2009, Amazon announced a new set of services. Included are two features I always wanted to see in their portfolio, namely auto scaling of an entire web application as well as load balancing. Unsurprisingly, Amazon calls these features Auto Scaling and Elastic Load Balancing.

Load balancing was something that, from a developer’s point of view, I didn’t want to be bothered with. Sure, I wanted it to work, but I didn’t want to get it to work. In the past, developing an application on top of an Infrastructure as a Service (IaaS) provider like Amazon often involved setting up your own load balancer, for example by creating a new instance from an Amazon Machine Image (AMI) with some suitable load balancing software. This was when the offerings of a Platform as a Service (PaaS) provider like Microsoft’s Azure platform became quite compelling (For differences between IaaS and PaaS, have a look here). Hosting an application on Azure already includes / will include load balancing, auto scaling and auto curing. That’s what PaaS is about: It is a more specialized stack than IaaS taking away some of your freedom of choice (Azure currently supports .NET and PHP apps while IaaS lets you use virtually everything) but in turn offers some features that IaaS normally doesn’t provide out of the box.

This is the reason why this offering affects Microsoft: it increases pressure on the development of the Azure platform. Amazon just took away one of the reasons to choose a tightly integrated PaaS provider over an IaaS provider. Of course, that feature has to come with a price, otherwise Amazon would lose money for all the running instances that currently do the work of a load balancer. I think that price is reasonable, which currently is at “$0.025 per hour for each Elastic Load Balancer, plus $0.008 per GB of data transferred through an Elastic Load Balancer”.

Let’s compare both approaches: Without Elastic Load Balancing, one had to pay for (at least) one instance running the load balancer (assumed this was an extra instance) but no traffic costs since traffic between EC2 instances within the same availability region is free of charge. We could have been using a reserved instance (linux), so we would have to pay the 1-year fee plus the hourly charges for one year, leaving us with

325 + (365 * 24 * 0.03) = {\bf 587.8} $

With Elastic Load Balancing, we have to pay

365 * 24 * 0.025 = {\bf 219} $ plus traffic charges, which makes it hard to put any number here. Still, we can tell how many GB we could serve through Elastic Load Balancing before it gets more expensive than our first solution:

(587.8 - 219) / 0.008 = {\bf 46,112} GB. That’s right, that’s about 45 Terabyte. I say, that’s fair enough to get anyone started 🙂

We have to keep three things in mind here:

  1. Normally, we wouldn’t use only one load balancer for the first solution because this would be a single point of failure. But if we trust Amazon’s Elastic Load Balancer to be inherently fault tolerant, we still could use one Elastic Load Balancer instead of two, making this solution even more worth the money.
  2. You can keep the amount of GB flowing through the Load Balancer small. You do not have to serve all your pictures, videos etc through your web server, instead you should use another server or S3 or CloudFront or whatever. This separation for media files is no special do-fancy-stuff-to-reduce-my-amazon-fee workaround; it’s a common approach.
  3. In a small company / startup, I would definitely go for Elastic Load Balancing because it has this nice aaS aspect: It hides complexity from me, thus saving me time and nerves. It also integrates nicely with other services from Amazon AWS such as auto-scaling and monitoring.

Combined with Auto Scaling, Amazon provides the possibility to let an application react upon increasing and decreasing traffic, distributing load across several servers and even cure itself by replacing unresponding instances with freshly booted ones which register themselves to the load balancer.

This will probably also give a headache to the guys over at Rightscale and Scalr which filled the gap by providing monitoring, auto-scaling, loadbalancing and self-curing on top of Amazon AWS. Of course, their services are more comprehensive than Amazon’s beta features but they are also more expensive. Over at RightScale it says “The RightScale Platform is available in editions starting at $500 a month with a one-time integration and access fee of $2,500.” For small companies, Amazon just saved the day.

Wrap-up: I believe the new offerings from Amazon (Auto Scaling, Monitoring and Elastic Load Balancing) are very attractive to developers with limited knowledge in infrastructure and network topics as well as to start-ups or other small businesses which do not want to pay for full-blown equivalents like RightScale. Amazon expands a core concept of cloud computing (grow dynamically, pay dynamically) to new features.

Links on that topic:


One thought on “Amazon AWS announces load balancing

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s