Yeah, that error drives everyone up the wall. You're staring at a red status check, and AWS is basically saying "we don't have room for you." But here's the thing—you don't need to wait it out or beg support. The fix is almost always a simple stop and start.
The Fix: Stop and Start the Instance
- Go to the EC2 console, select the instance, and choose Instance State → Stop.
- Wait until the instance shows
stoppedstatus. Don't rush—it can take a minute or two. - Then select Instance State → Start.
That's it. The instance comes back with a fresh host allocation. If the capacity problem was limited to a specific physical host, you're now on a different one, and the status check usually clears within a few minutes.
Why This Works
When you stop and start an EC2 instance, you're essentially releasing the old host and asking AWS to place you on a new one. The "insufficient capacity" error means the specific host you're on (or the one you tried to launch on) doesn't have spare CPU or memory for your instance. A stop and start forces a new placement. It's the fastest way to escape a bad neighborhood.
Rebooting won't help—that just restarts the OS on the same host. You need that stop/start to change the physical location.
What If Stop/Start Doesn't Fix It?
Sometimes the issue is broader. Maybe the entire Availability Zone (AZ) is low on capacity for your instance type, not just one host. Here are a few variations to try:
1. Change the Instance Type Temporarily
Start with a larger or different type, then resize back. For example, if you're running a t3.medium and it's stuck, try t3.large or t3.small. This can get you onto a different host pool. After it's running, you can resize back to the original type (stop, change type, start again) — just make sure the target type is available in that AZ.
2. Use a Different Availability Zone
If you're in us-east-1a, try us-east-1b. You can do this by creating an AMI from the instance and launching a new one in another AZ. You'll need to update the Elastic IP or change the security group rules if you're using public IPs.
# Create an image from the stuck instance
aws ec2 create-image --instance-id i-1234567890abcdef0 --name "my-instance-backup" --no-reboot
# Launch a new instance in a different AZ
aws ec2 run-instances --image-id ami-xyz --instance-type t3.medium --availability-zone us-east-1b
This is a bit more work, but it's a solid fallback when a whole AZ is tight.
3. Check for Dedicated Host or Placement Group Restrictions
If your instance is in a placement group or uses a dedicated host, those add constraints. The capacity issue might be specific to that placement group's physical rack. Removing the instance from the placement group (or using a dedicated host with different settings) can help.
Prevention: Don't Get Caught Again
- Use a mix of instance types in an Auto Scaling group. If one type is scarce, the ASG can fall back to another. This is the best long-term fix for critical workloads.
- Spread your instances across multiple AZs. Don't put all your eggs in one basket. Use a load balancer and spread the load.
- Consider On-Demand Capacity Reservations. If you absolutely need a specific instance type in a specific AZ, a Capacity Reservation guarantees it — but you pay for the reservation even if the instance is stopped.
- Keep a backup AMI ready. If you ever need to launch in a different AZ, having a current AMI saves you from a panic.
Also, monitor your AWS service health dashboard. If capacity issues are widespread, you'll see it there. But honestly, most of the time it's a local blip, and a stop/start solves it in under five minutes.
One More Thing
If you're launching a brand new instance and get this error, just change the AZ or instance type in the launch wizard. Don't keep retrying the same one—that's the definition of insanity. And if you're using Spot Instances, this error is more common. Spot capacity fluctuates, so have a fallback plan with On-Demand if your workload is time-sensitive.
That's it. Stop, start, done. You're welcome.