一部のリージョン (us-east-1 など) では、一部のアベイラビリティーゾーンのみがサブネット (したがって VPC インスタンス) の作成に使用できることがわかりました。私の場合、ゾーンは us-east-1c、-1d、および -1e ですが、これらはアカウントによって異なります。
サブネットと VPC インスタンスを生成するスクリプトを作成しているので、どのゾーンが VPC 対応であるかをプログラムで調べると便利です。特に、一連のゾーンが変更できなかった (または少なくとも拡張できなかった) 理由がわかっているためです。時間とともに。
この投稿は基本的に同じ質問をしていましたが、受け入れられた回答は実際には私とその質問者が探していた情報を提供しません (ec2-describe-availability-zones に私が認識していない VPC 固有のパラメータがない限り): Amazon VPC の可用性
考えられる回避策の 1 つを見つけました。それは、ガベージ vpc-id とアベイラビリティ ゾーンを使用してサブネットを作成することです ( ec2-create-subnet -c garbage -i 10.0.0.0/24 -z garbage)。この呼び出しのエラー メッセージには、サブネットをホストできる AZ のリストが含まれており、探している情報についてその出力を解析できます。ただし、これはハックのように感じます。必要がない場合、この種のエラー動作やエラー メッセージの特定の形式に依存するのは好きではありません。より良い方法はありますか？
更新:コメントに基づいてもう少し詳細を追加します...
私が ALWAYS を呼び出すと、ec2-describe-availability-zonesus-east-1a から us-east-1e までの 5 つの値が返されますが、VPC サブネットは 1c、1d、および 1e にしか作成できません。1b を除くすべてのゾーンで実行されているインスタンスがあり、通常のインスタンスでさえ起動できませんでした (段階的に廃止されているようです)。このアカウントは VPC 機能のリリース前から存在していたので、「レガシー」アカウントのようなものだと思います。これは、サブネットと VPC インスタンスの作成が許可されている場所と、ec2-describe-availability-zones が戻ってくる時期との不一致に関係している可能性があります。AWS サポートに質問を投稿し、ここで調査結果を報告します。