InsufficientInstanceCapacity: We currently do not have sufficient capacity

AWS does not have that instance type available in that availability zone right now. This is a capacity shortage on their side, not a configuration error and not a limit on your account.

First, is it actually capacity?

Two errors are frequently confused:

aws service-quotas get-service-quota --service-code ec2 \
  --quota-code L-1216C47A \
  --query 'Quota.{Name:QuotaName,Value:Value}'

L-1216C47A is running On-Demand Standard instances, measured in vCPUs. If you are near it, the real error is the quota one and a quota increase is the answer.

For genuine capacity shortage, a support ticket will not help. Only changing what you ask for does.

Change the availability zone

Capacity is per zone, so this is usually the quickest fix:

for az in eu-west-1a eu-west-1b eu-west-1c; do
  echo -n "$az: "
  aws ec2 describe-instance-type-offerings \
    --location-type availability-zone \
    --filters "Name=instance-type,Values=m5.large" "Name=location,Values=$az" \
    --query 'length(InstanceTypeOfferings)'
done

This tells you where the type is offered, which is not the same as where there is free capacity right now. There is no API that reports available capacity; you find out by trying.

Note that zone names are randomised per account, so your eu-west-1a is not the same physical zone as someone else's. describe-availability-zones shows the stable ZoneId if you need to compare.

Change the instance type

Older or less popular families frequently have capacity when the newest do not:

aws ec2 get-instance-types-from-instance-requirements \
  --architecture-types x86_64 --virtualization-types hvm \
  --instance-requirements '{"VCpuCount":{"Min":2,"Max":2},"MemoryMiB":{"Min":8192,"Max":8192}}' \
  --query 'InstanceTypes[].InstanceType' --output text

m5.large m5a.large m5n.large m6i.large m6a.large t3.xlarge ...

m5a is AMD and m6g is Graviton. Graviton in particular often has capacity when x86 does not, and is cheaper, though it needs arm64 images.

The durable fix: accept a range

A single hardcoded instance type in one zone is the design that produces this error. An Auto Scaling group across several zones with a mixed instances policy does not:

resource "aws_autoscaling_group" "app" {
  vpc_zone_identifier = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
    aws_subnet.private_c.id,
  ]

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 50
      spot_allocation_strategy                 = "capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
      }
      override { instance_type = "m5.large" }
      override { instance_type = "m5a.large" }
      override { instance_type = "m6i.large" }
      override { instance_type = "m6a.large" }
    }
  }
}

The ASG tries each type in each zone until something launches. A shortage of one type in one zone becomes invisible.

capacity-optimized for Spot picks pools with the deepest capacity rather than the lowest price, which meaningfully reduces interruptions.

Attribute-based selection expresses the same intent without listing types:

      override {
        instance_requirements {
          vcpu_count   { min = 2, max = 4 }
          memory_mib   { min = 8192 }
        }
      }

New instance families are then picked up automatically as AWS releases them.

Capacity Reservations

For capacity you must have at a specific time, such as a known traffic peak:

aws ec2 create-capacity-reservation \
  --instance-type m5.large --instance-platform Linux/UNIX \
  --availability-zone eu-west-1a --instance-count 10

You pay for reserved capacity whether or not you use it. An On-Demand Capacity Reservation combined with a Savings Plan covers the cost, which is the usual way to make it economic.

Spot

Could not launch Spot Instances. InsufficientInstanceCapacity

Spot capacity is whatever is spare, so this is more common and less alarming. Diversify across types and zones, and use capacity-optimized. A Spot request restricted to one type in one zone will fail regularly by design.

EKS and ECS

Managed node groups pass through to an ASG, so the same fixes apply:

aws eks update-nodegroup-config --cluster-name prod --nodegroup-name workers \
  --scaling-config minSize=2,maxSize=10,desiredSize=4

For a node group, specify several instance types and several subnets across zones.

Fargate has its own capacity limits and fails differently, usually with a throttle rather than this error.

A checklist

1. Check the vCPU quota. A quota error is a different, fixable problem.
2. Try another availability zone. Capacity is per zone.
3. Try an equivalent type: m5a, m6i, m6a, or Graviton if your image supports it.
4. get-instance-types-from-instance-requirements to list equivalents.
5. Move to an ASG spanning all zones with a mixed instances policy.
6. Use attribute-based selection so new families are picked up automatically.
7. Guaranteed capacity at a known time → On-Demand Capacity Reservations.
8. Spot → diversify pools and use capacity-optimized.

---

Frequently Asked Questions

Can I request more capacity from AWS support?

No, not for this error. InsufficientInstanceCapacity means AWS physically has no free capacity of that type in that availability zone at that moment, so there is nothing for support to grant. That is different from VcpuLimitExceeded, which is your account's own quota and is raised through Service Quotas or a support request. Check the quota first, because the two errors are easy to confuse and only one of them has a request-based fix.

Why does the same launch work in a different availability zone?

Because capacity is managed per zone, and each zone is a distinct set of physical facilities with its own hardware. A shortage of one instance type in one zone says nothing about the others. Availability zone names are also randomised per AWS account, so your eu-west-1a is not the same physical location as another account's; describe-availability-zones shows the stable ZoneId when you need to compare across accounts.

How do I stop this happening again?

Stop asking for exactly one instance type in exactly one zone. An Auto Scaling group spanning every zone in the region, with a mixed instances policy listing several equivalent types, will find capacity somewhere and the shortage becomes invisible. Attribute-based instance selection goes further by describing what you need in vCPU and memory terms, so AWS picks from every matching family including ones released after you wrote the configuration.

Is there an API that shows available capacity?

No. describe-instance-type-offerings tells you which types are offered in a zone, which is a static property, not whether any are free right now. AWS does not publish real-time capacity, so the only way to find out is to attempt a launch. This is why the resilient pattern is to let an Auto Scaling group try several combinations rather than to try to predict which will succeed.

Why do I see this more often with Spot instances?

Because Spot uses spare capacity by definition, so a shortage affects it first and more often. A Spot request constrained to one instance type in one availability zone will fail regularly, and that is expected behaviour rather than a fault. Diversify across several instance types and zones, and use the capacity-optimized allocation strategy, which selects pools with the deepest available capacity instead of the lowest price and substantially reduces both launch failures and interruptions.