The source for ec2-conssitent-snapshot has historically been available here:
For your convenience, it is now also available here:
You are welcome to fork ec2-consistent snapshot under the liberal terms of the Apache License, Version 2.0.
I welcome patch submissions, especially if:
Amazon just announced that the AWS MFA (multi-factor authentication) now supports virtual or software MFA devices in addition to the physical hardware MFA devices like the one that’s been taking up unwanted space in my pocket for two years.
Multi-factor authentication means that in order to log in to my AWS account using the AWS console or portal (including the AWS forums) you not only need my secret password, you also need access to a device that I carry around with me.
Before, this was a physical device attached to my key ring. Now, this is my smart phone which has the virtual (software) MFA device on it. I already carry my phone with me, so the software doesn’t take up any additional space.
To log in to AWS, I enter my password and then the current 6 digit access code displayed by the Android app on my phone. These digits change every 30 seconds in an unguessable pattern, so this enhances the security of my AWS account.
[Update: As predicted, these numbers are already out of date and Amazon has added more public IP address ranges for use by EC2 in various regions.]
Each standard Amazon EC2 instance has a public IP address. This is true for normal instances when they are first brought up and for instances which have had elastic IP addresses assigned to them. Your EC2 instance still has a public IP address even if you have configured the security group so that it cannot be contacted from the Internet, which happens to be the default setting for security groups.
Amazon has made public the EC2 IP address ranges that may be in use for each region.
From this information, we can calculate the absolute upper limit for the number of concurrently running standard EC2 instances that could possibly be supported in each region. At the time of this writing I calculate the hard upper limits to be:
I’m taking a class about using Chef with EC2 by Florian Drescher today and Florian mentioned that he noticed one of the four availability zones in us-east-1 is not currently available for starting new instances.
I’ve confirmed this in my own AWS accounts and found that one of the three availability zones in us-west-1 is also unavailable in addition to one of the four availability zones in us-east-1.
Here’s the error I get when I try to start an instance in the availability zone using an old AWS account:
Client.Unsupported: The requested Availability Zone is no longer supported. Please retry your request by not specifying an Availability Zone or choosing us-east-1d, us-east-1a, us-east-1b.
When I use an AWS account I created two days ago, I don’t even see the fourth availability zone at all:
Update 2011-08-04: Amazon Security did more research and investigated the desktop AMIs. They have confirmed that their software incorrectly flagged the AMIs (false positive) and they caught it in time to stop the warning emails from going out to users.
These AMIs include the NX software for remote desktop operation and the way that NX implement login authentication with ssh is convoluted, but secure. I can easily understand why it might have looked like there were potential problems with the AMIs, and I’m glad things turned out well.
As always, hats off to the hard working folks at AWS and thank for all the great products and services.
Original message:
If Amazon AWS/EC2 contacts you with a warning that one of my AMIs you are running contains a back door security hole with ssh keys or user passwords, please don’t be alarmed.
This article is a followup to Matching EC2 Availability Zones Across AWS Accounts written back in 2009. Please read that article first in order to understand any of what I write here.
Since I wrote that article, Amazon has apparently changed the reserved instance offering ids at least once. I haven’t been tracking this, so I don’t know if this was a one time thing or if the offering ids change on a regular basis.
Interestingly, the offering ids still seem to match across accounts and still map to different availability zones, so perhaps they can still be used to map the true, underlying availability zones as the original article proposes.
To document for posterity and comparison, here are my 2009 availability zone offering ids as calculated by the procedure in the above mentioned article:
Amazon designs availability zones so that it is extremely unlikely that a single failure will take out multiple zones at once. Unfortunately, whatever happened last night seemed to cause problems in all us-east-1 zones for one of my accounts.
Of the 20+ full time EC2 instances that I am responsible for (including my startup and my personal servers) only one instance was affected. As it turns out it was the one that hosts Alestic.com along with some other services that are important to me personally.
Here are some steps I took in response to the outage:
Update: Since this article was written, Amazon has released the ability to copy EBS boot AMIs between regions using the web console, command line, and API. You may still find information of use in this article, but Amazon has solved some of the harder parts for you.
Using Amazon EC2, you created an EBS boot AMI and it’s working fine, but now you want to run instances of that AMI in a different EC2 region. Since AMIs are region specific, you need a copy of the image in each region where instances are required.
This article presents one method you can use to copy an EBS boot from one EC2 region to another.
Ubuntu 9.04 Jaunty has reached EOL (End Of Life). It is no longer supported by Ubuntu with security updates and patches. You have known this day was coming for 1.5 years, as all non-LTS Ubuntu releases are supported for only 18 months.
I have no plans to delete the Ubuntu 9.04 Jaunty AMIs for EC2 published under the Alestic name in the foreseeable future, but I request, recommend, and urge you to please stop using them and upgrade to an officially supported, active, kernel-consistent release of Ubuntu on EC2 like 10.04 LTS Lucid or 10.10 Maverick.
Scott Moser and I were wondering if stopping and starting an EBS boot instance on EC2 would begin a new hour’s worth of charges or if AWS would not increase your costs if the stop/start were done a few minutes apart in the same hour.
For some reason, I had assumed that it would start a new hour of fees, possibly because of my experience with the somewhat unrelated terminating old instances and starting new instances. However, we decided it would be easy to test, so here are the results.
I tested with an Ubuntu 10.10 Maverick 32-bit server EBS boot AMI on the m1.small instance type in the ap-southeast-1 (Singapore) region. The AMI should have no effect on charges, so these results should apply to any OS you run on EC2.
I used an AWS account that did not have any EC2 instance fees in the Singapore region that month (Scott’s idea) so that this activity would be easy to see as the only charges on that account.
A few hours ago, Amazon launched a public preview of AWS Identity and Access Management (IAM) which is a powerful feature if you have a number of developers who need to access and to manage resources for an AWS account. A unique IAM user can be created for each developer and specific permissions can be doled out as needed.
You can also create IAM users for system functions, dramatically increasing the security of your AWS account in the event a server is compromised. That benefit is the focus of this article using an example frequently cited by EC2 users: Automating EBS snapshots on a local EC2 instance without putting the keys to your AWS kingdom on the file system.
Before the release of AWS IAM, if you wanted to create EBS snapshots in a local cron job on an EC2 instance, you needed to put the master AWS credentials in the file system on that instance. If those AWS credentials were compromised, the attacker could perform all sorts of havoc with resources in your AWS account and charges to your credit card.
With the launch of AWS IAM, we can create a system IAM user with its own AWS keys and all it is allowed to do is… create EBS snapshots! These keys are placed on the instance and used in the snapshot cron job. Now, an attacker can do very little damage with those keys if they are compromised, and we all feel much safer.
The AWS IAM documentation is required reading and a great reference. This article is only intended to serve as a practical introduction to one simple application of IAM.
These instructions assume you are running Ubuntu 10.04 (Lucid) on both your local system and on Amazon EC2. Adjust as appropriate for other distributions and releases.
Ubuntu does not yet have an official software package for AWS IAM, so we need to download the IAM command line toolkit from Amazon. This can be done on any machine including your local desktop. The IAM command line tools require Java so we need to make sure that is installed as well.
Eventually, you’ll want to install this software somewhere more permanent, but for this demo, we’ll just use it from a subdirectory.
sudo apt-get install openjdk-6-jre unzip
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
wget http://awsiammedia.s3.amazonaws.com/public/tools/cli/latest/IAMCli.zip
unzip IAMCli.zip
export AWS_IAM_HOME=$(echo $(pwd)/IAMCli-*)
export PATH=$PATH:$AWS_IAM_HOME/bin
The AWS IAM tools require you to save your AWS account’s main access
key id and AWS secret access key in yet another file format. Create
this AWS credential file as, say, $HOME/.aws-credentials-master.txt in
the following format (replacing the values with your own credentials):
AWSAccessKeyId=YOURACCESSKEYIDHERE
AWSSecretKey=YOURSECRETKEYHERE
Note: The above is the sample content of a file you are creating, and not shell commands to run.
Protect the above file and set an environment variable to tell IAM where to find it:
export AWS_CREDENTIAL_FILE=$HOME/.aws-credentials-master.txt
chmod 600 $AWS_CREDENTIAL_FILE
We can now use the iam-* command line tools to create and manage AWS IAM users, groups, and policies.
How you manage your users and groups is sure to be a personal preference that is fine tuned over time, but for the purposes of this demo, I’ll propose that for tracking purposes we put non-human users into a new group named “system”.
iam-groupcreate -g system
Create the snapshotter system user, saving the keys to a file:
user=snapshotter
iam-usercreate -u $user -g system -k |
tee $HOME/.aws-keys-$user.txt
chmod 600 $HOME/.aws-keys-$user.txt
You will want to have this snapshotter keys file on the EC2 instance, so copy it there:
rsync -Paz $HOME/.aws-keys-$user.txt REMOTEUSER@REMOTESYSTEM:
Allow IAM user snapshotter to create EBS snapshots of any EBS volume:
iam-useraddpolicy \
-p allow-create-snapshot \
-e Allow \
-u $user \
-a ec2:CreateSnapshot \
-r '*'
There’s a lot of preparatory and other commands in this article, but
take a second to focus on the fact that the core, functional steps
are simply the iam-usercreate and iam-useraddpolicy commands
above. Two commands and you have a new AWS IAM user with restricted
access to your AWS account.
For the purposes of this demo, we’ll assume you’re using the
ec2-consistent-snapshot tool to create
EBS snapshots with a consistent file system and perhaps a consistent
MySQL database. (If you’re not using this tool, then you could have
simply used ec2-create-snapshot from any computer without having to go
through the trouble of creating a new IAM user.)
Make sure you have the latest ec2-consistent-snapshot software
installed on the EC2 instance:
sudo add-apt-repository ppa:alestic/ppa
sudo apt-get install ec2-consistent-snapshot
Create the snapshot on the EC2 instance. Adjust options to fit your local EBS volume mount points and MySQL database setup.
sudo ec2-consistent-snapshot \
--aws-credentials-file $HOME/.aws-keys-snapshotter.txt \
--xfs-filesystem /YOURMOUNTPOINT \
YOURVOLUMEID
Follow similar steps to create users and set policies for other system activities you perform on your EC2 instances. IAM can control access to many different AWS resource types, API calls, specific resources, and has even more fine tuned control parameters including time-based restrictions.
The release of AWS Identity and Access Management alleviates one of the biggest concerns security-conscious folks used to have when they started using AWS with a single key that gave complete access and control over all resources. Now the control is entirely in your hands.
If you have followed the steps in this demo and you wish to undo most of what was done, here are some steps for reference.
Delete the IAM user and the IAM group:
iam-userdel -u $user -r
iam-groupdel -g system
Wipe the credentials and keys files and remove the downloaded and unzipped IAM command line toolkit:
sudo apt-get install wipe
wipe $HOME/.aws-credentials-master.txt \
$HOME/.aws-keys-$user.txt
rm IAMCli.zip
rm -r $AWS_IAM_HOME
Make sure to wipe the snapshotter key file on the remote EC2 instance as well.
If you’re looking for help with AWS IAM, there is a new AWS IAM forum dedicated to the topic.
[Update 2010-11-19: Fix path where new zip file is expanded]
For information on sponsoring Alestic.com, please see:
A quick but heartfelt note of thanks to Ben Cherian at ServiceCloud, a long term supporter and faithful sponsor of Alestic.com (2 years!). Ben started sponsoring this site, supporting the public Ubuntu AWS/EC2 work I performed, back when this was just a one page site listing the Ubuntu AMI ids on EC2. Alestic.com has multiplied many times in content and organic web traffic over these two years.
Alestic.com is now open to new sponsors. If your company is interested in getting brand exposure at the top of every page on this site dedicated to running Ubuntu on Amazon EC2, please drop me an email.
I like to partner with companies like ServiceCloud and RightScale where the service or product matches the highly targeted reader audience of Alestic.com: folks using or planning to use AWS/EC2 cloud technologies.
BTW, if you are looking for a CIO, consider getting in touch with Ben Cherian who is coming available for new opportunities.
On Friday evening (2 days ago) I and a number of other high octane LA individuals came to LA StartupWeekend to participate in the process of building the beginning of a startup in 2 days. The group of eighty participants divided up organically by interest into about ten different ideas which had been pitched that very evening.
I ended up in a great team of 9 developers, designers, and product folks who were all interested in building the idea I proposed:
Connect individuals carrying cell phone cameras with people who want timely photographs at a particular location.
Less than 48 hours later, we launched the prototype which you can check out now at:
And, we had a lot of fun in the process.
I mention this on the Alestic.com blog because our team used a number of cool technologies including:
Not shown on the site is the fact that two of the developers on the team learned Android development and built an integrated Android application which integrates with the CrowdPhoto.net service. In two days.
We also have prototype integration with Twitter. Feel free to follow us at:
Challenges we ran into and resolved included:
Our first AWS account took a long time to get approved for SimpleDB. Solution: We used SimpleDB from another AWS account (different than the one running the EC2 instance).
We quickly ran into the EC2 email sending limit just with cron job output and emails from our revision control system. Solution: relay email through one of our personal servers on a non-standard port.
We found that some SimpleDB requests had too high a latency to run a large number sequentially: Solution: make the requests in parallel (not yet implemented).
Ubuntu 10.04 Lucid worked like a charm.
Take the prototype service for a spin and let us know what you think. Do you think that this type of application has potential? What would you use it for?
Feel free to be harsh on what you see. We are. But, remember that this was built in less than 2 days from concept, to design, to building development infrastructure, to implementation. This is a fun prototyping project.
We don’t know if there is going to be a future for this project as we all go back to our separate real jobs on Monday, but some of us think there might be something really cool here. Give us your ideas.
[Update 2010-05-03: Added images]
Amazon Web Services (AWS) has a dizzying proliferation of credentials, keys, ids, usernames, certificates, passwords, and codes which are used to access and control various account and service features and functionality. I have never met an AWS user who, when they started, did not have trouble figuring out which ones to use when and where, much less why.
Amazon is fairly consistent across the documentation and interfaces in the specific terms they use for the different credentials, but nowhere have I found these all listed in one place. (Update: Shlomo pointed out Mitch Garnaat’s article on this topic which, upon examination, may even have been my subconscious inspiration for this. Mitch goes into a lot of great detail in his two part post.)
Pay close attention to the exact names so that you use the right credentials in the right places.
(1) AWS Email Address and (2) Password. This pair is used to log in to your AWS account on the AWS web site. Through this web site you can access and change information about your account including billing information. You can view the account activity. You can control many of the AWS services through the AWS console. And, you can generate and view a number of the other important access keys listed in this article. You may also be able to order products from Amazon.com with this account, so be careful. You should obviously protect your password. What you do with your email address is your business. Both of these values may be changed as needed.
(3) MFA Authentication Code. If you have ordered and activated a multi-factor authentication device, then parts of the AWS site will be protected not only by the email address and password described above, but also by an authentication code. This is a 6 digit code displayed on your device which changes every 30 seconds or so. The AWS web site will prompt you for this code after you successfully enter your email address and password.
(4) AWS Account Number. This is a 12 digit number separated with dashes in the form 1234-5678-9012. You can find your account number under your name on the top right of most pages on the AWS web site (when you are logged in). This number is not secret and may be available to other users in certain circumstances. I don’t know of any situation where you would use the number in this format with dashes, but it is needed to create the next identifier:
(5) AWS User ID. This is a 12 digit number with no dashes. In fact, it is simply the previously mentioned AWS Account Number with the dashes removed (e.g., 12345678912). Your User ID is needed by some API and command line tools, for example when bundling a new image with ec2-bundle-vol. It can also be entered in to the ElasticFox plugin to help display the owners of public AMIs. Again, your User ID does not need to be kept private. It is shown to others when you publish an AMI and make it public, though it might take some detective work to figure out who the number really belongs to if you don’t publicize that, too.
(6) AWS Access Key ID and (7) Secret Access Key. This is the first of two pairs of credentials which can be used to access and control basic AWS services through the API including EC2, S3, SimpleDB, CloudFront, SQS, EMR, RDS, etc. Some interfaces use this pair, and some use the next pair below. Pay close attention to the names requested. The Access Key ID is 20 alpha-numeric characters like 022QF06E7MXBSH9DHM02 and is not secret; it is available to others in some situations. The Secret Access Key is 40 alpha-numeric-slash-plus characters like kWcrlUX5JEDGM/LtmEENI/aVmYvHNif5zB+d9+ct and must be kept very secret.
You can change your Access Key ID and Secret Access Key if necessary. In fact, Amazon recommends regular rotation of these keys by generating a new pair, switching applications to use the new pair, and deactivating the old pair. If you forget either of these, they are both available from AWS.
(8) X.509 Certificate and (9) Private Key. This is the second pair of credentials that can be used to access the AWS API (SOAP only). The EC2 command line tools generally need these as might certain 3rd party services (assuming you trust them completely). These are also used to perform various tasks for AWS like encrypting and signing new AMIs when you build them. These are the largest credentials, taking taking the form of short text files with long names like cert-OHA6ZEBHMCGZ66CODVHEKKVOCYWISYCS.pem and pk-OHA6ZEBHMCGZ66CODVHEKKVOCYWISYCS.pem respectively.
The Certificate is supposedly not secret, though I haven’t found any reason to publicize it. The Private Key should obviously be kept private. Amazon keeps a copy of the Certificate so they can confirm your requests, but they do not store your Private Key, so don’t lose it after you generate it. Two of these pairs can be associated with your account at any one time, so they can be rotated as often as you rotate the Access Key ID and Secret Access Key. Keep records of all historical keys in case you have a need for them, like unencrypting an old AMI bundle which you created with an old Certificate.
(10) Linux username. When you ssh to a new EC2 instance you need to connect as a user that already exists on that system. For almost all public AMIs, this is the root user, but on Ubuntu AMIs published by Canonical, you need to connect using the ubuntu user. Once you gain access to the system, you can create your own users.
(11) public ssh key and (12) private ssh key. These are often referred to as a keypair in EC2. The ssh keys are used to make sure that only you can access your EC2 instances. When you run an instance, you specify the name of the keypair and the corresponding public key is provided to that instance. When you ssh to the above username on the instance, you specify the private key so the instance can authenticate you and let you in.
You can have multiple ssh keypairs associated with a single AWS account; they are created through the API or with tools like the ec2-add-keypair command. The private key must be protected as anybody with this key can log in to your instances. You generally never see or deal with the public key as EC2 keeps this copy and provides it to the instances. You download the private key and save it when it is generated; Amazon does not keep a record of it.
(13) ssh host key. Just to make things interesting, each EC2 instance which you run will have its own ssh host key. This is a private file generated by the host on first boot which is used to protect your ssh connection to the instance so it cannot be intercepted and read by other people. In order to make sure that your connection is secure, you need to verify that the (14) ssh host key fingerprint, which is provided to you on your first ssh attempt, matches the fingerprint listed in the console output of the EC2 instance.
At this point you may be less or more confused, but here are two rules which may help:
A. Create a file or folder where you jot down and save all of the credentials associated with each AWS account. You don’t want to lose any of these, especially the ones which Amazon does not store for you. Consider encrypting this information with (yet another) secure passphrase.
B. Pay close attention to what credentials are being asked for by different tools. A “secret access key” is different from a “private key” is different from a “private ssh key”. Use the above list to help sort things out.
Use the comment section below to discuss what I missed in this overview.
Summary: EC2 availability zone names in different accounts do not match to the same underlying physical infrastructure. This article explains a trick which can be used to figure out how to match availability zone names between different accounts.
As of the updating of this article (2014-11-03) Amazon EC2 (Elastic Compute Cloud) has over thirty different availability zones in eleven regions. A region can be thought of as a specific area of the world. An availability zone can be thought of roughly as a data center, defined such that no single failure scenario should affect two availability zones.
The current regions are:
The availability zones in those regions are given the region name plus simple letters appended. For example:
us-east-1aus-east-1bus-east-1cus-east-1dus-east-1eand
eu-west-1aeu-west-1bWhen you start EC2 instances, you can specify an availability zone or let Amazon pick one for you. You always have a default region which can be overridden when starting instances.
In order to prevent an overloading of a single availability zone when everybody tries to run their instances in us-east-1a, Amazon has added a layer of indirection so that each account’s availability zones can map to different physical data center equivalents.
For example, zone us-east-1a in your account might be the same as zone us-east-1c in my account and us-east-1d in a third person’s account.
In fact, given the way that Amazon has set this up, I would not be surprised if Amazon may not occasionally reassign availability zone names which you are not currently using. For example, Amazon added the fourth availability zone in the us-east-1 region, but I suspect this might not be us-east-1d in all accounts (especially new ones).
On occasion, users sometimes want to know if instances in different accounts are running in the same availability zone. Or, users might want to know which availability zone is the one with which people are currently experiencing a particular problem.
You’ll often see users say that there is a problem in zone us-east-1a but this isn’t very helpful for other users because (as described above) that name only has significance within the original user’s account.
What would be helpful is a unique identifier which maps to the underlying physical infrastructure (e.g., data center) and can be mapped to the different availability zone names in each account.
I believe that Amazon may have inadvertently let slip a way to obtain this in the current implementation of the reserved instance offering ids. In my experiments so far, these seem to be tied to something outside of the account’s availability zones and, though the ids are the same, they are mapped to different availability zone names for different accounts.
To demonstrate this I’ve arbitrarily chosen the reserved instance offerings for m3.medium, Linux/UNIX, Heavy Utilization, one year, non-Marketplace, non-VPC.
To list the mappings for a single account, you can use a command like:
aws ec2 describe-regions --output text --query 'Regions[*].[RegionName]' |
while read region; do
aws ec2 describe-reserved-instances-offerings --region $region --output text --query 'ReservedInstancesOfferings[*].[AvailabilityZone,ReservedInstancesOfferingId,InstanceType,OfferingType,ProductDescription,InstanceTenancy,Marketplace,Duration]'|
egrep 'm3\.medium.Heavy Utilization.Linux/UNIX.default.False.31536000' |
cut -f1,2
done | sort
The describe-reserved-instances-offerings API call can be very slow, so wait patiently for the output.
Here are the mappings for one of my accounts (let’s call it “Blue”):
ap-northeast-1b 6126282e-74c0-42db-a3c0-cfb4535203df
ap-northeast-1c f72822dd-b4ac-431e-a8a7-74eb6cb3712d
ap-southeast-1a ca82f875-3397-46e2-915e-1f0149617db3
ap-southeast-1b 528964f4-71a0-4209-8be7-81efc91e0742
ap-southeast-2a 97875095-d596-4535-a355-3edd28a6c404
ap-southeast-2b 31a8bf89-1ec8-4bfd-b8d9-f044d4ce37bb
eu-central-1a 223aa78f-7609-4d55-adf4-26523b76497c
eu-central-1b 0f756f35-6d7d-40e8-99d3-da56ad5e79ca
eu-west-1a 3a02219b-7eca-42f1-967b-513dc8faea80
eu-west-1b b90c4fcf-4b9a-404b-adb0-378b0bb1d15b
eu-west-1c d538b1e9-12c4-4b65-8ad9-fd138fa0ffb7
sa-east-1a ada8467a-6227-4a7c-a08c-0bf7fa1a9b78
sa-east-1b bfe7cebc-d6ce-4186-b405-16c798408f8d
us-east-1a f0e32143-5358-4e0c-a809-b7ebb6f76f94
us-east-1c 451c0ebc-e07f-4ff1-a8c5-936965408bee
us-east-1d afd143f6-2f95-4db4-86ac-b1210bef0254
us-east-1e a19441e7-7e25-4d4c-bce1-71a7bced2c9a
us-west-1a 0c31ec4b-6dbf-4775-9736-137e6cae5e35
us-west-1c b5677909-0292-4d17-b394-3286a9a10119
us-west-2a 3a32d7f4-a14a-4d25-9617-b7e2f98c3986
us-west-2b 882971b6-0f4e-454c-b72f-9b3177090aba
us-west-2c a7ecdbc4-2441-4375-84c7-37400deccaed
Here are the mappings for a different account (let’s call it “Red”):
ap-northeast-1b 6126282e-74c0-42db-a3c0-cfb4535203df
ap-northeast-1c f72822dd-b4ac-431e-a8a7-74eb6cb3712d
ap-southeast-1a 528964f4-71a0-4209-8be7-81efc91e0742
ap-southeast-1b ca82f875-3397-46e2-915e-1f0149617db3
ap-southeast-2a 31a8bf89-1ec8-4bfd-b8d9-f044d4ce37bb
ap-southeast-2b 97875095-d596-4535-a355-3edd28a6c404
eu-central-1a 223aa78f-7609-4d55-adf4-26523b76497c
eu-central-1b 0f756f35-6d7d-40e8-99d3-da56ad5e79ca
eu-west-1a b90c4fcf-4b9a-404b-adb0-378b0bb1d15b
eu-west-1b 3a02219b-7eca-42f1-967b-513dc8faea80
eu-west-1c d538b1e9-12c4-4b65-8ad9-fd138fa0ffb7
sa-east-1a bfe7cebc-d6ce-4186-b405-16c798408f8d
sa-east-1b ada8467a-6227-4a7c-a08c-0bf7fa1a9b78
us-east-1a 451c0ebc-e07f-4ff1-a8c5-936965408bee
us-east-1b f0e32143-5358-4e0c-a809-b7ebb6f76f94
us-east-1d afd143f6-2f95-4db4-86ac-b1210bef0254
us-east-1e a19441e7-7e25-4d4c-bce1-71a7bced2c9a
us-west-1b 0c31ec4b-6dbf-4775-9736-137e6cae5e35
us-west-1c b5677909-0292-4d17-b394-3286a9a10119
us-west-2a 3a32d7f4-a14a-4d25-9617-b7e2f98c3986
us-west-2b 882971b6-0f4e-454c-b72f-9b3177090aba
us-west-2c a7ecdbc4-2441-4375-84c7-37400deccaed
From this, I theorize that availability zone us-east-1a in account Blue is the same as availability zone us-east-1b in account Red, but availability zones us-east-1d happen to be the same in both accounts.
Please note that this approach is not a documented feature of Amazon EC2. I may be misinterpreting what I am seeing and the mappings may be completely random for different accounts.
Amazon could at any time restructure how these values work so that the described offering ids cannot be used between accounts or do not map to any common infrastructure.
Use at your own risk and please post a comment if you find out any further data to support or disprove this theory.
Not all accounts have access to all regions or availability zones in those regions.
Not all accounts have access to reserved instances in the availability zones they have access to.
The Reserved Instance offering ids change from time to time over the years for unknown and unpublished reasons.
[Update 2011-04-25: Tweaked command line to exclude more instance types Amazon has added. Updated info for current ids in current regions/zones.]
[Update 2011-12-23: Tweaked command line to exclude more instance types Amazon has added. Updated info for current ids in current regions/zones.]
[Update 2014-11-03: Updated to use new aws-cli command syntax]