AWS recently launched the Application Load Balancer. It’s like the classic ELB we all know and love but has been administered a hefty dose of Micro Service friendly steroids filling it with heaps of lovely features:
- Content-Based Routing
- Containerized Application Support
- Request Tracing
- …And so much more
The feature that struck me was content-based routing. It was one of those beautiful lightbulb moments, we were running apache load balancer in our legacy solution which utilised content based routing. We originally wanted to do something like this in AWS but the thought of not having to manage apache or NginX was far too alluring. It dawned on us that ALBs mean we still have the convenience of Elastic Load Balancing but with included path based routing. The perfect solution.
ALB are the best of both worlds; I don’t have to manage any additional servers, worry about it being HA or recovery and AWS provide us with content routing.
I came up with a couple of diagrams illustrating how our ELB infrastructure looks now and how our ALB infrastructure may look moving forward.
First, here is a simple representation of our current ELB infrastructure.
As you can see this is a fairly standard way to waste a lot of money on load balancing… One ELB per service.
Here is a simplistic representation of an ALB architecture, which will become much more detailed in the next article.
We have removed the need to have an ELB per service and a route53 record per service. Instead both can now be shared by a single ALB which can forward to multiple services. With this in mind, if we use an ALB to its maximum potential which is 10 rules per load balancer, (or 10 services per ALB), we can turn our 50 load balancer behemoth into a cute little 5 load balancer kitten (because who doesn’t love a kitten?!). Not too shabby!
Most importantly though, COST.
Application Load Balancers cost $0.0252 per hour.
Classic Load Balancers cost $0.028 per hour
Seems like a no-brainer, right? Not quite, AWS have changed the way they bill on the ALB and have added a new unit, LCU (Load Balancer Capacity Units) which uses the highest values of the following metrics:
- New connections (per second)
- Active connections (per minute)
- Bandwidth (Mbps)
So, the calculation becomes a little bit more complex… I’ll show you how we worked it through at Cognito iQ.
Application Load Balancer = $0.0252/h * 24 hours * 5 ALBs = $3.02 per day
Classic Load Balancer = $0.028 p/h * 24 hours * 50 ELBs = $33.60 per day
We know that we are going to be using a large amount of bandwidth compared to new and active connections. To work out the cost we took the bandwidth for the account then divided by the number of ELBs. This isn’t an accurate representation for the ELB costs but will derive the cost or load balancing for the account as a whole.
So, our estimated bandwidth per service is roughly 350 kbp/s which means we can work out our LCU per service:
350/275 = 1.28618181818 LCU.
We can then say that with 10 services attached to a single ALB we will be using 13 LCU per hour.
13 * 0.008 = $0.104 per ALB per hour
(0.104 + 0.0252) * 24 = $3.10 per day.
And like I mentioned at the start, for comparison our ELBs cost around $34 a day.
This is of course all estimation work and obviously is not a complete representation of the cost but gives a good ballpark figure.
If we scale this out taking a 24/7 runtime:
ALB = 3.10 * 365 = $1131.5 per year
ELB = 34 * 365 = $12410 per year
So yes, for Cognito iQ ALB’s are a no brainer, they cash in at about 1/10th the cost of ELB’s.
In the next article, I will share a more detailed architecture diagram and terraform code so you can provision your own ALB to start saving money.