はじめに
TerraformでAWSのEC2（Windowsサーバー、インスタンスタイプはx8i.xlarge）を東京リージョンのap-northeast-1aに作ろうとしたところ、terraform applyが失敗しました。
エラーメッセージは次のとおりです。
Error: creating EC2 Instance: operation error EC2: RunInstances, https response error StatusCode: 400,
api error Unsupported: Your requested instance type (x8i.xlarge Windows) is not supported in your requested Availability Zone (ap-northeast-1a).
Please retry your request by not specifying an Availability Zone or choosing ap-northeast-1c, ap-northeast-1d.エラー: EC2インスタンスの作成に失敗しました。操作エラーEC2: RunInstances、HTTPSレスポンスエラー、ステータスコード: 400、
APIエラーUnsupported: リクエストされたインスタンスタイプ(x8i.xlarge Windows)は、リクエストされたアベイラビリティーゾーン(ap-northeast-1a)ではサポートされていません。
アベイラビリティーゾーンを指定しないか、ap-northeast-1cまたはap-northeast-1dを選んで、もう一度リクエストしてください。
同じリージョンの中でも、AZによって起動できるインスタンスタイプが違う場合があると知って、驚きました😳
この記事では、このエラーの原因と、AZごとの提供状況の確認方法と、東京リージョンで実際に調べた結果を紹介します📝
この記事はこんな人向けです
- TerraformやCloudFormationでAZを固定してインスタンスを作っている方
- 新しいインスタンスタイプを、特定のAZで使えるかを事前に確認したい方
エラーの意味
Unsupported: Your requested instance type (...) is not supported in your requested Availability Zone (...)は、指定したAZが、指定したインスタンスタイプを提供していない時に出ます。
括弧の中のx8i.xlarge WindowsはインスタンスタイプとOSの組み合わせで、エラーメッセージの後半には提供されているAZ(今回はap-northeast-1cとap-northeast-1d)が書かれています。
AWS公式のKnowledge Centerでは、このエラーの対処として、AZを指定せずに起動するか、提供されているAZを指定して起動するよう案内されています1。
AZを指定しなければ、EC2が対応するAZを選びます。
同じ原因で、停止中のインスタンスを起動する時にThe requested configuration is currently not supportedが出る場合があります2。
このエラーは、そのAZでは恒久的に起きます。
容量不足のInsufficientInstanceCapacityは一時的なエラーなので、待てば解消する場合があります。
AZが提供していないことが原因のエラーは、待っても解消しません。
提供状況をAWS CLIで調べる
describe-instance-type-offeringsで、インスタンスタイプごとに提供されているAZを確認できます3。
aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=instance-type,Values=x8i.xlarge --region ap-northeast-1
今回の調査では、x8i.xlargeは次の結果でした。
同じAPI(DescribeInstanceTypeOfferings)をboto3で実行した結果で、AWS CLIの出力も同じ項目で構成されたJSONです。
{
"InstanceTypeOfferings": [
{
"InstanceType": "x8i.xlarge",
"LocationType": "availability-zone",
"Location": "ap-northeast-1d"
},
{
"InstanceType": "x8i.xlarge",
"LocationType": "availability-zone",
"Location": "ap-northeast-1c"
}
]
}
ap-northeast-1aで提供されていなければ、結果にap-northeast-1aが含まれません。
上の結果をAZごとに整理すると、次のとおりです。
| AZ | x8i.xlarge |
|---|---|
| ap-northeast-1a | 提供なし |
| ap-northeast-1c | 提供あり |
| ap-northeast-1d | 提供あり |
EC2コンソールでも、左のナビゲーションペインの「インスタンスタイプ」を開き、「アベイラビリティーゾーン」の列を表示して、インスタンスタイプで絞り込むと確認できます。
リージョン内の全インスタンスタイプを一括で調べる
AZによって提供が違うインスタンスタイプを一覧にするには、Python (boto3)を使います。
describe-instance-type-offeringsは1回で全件を返さずページ送りが必要なので、paginatorを使います。
import collections
import boto3
REGION = "ap-northeast-1"
ec2 = boto3.client("ec2", region_name=REGION)
all_azs = {
az["ZoneName"]
for az in ec2.describe_availability_zones()["AvailabilityZones"]
}
offered_azs = collections.defaultdict(set)
paginator = ec2.get_paginator("describe_instance_type_offerings")
for page in paginator.paginate(LocationType="availability-zone"):
for offering in page["InstanceTypeOfferings"]:
offered_azs[offering["InstanceType"]].add(offering["Location"])
partial = {
instance_type: sorted(azs)
for instance_type, azs in offered_azs.items()
if azs != all_azs
}
print(f"全タイプ数: {len(offered_azs)}")
print(f"提供 AZ が一部のタイプ数: {len(partial)}")
for instance_type, azs in sorted(partial.items()):
print(instance_type, azs)
実行すると以下のような結果が出力されました。
全タイプ数: 1202
提供 AZ が一部のタイプ数: 157
a1.2xlarge ['ap-northeast-1a', 'ap-northeast-1d']
a1.4xlarge ['ap-northeast-1a', 'ap-northeast-1d']
a1.large ['ap-northeast-1a', 'ap-northeast-1d']
a1.medium ['ap-northeast-1a', 'ap-northeast-1d']
a1.metal ['ap-northeast-1a', 'ap-northeast-1d']
a1.xlarge ['ap-northeast-1a', 'ap-northeast-1d']
(以降は省略)
実行には、ec2:DescribeInstanceTypeOfferingsとec2:DescribeAvailabilityZonesの権限が必要です。
東京リージョンの調査結果
上の方法で、2026年10月19日に東京リージョンの全インスタンスタイプを調べた結果は、次のとおりです。
| 区分 | インスタンスタイプ数 |
|---|---|
| 調べたインスタンスタイプ | 1,202個 |
| 3つのAZすべてで提供されている | 1,045個 |
| 一部のAZでしか提供されていない | 157個 |
思ったより多くて驚きました😲
インスタンスタイプの1割以上が、一部のAZでしか提供されていないのですね👀
提供AZが偏っている主なファミリーは次のとおりです。
| 提供されているAZ | ファミリー |
|---|---|
| 1aと1c(1dなし) | c5a、g5、g6、g6e、g7e、inf2、d3en、c3、m3、r3、x1e |
| 1aと1d(1cなし) | t3a、r5ad、a1 |
| 1cと1d(1aなし) | x8i、g5g |
| 1cのみ | x8aedz |
| 1dのみ | f2 |
| 1aのみ | hpc7g、hpc8a、vt1、p3dn、p5en |
この表を、AZごとの重なりで図にすると次のとおりです。
図の中央の1,045タイプは、3つのAZすべてで提供されているインスタンスタイプの数で、ほかの領域に書いてあるのはファミリー名です。
この結果から、次の傾向が読み取れます。
- 図で紫色にした古い世代のインスタンス4は、1dで提供されないものが多い
- 機械学習や3D描画に使われるGPU系と、AI向けのインスタンス(図では橙色)は、1dで提供されていないものが多い
AWSの公式ドキュメントには、AZごとに差がある理由は書かれていませんが、X1やHigh Memoryなどのファミリーはリージョン内のすべてのAZでは使えない場合があると書かれています5。
ここからは公式ドキュメントの根拠がない私の予想ですが、古い世代のインスタンスは1dで提供されないものが多く、2026年7月に東京リージョンでの提供が始まったX8i6は、1aでは提供されず、1cと1dで提供されています。
このことから、1dは他のAZより後から作られたAZで、新しい世代のインスタンスが中心に置かれているのかな、と感じました🤔
一方で、GPUやAI向けのインスタンスは新しい世代でも1dで提供されておらず、f2やp5enのように1つのAZだけで提供されるものもあるので、GPUやAI向け、FPGAなどのチップを積んだ特殊なインスタンスは提供するAZが絞られやすく、今後登場する新しいインスタンスも3つのAZすべてでは提供されない可能性があると考えています。
注意点
AZ名とAZ IDの対応はアカウントごとに違う場合がある
東京リージョンのAZには、AZ名(ap-northeast-1aなど)とAZ ID(apne1-az4など)の2種類の識別子があります。
この記事の調査結果は、すべてAZ名で書いています。
東京リージョンでは、2025年11月より前に作られたアカウントで、AWSがAZ名と物理的なAZの対応をアカウントごとに別々に割り当てています。
そのため、自分のアカウントのap-northeast-1aと別のアカウントのap-northeast-1aは、同じ物理AZとは限りません。
物理的なAZを一意に表すのは、AZ IDです7。
2025年11月以降に作られたアカウントでは、どのアカウントでもAZ名と物理的なAZの対応が同じになります8。
たとえば図では、同じapne1-az1が、アカウントAではap-northeast-1c、アカウントBではap-northeast-1aになっています。
今回の調査結果は、1つのアカウントでの結果です。
本番のアカウントでは、必ず対象のアカウントで確認してください。
まとめ
インスタンスタイプの提供状況は、リージョンだけでなくAZごとにも違うことが分かりました💡
これからGPUやAI向けのチップを積んだインスタンスを使う機会がもっと増えそうなので、構築の前に、使いたいAZで提供されているかをさっと確認する習慣を、みなさんも一緒につけていきませんか🚀
BIPROGYグループの技術への取り組み
We Are Hiring!
-
How do I resolve the "Your requested instance type is not supported in your requested Availability Zone" error I receive when I launch an EC2 instance?(AWS re:Post Knowledge Center) ↩
-
Why can't I start or launch my Amazon EC2 instance for my Amazon EBS volume?(AWS re:Post Knowledge Center) ↩
-
describe-instance-type-offerings(AWS CLI Command Reference) ↩
-
Amazon EC2 X8i instances are now available in additional regions(AWS What's New) ↩
-
Availability Zone IDs for your AWS resources(AWS RAMユーザーガイド) ↩