EC2 Availability Zones and Instance Types

UPDATED 2014: See the bottom of the page for a table of results updated as of the 21st of March 2014.

One of the odd things Amazon doesn’t tell you about EC2 is that some instance types simply aren’t supported by particular availability zones in the US-East region.

I work on libraries for provisioning so I should, perhaps, have noticed this earlier - however I just noticed it today when I was updating some code to handle the new per-Availability Zone Spot Price feeds. Some zones simply aren’t listed!

When provisioning normal instances in an availability zone that doesn’t support that instance type you get the error “Your requested instance type (m2.4xlarge) is not supported in your requested Availability Zone (us-east-1b). Please retry your request by not specifying an availability zone or choosing us-east-1a, us-east-1c, us-east-1d”

At work we don’t generally launch instances that are targeted to an Availability Zone, however I have seen this before when launching t1.micro instances (which, again, were unavailable in my us-east-1b). I assumed this meant that availability zone had run out of t1.micro capacity and provisioned it elsewhere - never noticing that it was always the same zone giving this complaint.

But now it’s clear as day in the spot price history tables - when an instance type isn’t supported by an Availability Zone it’s not listed in the graph (and it appears greyed out in the drop-down list at the top right of the price history page)

Amazon also do this bizarre psychometric loadbalancing thing where the zone called “us-east-1a” for my account may be the zone called “us-east-1b” for yours. If you do automated provisioning and want to target specific Availability Zones you’ll probably want a way to avoid accidentally targeting Normal or Spot instances at Availability Zones where they won’t be supported.

The way that my API works is the provider makes offers which the client can bid on (so I can write a piece of code to discard offers for instance types that aren’t supported by a particular availability zone)

As of the time of posting, here’s the list of unsupported Instance Type / Availability Zone combinations for my primary account:

Despite being an incredibly uncommunicative company, Amazon finally responded to this issue with a somewhat bland response on their forums:

As Availability Zones grow over time, our ability to continue to expand them can become constrained. In these scenarios, we will prevent customers from launching in the constrained zone if they do not yet have existing resources in that zone. We also might remove the constrained zone entirely from the list of options for new customers. This means that occasionally, different customers will see a different number of Availability Zones in a particular Region. Both approaches aim to help customers avoid accidentally starting to build up their infrastructure in an Availability Zone where they might have less ability to expand. We recommend the purchase of Reserved Instances to assure capacity for a particular instance type in a specific Availability Zone when you need it.

Gee, thanks. Except there are deficits in all US-East Availability Zones.

The situation in 2014#

I’ve re-run the code mentioned above, this time looking for instance types with neither spot price history data in the last month nor reserved instance offerings in a specific availability zone. The table is shown below. Obviously my particular availability zone names will not match yours, I’ll be posting code shortly to let you run these tests against your own EC2 account. I suspect the situation may no longer be as simple as it was - it may be possible to launch on-demand instances in these availability zones but there may be no spot or reserved capacity available.