You may know that Amazon Web Services Reserved Instances have some gotchas. One of these gotchas is that the availability zone in which the reservation is purchased cannot be changed. So if you need to use an instance in a different availability zone (e.g. if you hit InsufficientCapacity errors*) than your reservation, you’re out of luck – and you end up paying the on-demand price.
Today at CloudConnect I chatted with Jeremy Edberg of Reddit and Joe Arnold of Cloudscaling, and we had an insight: there’s a workaround. Read on for more details.
* AWS says this shouldn’t happen, but I’ve seen it happen.
The Availability Zone Cha-Cha
EC2 availability zones are different for each customer: my us-east-1a may be your us-east-1c. This makes it confusing when you discuss specific availability zones with other users. Eric Hammond published a technique to discover the correspondence between availability zones across accounts, but there has been limited practical use for this technique.
What if you could share reserved instances across accounts? What if you could do so without regard to the availability zone? Wouldn’t this help circumvent insufficient capacity errors?
Guess what: you can. EC2 Consolidated Billing allows you to set up a master account that consolidates the billing of many sub-accounts. If you use consolidated billing then your reservations from one sub-account’s us-east-1a are usable for another “sister” account’s us-east-1a. Here’s the quote:
Bob receives the cost benefit from Susan’s Reserved Instances only if he launches his instances in the Availability Zone where Susan purchased her Reserved Instances. For example, if Susan specified us-east-1a when she purchased her Reserved Instances, Bob must specify us-east-1a when he launches his instances in order to get the cost benefit on his Consolidated Bill. However, the actual locations of Availability Zones are independent from one account to another. For example, the us-east-1a Availability Zone for Bob’s account might be in a different location than for Susan’s account.
So, here’s the idea:
- Set up two accounts in AWS. You might want to use the same credit card for both of them to make your life easier.
- Use Eric Hammond’s technique to determine whether or not us-east-1a on the two accounts match up. If they do: make a new account. You’re looking for two accounts whose us-east-1a do not match.
- Repeat step 2, creating new accounts and making sure that us-east-1a does not match any of the other accounts. Do this until you have four accounts, all with different physical availability zones behind us-east-1a.
- Set up Consolidated Billing for those accounts.
- Launch an on-demand instance in one account’s us-east-1a. It doesn’t matter which, because the reserved instance pricing will apply.
- If that original instance has a problem and you need to launch another one in a different availability zone, just choose one of the other accounts. Launch the new instance in that account’s us-east-1a availability zone. Reserved instance pricing will apply to the new instance as soon as you terminate the original.
One caveat: I haven’t actually tried this. Please let me know if this helps you.
4 replies on “EC2 Reserved Instance Availability Zone Problem? No Problem.”
I would be very interested in hearing about cases where people need to match EC2 availability zones across customer accounts. Feel free to email me (jbarr at amazon dot com) if you have an actual use case and I’ll forward the info to the development team.
Sure, happy to share a use case:
When two accounts interact with each other on the internal EC2 network, such as the Production account pulling the latest info from the Staging account, you want to minimize the cost of the data transfer between them. This is only possible if you know the correspondence of the physical availability zones.
Readers are welcome to submit more use cases as comments.
If you are still collecting use cases, here is an old one, which is the opposite of shlomo’s, due to devpay you want to force them into different az’s:
Revisiting this use case, I think I might use consolidated billing rather than devpay – but I am not sure since my use case is extra-company, and consolidated billing seems intra-company (e.g. 20 linked account limit, credit card required).