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!
The way it works is that 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 & 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: so 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, i.e., 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. Well, 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. Well, 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…