Matching EC2 Availability Zones Across AWS Accounts

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 writing of this article, Amazon EC2 (Elastic Compute Cloud) has six different availability zones in two 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 (probably near Washington, DC)
• eu-west-1 - Western Europe (probably near Dublin, Ireland)

The availability zones in those regions are given the region name plus simple letters appended:

• us-east-1a
• us-east-1b
• us-east-1c
• us-east-1d

and

• eu-west-1a
• eu-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 recently 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.

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%'; 
done | sort

Examples

Here are the mappings for one of my accounts (let’s call it “Blue”):

eu-west-1a 649fd0c8-75d4-4e16-88c7-1ddb83f66062
eu-west-1b 438012d3-0440-480a-9f5c-eb7e55dd5a37
us-east-1a 4b2293b4-1e6c-4eb3-ab74-4493c0e57987
us-east-1b 60dcfab3-a56c-4092-8c90-3677e9da02b7
us-east-1c c48ab04c-c057-457e-a4d8-a0f172f4db2d
us-east-1d c48ab04c-7e96-4ea8-9579-d62194490546

Here are the mappings for a different account (let’s call it “Red”):

eu-west-1a 438012d3-0440-480a-9f5c-eb7e55dd5a37
eu-west-1b 649fd0c8-75d4-4e16-88c7-1ddb83f66062
us-east-1a c48ab04c-c057-457e-a4d8-a0f172f4db2d
us-east-1b 4b2293b4-1e6c-4eb3-ab74-4493c0e57987
us-east-1c 60dcfab3-a56c-4092-8c90-3677e9da02b7
us-east-1d c48ab04c-7e96-4ea8-9579-d62194490546

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.