Fix: InsufficientInstanceCapacity

An EC2 launch, Auto Scaling action, or CloudFormation deploy failed with InsufficientInstanceCapacity. This one trips people up because it looks like a limit you did something wrong to hit, but it is not about your account at all. AWS is telling you it does not currently have physical capacity for that exact instance type in that exact Availability Zone. It is a temporary supply condition on the AWS side. The fix is to stop retrying the same type in the same AZ and instead broaden where and what you launch.

InsufficientInstanceCapacity

What this error means

EC2 capacity is physical: real servers in real Availability Zones. When you request a specific instance type in a specific AZ, AWS has to have a free host of that hardware to place you on. InsufficientInstanceCapacity means it does not have one right now for that type in that AZ. This is entirely separate from your account quota. If you had hit a quota, EC2 would return VcpuLimitExceeded (or a limit-exceeded error) instead, and the remedy there is a Service Quotas increase. Because InsufficientInstanceCapacity is a transient supply problem, the same request frequently succeeds a short time later, or immediately if you ask for a different AZ or an equivalent instance type. Popular and newer instance types in single AZs are the most likely to hit it.

Common causes

• High demand for a specific instance type in a specific Availability Zone at that moment.
• Pinning launches to a single AZ, so there is no fallback when that one AZ is tight.
• Requesting a large or specialized instance size (GPU, high-memory, newest-generation) that has thinner capacity.
• Launching many identical instances at once into one AZ, exhausting what is available there.
• A failover or scale-up event where everyone in the region reaches for the same capacity simultaneously.

How to fix it

STABILIZE

1. Do not retry the identical request in a tight loop; it will keep failing while the AZ is tight and adds noise. First confirm the error is capacity and not a quota by reading it precisely: InsufficientInstanceCapacity is capacity, VcpuLimitExceeded is quota.
2. Retry the launch in a different Availability Zone in the same region, which is the fastest workaround when only one AZ is short:

aws ec2 run-instances \
  --image-id ami-0abcd1234efgh5678 \
  --instance-type m5.large \
  --subnet-id subnet-0zone-b-xxxxxxxx \
  --count 1

DIAGNOSE

1. Check which instance types are actually offered in each AZ of your region, so you choose an AZ and type combination that exists:

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

2. Identify equivalent instance types you can accept, so you are not locked to one. For a given family and size there are usually several comparable options across generations (for example m5.large, m5a.large, m6i.large, m5n.large).
3. Confirm this is not actually a quota issue by checking your running vCPU limit for the family:

aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-1216C47A

Quota code L-1216C47A is the Running On-Demand Standard instances vCPU limit. If you are near it, the real error would be VcpuLimitExceeded, and a quota increase is the fix instead.

FIX

1. Spread across AZs. Give Auto Scaling groups and launches multiple subnets in different AZs so a single tight AZ does not block you.
2. Accept multiple instance types. Use a launch template with an Auto Scaling group configured for mixed instances so ASG can substitute an equivalent type when one is unavailable:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {"LaunchTemplateName": "my-lt", "Version": "$Latest"},
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5a.large"},
        {"InstanceType": "m6i.large"}
      ]
    }
  }' \
  --vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc"

3. For a launch you know is coming (a planned scale-up or a failover drill), reserve capacity ahead of time with an On-Demand Capacity Reservation for the type and AZ:

aws ec2 create-capacity-reservation \
  --instance-type m5.large \
  --instance-platform Linux/UNIX \
  --availability-zone us-east-1b \
  --instance-count 10

How to prevent it

• Run across at least two or three Availability Zones so no single AZ shortage blocks a launch.
• Configure Auto Scaling groups with a mixed instances policy listing several equivalent types.
• Use Capacity Reservations for planned events and for capacity you must be able to launch on demand.
• Avoid pinning to the newest or most specialized instance types for workloads that can run on more widely available families.
• For scheduled scale-ups, launch a little ahead of demand rather than at the exact moment everyone in the region reaches for capacity.

When to call a senior engineer

Call for help when capacity shortages keep breaking autoscaling or failover, when a workload is stuck on a specialized instance type (GPU or high-memory) with thin availability, or when you need capacity guaranteed for a critical event and are unsure how to combine reservations, mixed instances, and multi-AZ placement without overspending. Erzon engineers can redesign the launch strategy so a single AZ or type shortage stops being an outage, and set up reservations that guarantee the capacity you actually need.