RightScale Blog

Cloud Management Blog
Benchmark Your Cloud Maturity Quiz
Cloud Management Blog

Amazon Consolidated Billing and Reserved Instances

Amazon added consolidated billing a couple of days ago. It allows you to consolidate multiple accounts onto a single bill so your credit card only gets one hefty charge instead of many smaller ones from all the accounts you might have. What's actually nice is that you can download a CSV file with the details of all the accounts in one place so you get an overview of where the money is going. For someone like me who has over a dozen accounts that's really, really nice!

From the account you use for billing you can send invites to others so they can add their account to your billing method. They can still see their bill, it just doesn't hit their credit card, it hits yours. You get to see what they used too, since you're paying for it. I created a new account that I'm not using for any service at all and consolidated all my "real" accounts onto it. This way I can pretty freely hand out the credentials in finance and admin so anyone there who wants to see the numbers can log in without having any power over any instances, buckets, or whatnot.

One of the nice benefits of consolidated billing is that you can share some of the savings of reserved instances across accounts, but the details are pretty weird. The part that makes sense is that if account A doesn't use a reserved instance "slot" then another account B can make use of it and get the discounted hourly rates. Where it gets weird is that if account A purchased a reserved instances in zone us-east-1a then account B gets the benefit also in zone us-east-1a. While this may sound logical it makes no sense because the zone names are permuted between accounts, so A's 1a is typically different from B's! Amazon: why do we need to buy reserved instances in an availability zone as opposed to a region since it clearly doesn't really matter?

I've actually always been unhappy with reserved instances. They seem to combine two completely different notions that I believe don't go together because the use-cases are disjoint. One notion is that of a "revenue commit" or "buying into a discount tier": you pay some money up front to get a lower rate. Makes perfect sense, but why does it have to be tied to an availability zone? Or even to an instance type for that matter? The second notion is that of guaranteed availability - your reserved instance slot is always guaranteed to be available, you won't get an "insufficient capacity" error. I understand why that has to be for a specific zone and type.

The reason the two notions don't mix for me is that in order to get the discount benefits you have to run your instance virtually all the time. It really only is advisable for instances that always run. In that case the whole notion of reservation is moot since you're running all the time anyway! If you're looking for the availability guarantee it's generally because the instance is not running all the time and you want to make sure that the day you need it you can get it. Think disaster recovery scenario. In that case the whole "discount" is moot, since you're like to actually pay more due to the up-front reservation cost! I wish I could just buy the discount without the availability guarantee and without the tie to a specific zone!  

One thing I noticed is that most of our larger customers are not using reserved instances. I wonder why...

Comments

Thorsten, I think it makes more sense when you look at it through the competitive lens. The reserved instance pricing is designed to be compelling for you if you're considering the alternative of getting a three year server lease and putting it into a colo. What do you get with a three year server lease -> guaranteed capacity in a specific place and a known price.
Thorsten, Yes, I agree that it's the better way to do it (and what I do). But then again the most I had to wait for an instance to be launched was 30 minutes (and even that only once, other times much less). Ismael
Ismael, thanks for the comment! Yes, from a theoretical point of view you are of course right, but I maintain that the two use cases are disjoint. For me "replacing" means "launch new instance, get it operational, switch over, terminate old when all is ok" and in this case the reservation helps nothing.
Hi, "Well, in that case the whole notion of reservation is moot since you’re running all the time anyway!" Even if the aim is to run them all the time, you may still need to replace them with new instances due to various reasons. If the cluster has enough redundancy and there are insufficient capacity errors, one can take down existing instances in order to replace them with new ones without being afraid of others getting the available instances first. Sure, quite hypothetical. :) "I wish I could just buy the discount without the availability guarantee and without the tie to a specific zone!" Definitely agree. Best, Ismael

Post a comment