If you’ve tried to launch an EC2 instance or scale an Auto Scaling Group and received the “InsufficientInstanceCapacity” error, you know how frustrating it is. AWS has capacity, but not in your specific AZ for your specific instance type. I’ve seen this error block critical scaling events at 3am. In this post, I’ll show you how to work around it immediately and how to architect your infrastructure so it doesn’t happen again.

The Problem

You attempt to launch an instance or your Auto Scaling Group tries to scale out, and you get this error:

Error Type	Description
InsufficientInstanceCapacity	We currently do not have sufficient m5.xlarge capacity in the Availability Zone you requested (us-east-1a). Our system will be working on provisioning additional capacity. Please retry your request by specifying a different Availability Zone or by waiting to receive more capacity.

Your scaling fails, your infrastructure can’t expand to handle load, and there’s no clear fix beyond “wait” or “try somewhere else.”

Why Does This Happen?

• High demand in that AZ for that instance type — Large organizations or other AWS customers are launching many instances of the same type in the same AZ. Capacity is temporarily exhausted.
• Capacity reservation held by other accounts — If your organization has Capacity Reservations, they may be consuming available capacity, or third parties have reserved capacity in that AZ.
• Instance type being phased out in that AZ — Older instance types (like m4 or t2) are being sunset in specific AZs. AWS gradually deprioritizes them to retire hardware.
• Time of day / region-wide surge — Noon in a major region often sees spikes. Black Friday, major deployments, or announced feature releases cause regional spikes in capacity demand.

The Fix

The key is to have options. Here are the approaches, ranked by how quickly they work:

Option 1: Try a Different Instance Type (Fastest)

If you’re trying to launch m5.xlarge and it fails, try a similar type: m5a.xlarge, m5zn.xlarge, m6i.xlarge, or m7i.xlarge. These are in the same family but on different hardware.

# Instead of launching m5.xlarge, try m5a.xlarge
aws ec2 run-instances \
  --image-id ami-0abc123def \
  --instance-type m5a.xlarge \
  --subnet-id subnet-0abc123 \
  --region us-east-1

This often succeeds because demand for the alternative type is lower.

Option 2: Try a Different Availability Zone (Very Fast)

If a specific AZ is out of capacity, AWS typically has capacity in neighboring AZs.

# List all AZs in the region
aws ec2 describe-availability-zones \
  --region us-east-1 \
  --query 'AvailabilityZones[*].[ZoneName,State]' \
  --output table

# Launch in us-east-1b instead of us-east-1a
aws ec2 run-instances \
  --image-id ami-0abc123def \
  --instance-type m5.xlarge \
  --placement AvailabilityZone=us-east-1b \
  --region us-east-1

Important: Changing AZs can affect latency and data transfer costs if you have cross-AZ traffic. Verify this is acceptable for your workload.

Option 3: Use an Auto Scaling Group with Multi-AZ Spread (Best Long-Term)

The real solution is to distribute your instances across multiple AZs so you’re never pinned to one. If one AZ is full, ASG launches in another.

# Create a Launch Template with your instance config
aws ec2 create-launch-template \
  --launch-template-name my-app-template \
  --launch-template-data '{
    "ImageId": "ami-0abc123def",
    "InstanceType": "m5.xlarge",
    "SecurityGroupIds": ["sg-0abc123"]
  }' \
  --region us-east-1

# Create ASG spanning us-east-1a, us-east-1b, us-east-1c
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-app-asg \
  --launch-template LaunchTemplateName=my-app-template,Version=\$Latest \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 3 \
  --vpc-zone-identifier "subnet-1a,subnet-1b,subnet-1c" \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --region us-east-1

With this setup, if one AZ hits capacity, AWS automatically launches in another AZ. The vpc-zone-identifier parameter accepts a comma-separated list of subnets, each in a different AZ.

Option 4: Create an On-Demand Capacity Reservation (Proactive)

If you know you’ll need specific capacity at specific times, reserve it in advance.

aws ec2 create-capacity-reservation \
  --availability-zone us-east-1a \
  --instance-type m5.xlarge \
  --instance-platform Linux/UNIX \
  --quantity 5 \
  --region us-east-1

This guarantees you have 5 m5.xlarge instances available in that AZ, even during peaks.

Option 5: Use Mixed Instance Types in Launch Template

Define a fallback list of instance types. If the primary type is unavailable, ASG tries the next on the list.

# Create Launch Template with multiple instance types
aws ec2 create-launch-template \
  --launch-template-name multi-type-template \
  --launch-template-data '{
    "ImageId": "ami-0abc123def",
    "InstanceType": "m5.xlarge",
    "SecurityGroupIds": ["sg-0abc123"]
  }' \
  --region us-east-1

# Create ASG with Overrides specifying fallback types
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-mixed-asg \
  --launch-template LaunchTemplateName=multi-type-template,Version=\$Latest \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --vpc-zone-identifier "subnet-1a,subnet-1b,subnet-1c" \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "multi-type-template",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.xlarge"},
        {"InstanceType": "m5a.xlarge"},
        {"InstanceType": "m6i.xlarge"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandPercentageAboveBaseCapacity": 100
    }
  }' \
  --region us-east-1

How to Run This

1. If you get the error immediately: try --instance-type m5a.xlarge or similar variant.
2. Check capacity in other AZs: aws ec2 describe-availability-zones.
3. Retry launch with --placement AvailabilityZone=us-east-1b.
4. For production: create an Auto Scaling Group with subnets in 3 different AZs so distribution is automatic.
5. For critical workloads: create a Capacity Reservation to guarantee capacity.

Is This Safe?

All options are safe. Changing instance type or AZ may affect performance and cost. Cross-AZ data transfer incurs charges (~$0.02/GB). Test failover behavior before going to production.

Key Takeaway

“InsufficientInstanceCapacity” is often a localized issue, not a regional one. Use multi-AZ ASGs and mixed instance types to eliminate single points of capacity failure. For critical applications, reserve capacity in advance.

---

Hit capacity limits during scaling? Connect with me on LinkedIn or X.