Alestic.com - A Personal AWS Blog by Eric Hammond

understand the commitment you are making to pay for the entire 1-3 years

Amazon just announced a change in the way that Reserved Instances are sold. Instead of selling the old Reserved Instance types:

• Light Utilization
• Medium Utilization
• Heavy Utilization

EC2 is now selling these new Reserved Instance types:

• No Upfront
• Partial Upfront
• All Upfront

Despite the fact that they are still called “Reserved Instances” and that there are three plans which sound like increasing commitment, the are not equivalent and do not map 1-1 old to new. In fact the new Reserved Instances are not even increasing commitment.

You should forget what you knew about Reserved Instances and read all the fine print before making any further Reserved Instance purchases.

One of the big differences between the old and the new is that you are always committing to spend the entire 1-3 years of cost even if you are not running a matching instance during part of that time. This text is buried in the fine print in a “**” footnote towards the bottom of the pricing page:

You may be able to save on future EC2 expenses by selling an unused Reserved Instance for less than its true value or even $0.01, provided it is in the “Heavy Utilization” class.

In the description of the Heavy Utilization Reserved Instance, is this statement:

you pay […] a significantly lower hourly usage fee, and you’re charged that lower hourly rate for every hour in the Reserved Instance term you purchase [emphasis added]

What may not be clear to the casual reader is the fact that when you purchase a Heavy Utilization Reserved Instance, you commit not only to paying the one-time up front cost, but you are also committing to paying the hourly charge for every hour of every month, even if you are not running a matching instance!

The Light Utilization and Medium Utilization descriptions state:

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:

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 (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:

• us-east-1
• us-west-1
• us-west-2
• us-gov-west-1
• eu-central-1
• eu-west-1
• ap-northeast-1
• ap-southeast-1
• ap-southeast-2
• sa-east-1
• cn-north-1

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

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

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 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 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.

Examples

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.

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.

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.

History

[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]