VPC-capable availability zones in Amazon

Question

I've found that in some regions (such as us-east-1), only some availability zones are available for creating subnets (and therefore VPC instances). In my case, the zones are us-east-1c, -1d, and -1e, but these vary by account.

I'm building a script that generates subnets and VPC instances, so it would be useful to find out programatically which zones are VPC-capable, especially since I see know reason why the set of zones couldn't change (or at least grow) over time.

This post was asking basically the same question, but the accepted answer doesn't actually provide the info I and that asker were looking for (unless ec2-describe-availability-zones has some VPC-specific parameter I'm not aware of): Amazon VPC Availability

I have figured out one possible workaround, which is to try and create a subnet with a garbage vpc-id and availability zone (ec2-create-subnet -c garbage -i 10.0.0.0/24 -z garbage). The error message for this call includes a list of the AZs that are able to host subnets, and I can parse that output for the info I'm looking for. However, this feels like a hack, and I don't like relying on error behavior and the specific format of error messages for this kind of thing if I don't have to. Is there a better way?

UPDATE: Adding a bit more detail based on comments...

Calls I make to ec2-describe-availability-zones ALWAYS return five values: us-east-1a through us-east-1e, but we can only create VPC subnets in 1c, 1d and 1e. We have instances running in all zones except 1b, in which I was unable to launch even a regular instance (it appears to be getting phased out). This account has existed since before the release of the VPC feature, so it's somewhat of a "legacy" account I suppose. That might have something to do with the discrepancy between where I'm allowed to create subnets and VPC instances and when ec2-describe-availability-zones is returning. I'm going to post a question to AWS support and will report any findings here.

Answer 1

After a little back and forth with AWS support, it appears that my situation is the result of a decision on Amazon's part not to "hide" existing Availability Zones even after they are phased out for new instances, since they believed it would be confusing to hide an AZ that might still have running instances. Their recommendation for determining VPC-capable AZs in my situation is either hard-coding or trial-and-error - disappointing, but understandable.

So, my solution of making an intentionally bad request and parsing the error (see below) seems to be the lesser of a handful of evils.

> ec2-create-subnet -c garbage -i 10.0.0.0/24 -z garbage
Client.InvalidParameterValue: Value (garbage) for parameter availabilityZone is invalid. Subnets can currently only be created in the following availability zones: us-east-1c, us-east-1d, us-east-1e.

UPDATE: After some more follow-up with AWS support, I was able to confirm that this is indeed related to my account pre-dating VPC, and that the ability to distinguish between "restricted" and VPC-capable AZs via the API is on their roadmap.

Answer 2

I'm not sure what you mean create a fake subnet to see what availability zone you can use. Every subnet in a VPC is in a specific availability zone. As per documentation:

Q. Can a subnet span Availability Zones?

No. A subnet must reside within a single Availability Zone.

It's in their FAQs: http://aws.amazon.com/vpc/faqs/

So basically when you create a subnet you can tell which availability zone it's supposed to be in.