EC2インスタンスの起動時に発生する「InsufficientInstanceCapacity」エラーの修正方法

TL;DR

AWSが指定したアベイラビリティゾーンで物理ハードウェアの在庫不足が発生しています。即効性のある対処法は3つあります：別のAZを試す、類似のインスタンスタイプに切り替える、または別のリージョンに移動する。長期的な保証が必要な場合（本番ワークロード、コンプライアンス要件など）は、実際に必要になる前にオンデマンドキャパシティ予約を設定しておきましょう。

このエラーが発生する原因

RunInstancesの呼び出しと停止中インスタンスの再起動はいずれも、特定のAZにある実際の物理サーバーの割り当てをAWSに要求します。そのAZのハイパーバイザーフリートがお使いのインスタンスファミリーで満杯になると、InsufficientInstanceCapacityエラーが返されます。これはサプライの問題であり、アカウントの問題ではありません。サービスクォータを引き上げても効果はありません。

このエラーが発生しやすい状況は以下の通りです：

p4d.24xlarge、trn1、inf2などのGPU集約型インスタンスの起動 — グローバル供給量が少ない
停止中インスタンスの再起動：停止時にAWSがハードウェアを解放しており、その枠がすでに埋まっている
単一のAZと単一のインスタンスタイプに集中するよう設定されたAuto Scalingグループ
小規模またはプロビジョニングが少ないAZへのデプロイ（例：旧アカウントのus-east-1e）

修正1：別のアベイラビリティゾーンを試す

最も速く、成功率が高い方法です。キャパシティプールはAZごとに独立しているため、us-east-1aが逼迫していてもus-east-1bには十分な空きがある場合があります。

# AZ制約を外す — AWSに選ばせるか、別のAZのサブネットを指定する
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m5.xlarge \
  --subnet-id subnet-0bb1234567890abcd \
  --count 1

複数のAZを自動的に試したい場合は、以下のシェルループを使用できます：

#!/bin/bash
SUBNETS=("subnet-aaa" "subnet-bbb" "subnet-ccc")  # AZごとに1つのサブネット
for SUBNET in "${SUBNETS[@]}"; do
  echo "Trying subnet $SUBNET..."
  RESULT=$(aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type m5.xlarge \
    --subnet-id "$SUBNET" \
    --count 1 2>&1)
  if echo "$RESULT" | grep -q "InstanceId"; then
    echo "Success in $SUBNET"
    echo "$RESULT"
    break
  fi
  echo "Failed: $RESULT"
done

修正2：同等のインスタンスタイプに切り替える

インスタンスファミリーが異なれば、使用するキャパシティプールも異なります — 基盤となるハードウェアがほぼ同一であっても同様です。m5.xlarge（Intel）とm5a.xlarge（AMD）はどちらも4 vCPUと16 GB RAMを提供しますが、それぞれ別の物理インベントリを使用します。

# m5.xlargeが失敗する場合はm6i.xlargeを試す — 同スペック、別プール
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m6i.xlarge \
  --subnet-id subnet-0bb1234567890abcd \
  --count 1

試すべき信頼性の高い代替ペア：

m5 → m5a / m6i / m6a
c5 → c5a / c6i
r5 → r5a / r6i
p3 → 利用可能であればp3dn / p4d、それ以外はEC2 Capacity Blocks

修正3：スポットインスタンスをフォールバックとして使用する

スポットインスタンスは独立したキャパシティプールから割り当てられます。オンデマンドの枯渇は影響しません。バッチジョブ、CIランナー、または中断を許容できるワークロードに適しています。

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m5.xlarge \
  --subnet-id subnet-0bb1234567890abcd \
  --instance-market-options '{"MarketType":"spot","SpotOptions":{"SpotInstanceType":"one-time"}}' \
  --count 1

修正4：オンデマンドキャパシティ予約で事前にキャパシティを確保する

本番トラフィックやコンプライアンスが求められるワークロードを実行する場合、必要なときにキャパシティが確保できるかを運任せにしてはいけません。障害が発生する前に、事前に予約を作成しておきましょう。

aws ec2 create-capacity-reservation \
  --instance-type m5.xlarge \
  --instance-platform Linux/UNIX \
  --availability-zone us-east-1a \
  --instance-count 5 \
  --instance-match-criteria open

openマッチ基準を指定すると、同じAZで一致するタイプのオンデマンド起動が自動的に予約を使用します — 起動時に追加フラグは不要です。注意点として、予約内でインスタンスが稼働しているかどうかに関わらず、オンデマンド料金が24時間365日発生します。実際に使用する分だけ予約してください。

予約を明示的にターゲットにする場合：

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m5.xlarge \
  --subnet-id subnet-in-us-east-1a \
  --capacity-reservation-specification \
    'CapacityReservationTarget={CapacityReservationId=cr-0123456789abcdef0}' \
  --count 1

修正5：Auto ScalingグループでマルチAZと混合インスタンスタイプを有効にする

単一AZ・単一インスタンスタイプのASGはキャパシティ障害の温床です。混合インスタンスポリシーを使用すると、複数のプールにリスクを分散できます：

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateId": "lt-0123456789abcdef0",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.xlarge"},
        {"InstanceType": "m5a.xlarge"},
        {"InstanceType": "m6i.xlarge"},
        {"InstanceType": "m6a.xlarge"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 1,
      "OnDemandPercentageAboveBaseCapacity": 100
    }
  }'

修正6：停止中のインスタンスが起動できない場合

EC2インスタンスを停止すると、その基盤となるハードウェアがプールに返却されます。再起動しようとする際、AWSはそのAZで新しいハードウェアを見つける必要がありますが、見つからない場合があります。

影響の小さい順に3つの選択肢があります：

待ってリトライする：キャパシティは常に変動しています。us-east-1aなどの人気AZでの不足は、15〜60分以内に解消されることが多いです。
一時的にインスタンスタイプを変更する：停止 → インスタンスタイプを変更 → 起動。別のタイプであれば空きキャパシティがある可能性があります。
AMIを作成して別のAZで再起動する：手間はかかりますが、キャパシティが存在する場所に移行できます。

# 停止中インスタンスのスナップショットを作成
aws ec2 create-image \
  --instance-id i-0123456789abcdef0 \
  --name "my-instance-backup-$(date +%Y%m%d)" \
  --no-reboot

# 別のAZでそのAMIから起動
aws ec2 run-instances \
  --image-id ami- \
  --instance-type m5.xlarge \
  --subnet-id subnet-in-different-az \
  --count 1

修正の確認

起動が成功するとInstanceIdが返されます。インスタンスが実際にrunning状態になったことを確認します：

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,AZ:Placement.AvailabilityZone}' \
  --output table

期待される出力：

--------------------------------------------------
|             DescribeInstances                  |
+----------------------+----------+--------------+
|          AZ          |    ID    |    State     |
+----------------------+----------+--------------+
|  us-east-1b          | i-0abc.. |  running     |
+----------------------+----------+--------------+

次回の起動前に、必要なインスタンスタイプを実際に提供しているAZを確認しておきましょう：

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=instance-type,Values=m5.xlarge \
  --query 'InstanceTypeOfferings[].Location' \
  --output table

参考資料

AWSドキュメント：オンデマンドキャパシティ予約 — 特定のAZでのキャパシティ保証
AWSドキュメント：ML向けEC2 Capacity Blocks — 期間限定のGPUインスタンス予約
AWSドキュメント：Auto Scaling混合インスタンスポリシー — 耐障害性の高いフリートの構築