InsufficientInstanceCapacity: We currently do not have sufficient capacity
Fix InsufficientInstanceCapacity: retry in another availability zone, switch instance type, or accept a range of types. Covers Spot and Capacity Reservations.
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances operation: We currently do not have suffi
Incident Overview
Fix InsufficientInstanceCapacity: retry in another availability zone, switch instance type, or accept a range of types. Covers Spot and Capacity Reservations.
medium fix·5 min read
By Vishvesh Patel·DevOps Engineer·Updated 21 September 2026
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances operation: We currently do not have sufficient m5.large capacity in the Availability Zone you requested (eu-west-1a). Our system will be working on provisioning additional capacity. Error: creating EC2 Instance: InsufficientInstanceCapacity Could not launch On-Demand Instances. InsufficientInstanceCapacity
Do this first3 steps
Run these in order. Each one tells you what its output means before you change anything.
• Confirm it is capacity and not a quota
InsufficientInstanceCapacity means AWS has none to give. VcpuLimitExceeded means you have hit your own limit. The first is not fixable by a support request, the second is.
• Try another availability zone
Capacity is per zone. An offering of 1 means the type exists there, though it does not guarantee free capacity. Launching in a different zone is usually the fastest workaround.
• Find equivalent instance types you could accept instead
Accepting a family of equivalent types rather than one exact type is what makes an Auto Scaling group resilient to this. Attribute-based selection expresses that directly.
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.
aws service-quotas get-service-quota --service-code ec2 --quota-code L-1216C47A --query 'Quota.{Name:QuotaName,Value:Value}'First, is it actually capacity?
Two errors are frequently confused:
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.
aws service-quotas get-service-quota --service-code ec2 \
--quota-code L-1216C47A \
--query 'Quota.{Name:QuotaName,Value:Value}'Change the availability zone
Capacity is per zone, so this is usually the quickest fix:
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.
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)'
doneChange the instance type
Older or less popular families frequently have capacity when the newest do not:
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.
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 textThe 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:
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:
New instance families are then picked up automatically as AWS releases them.
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" }
}
}
}Capacity Reservations
For capacity you must have at a specific time, such as a known traffic peak:
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.
aws ec2 create-capacity-reservation \ --instance-type m5.large --instance-platform Linux/UNIX \ --availability-zone eu-west-1a --instance-count 10
Spot
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.
Could not launch Spot Instances. InsufficientInstanceCapacity
EKS and ECS
Managed node groups pass through to an ASG, so the same fixes apply:
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.
aws eks update-nodegroup-config --cluster-name prod --nodegroup-name workers \ --scaling-config minSize=2,maxSize=10,desiredSize=4
A checklist
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.
Reference and practice
Learn the underlying concept
Other AWS errors
Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.
Get notified about new tutorials and features.
• Roadmaps
• Interview Prep
• Certifications
• Company
© 2026 DevOpsLesson. All rights reserved.
Need to practice this scenario?
Simulate this error condition and practice recovery commands safely in our in-browser terminal.