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.
Background
As of the updating of this article (2011-12-23) Amazon EC2 (Elastic Compute Cloud) has twenty different availability zones in eight 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:
us-east-1- East coast of the United States (Northern Virginia)us-west-1- West coast of the United States (Northern California)us-west-2- West coast of the United States (Oregon)sa-east-1- East coast of South America (São Paulo, Brazil)eu-west-1- Western Europe (Dublin, Ireland)ap-southeast-1- SouthEast Asia (Singapore)ap-northeast-1- NorthEast Asia (Tokyo)- GovCloud - US Government use only
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-1d
and
eu-west-1aeu-west-1b
When 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.
Balancing
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).
Identification
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 m1.small, one year, Linux/UNIX.
To list the mappings for a single account, you can use a command like:
ec2-describe-regions | cut -f2 | while read region; do
ec2-describe-reserved-instances-offerings --region $region |
perl -ne 'print "$2 $1\n" if
m%\S+\t(\S+)\t(\S+)\tm1.small\t1y.\t.*\tLinux/UNIX(\t(.(?!Utilization)|Medium Utilization)*)$%'
done | sort
Examples
Here are the mappings for one of my accounts (let’s call it “Blue”):
ap-northeast-1a 4b2293b4-ed86-4e9c-a41d-b9aa6ab6d143
ap-northeast-1b ceb6a579-a3ba-4488-ae42-59ca92a3d26f
ap-southeast-1a d586503b-ce55-4e1e-8012-f87395ccfb39
ap-southeast-1b 649fd0c8-66cb-4867-a124-70e7b38902b1
eu-west-1a c48ab04c-0bd0-4be9-8db5-a4bad61c6c58
eu-west-1b d586503b-7025-44e8-8487-09907b6b0e7e
eu-west-1c c48ab04c-ca5b-43be-999b-ed45d67a058e
sa-east-1a ceb6a579-ef87-4741-bbb5-f52911e182b4
sa-east-1b 248e7b75-96bb-4161-b50a-2f042094f022
us-east-1a 438012d3-80c7-42c6-9396-a209c58607f9
us-east-1b 60dcfab3-06bb-4b68-9503-53bf89823b5e
us-east-1c ceb6a579-757c-474b-b09b-52c84b605767
us-east-1d 649fd0c8-5d76-4881-a522-fe5224c10fcc
us-west-1a c48ab04c-446f-416d-b7e1-75db17b1354c
us-west-1b e5a2ff3b-79b4-4217-8c93-ebf1d633dd6e
us-west-1c 4b2293b4-def5-468b-ae97-63886afe7a09
us-west-2a 60dcfab3-d0b1-48f5-bb2a-031bba5ec5e5
us-west-2b ceb6a579-9c3b-4098-b745-c3e256d612c5
Here are the mappings for a different account (let’s call it “Red”):
ap-northeast-1a 4b2293b4-ed86-4e9c-a41d-b9aa6ab6d143
ap-northeast-1b ceb6a579-a3ba-4488-ae42-59ca92a3d26f
ap-southeast-1a 649fd0c8-66cb-4867-a124-70e7b38902b1
ap-southeast-1b d586503b-ce55-4e1e-8012-f87395ccfb39
eu-west-1a d586503b-7025-44e8-8487-09907b6b0e7e
eu-west-1b c48ab04c-0bd0-4be9-8db5-a4bad61c6c58
eu-west-1c c48ab04c-ca5b-43be-999b-ed45d67a058e
sa-east-1a 248e7b75-96bb-4161-b50a-2f042094f022
sa-east-1b ceb6a579-ef87-4741-bbb5-f52911e182b4
us-east-1a ceb6a579-757c-474b-b09b-52c84b605767
us-east-1b 438012d3-80c7-42c6-9396-a209c58607f9
us-east-1c 60dcfab3-06bb-4b68-9503-53bf89823b5e
us-east-1d 649fd0c8-5d76-4881-a522-fe5224c10fcc
us-west-1a e5a2ff3b-79b4-4217-8c93-ebf1d633dd6e
us-west-1b c48ab04c-446f-416d-b7e1-75db17b1354c
us-west-1c 4b2293b4-def5-468b-ae97-63886afe7a09
us-west-2a 60dcfab3-d0b1-48f5-bb2a-031bba5ec5e5
us-west-2b ceb6a579-9c3b-4098-b745-c3e256d612c5
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.
Caveats
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.
[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.]
Follow Eric Hammond on Twitter
Awesome - thanks!
This can help eliminate cross-availability-zone networking charges when I copy data from my Testing account to/from my Production account. In order to restrict access to the Production deployment I have two separate AWS accounts, Testing and Production. The AZs in these accounts do not match, and I sometimes end up being charged for transferring data between (instances belonging to) the two accounts. Using your tip I can figure out where to deploy my Testing instances to save $$ transferring data between instances belonging to the different accounts.
As of Dec. 20, 2012 it looks like Amazon has changed their zones mapping again. Now for each zone they have multiple codes. Below are few output lines from one of my EC2 accounts:
ap-northeast-1a 3a98bf7d-8adc-4dfe-9bd6-b16a735c0894
ap-northeast-1a 4b2293b4-ed86-4e9c-a41d-b9aa6ab6d143
ap-northeast-1a d586503b-1ff7-4466-8593-34b02b42d768
ap-northeast-1b 4b2293b4-8b7a-4aec-9636-cc4aad7e3514
ap-northeast-1b ceb6a579-9e28-422a-ac6b-d200348f1ea1
ap-northeast-1b ceb6a579-a3ba-4488-ae42-59ca92a3d26f
Yiftach:
Thanks. I have updated the code above to only look for "Medium Utilization" records (the previous default).
Another approach to the same problem (though definitely a more complex approach) would be to use the spot instance pricing history. The history can be used as a signature to match azs across accounts -- histories rarely match between azs in the same region with even the 1 day timeframe (exception being us-west-2/Oregon).
Also worth noting -- this is a guess -- I haven't tried it in practice yet. Maybe I'll find that spot rates differ between accounts in the same datacenter/ configuration.
Do you mind telling users who are unfamiliar with commands such as "ec2-describe-regions" where one can obtain those commands. I've tried running them on my ec2 instance to no avail.
hengjie:
You can install these commands on Ubuntu using:
sudo apt-get install ec2-api-tools
You'll also need to set up the AWS credentials and some environment variables as described here: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/setting-up-your-tools.html#set-aes-home