我发现在某些地区（例如us-east-1），只有一些可用区可用于创建子网（因此也就是VPC实例）。在我的例子中，区域是us-east-1c，-1d和-1e，但这些区域因帐户而异。
我正在构建一个生成子网和VPC实例的脚本，因此以编程方式找出哪些区域具有VPC能力是很有用的，特别是因为我知道为什么区域集不能改变（或者随着时间的推移，最不成长。
这篇文章提出的问题基本相同，但接受的答案实际上并没有提供我和提问者正在寻找的信息（除非ec2-describe-availability-zones有一些特定于VPC的参数我不知道of）：Amazon VPC Availability
我找到了一种可能的解决方法，即尝试使用垃圾vpc-id和可用区（ec2-create-subnet -c garbage -i 10.0.0.0/24 -z garbage）创建子网。此调用的错误消息包括能够托管子网的AZ列表，我可以解析该输出以查找我正在查找的信息。但是，这感觉就像一个黑客，我不喜欢依赖于错误行为和错误消息的特定格式，如果我不必这样做。还有更好的方法吗？
更新：根据评论添加更多细节......
我对ec2-describe-availability-zones的调用总是返回五个值：us-east-1a到us-east-1e，但我们只能在1c，1d和1e中创建VPC子网。我们在除1b之外的所有区域都运行实例，其中我甚至无法启动常规实例（它似乎逐渐被淘汰）。此帐户自VPC功能发布之前就已存在，因此我认为它有点像“遗留”帐户。这可能与我允许创建子网和VPC实例之间的差异以及ec2-describe-availability-zones返回时的差异有关。我将向AWS支持发布一个问题，并在此处报告任何调查结果。
答案 0 :(得分：9)
在AWS支持下来回一点点之后，我的情况似乎是由于亚马逊决定不去躲避＆＃34;现有的可用区甚至在逐步淘汰新实例之后，因为他们认为隐藏可能仍然有运行实例的AZ会很困惑。他们建议在我的情况下确定具有VPC功能的AZs是硬编码还是反复试验 - 令人失望，但是可以理解。
因此，我做出故意错误请求并解析错误（见下文）的解决方案似乎是少数邪恶中的较小者。
> 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.
更新：经过对AWS支持的更多跟进后，我能够确认这确实与我的帐户预约VPC相关，并且能够区分＆＃34;限制＆＃34;通过API提供支持VPC的AZ是他们的路线图。
答案 1 :(得分：1)
我不确定您的意思是创建一个假子网以查看您可以使用的可用区域。 VPC中的每个子网都位于特定的可用区中。根据文件：
Q值。子网是否可以跨越可用区？
没有。子网必须位于单个可用区内。
它们的常见问题解答：http://aws.amazon.com/vpc/faqs/
因此，基本上在创建子网时，您可以确定它应该位于哪个可用区域。