Fix AWS EC2 InsufficientInstanceCapacity Error: Meaning & Workarounds

InsufficientInstanceCapacity means AWS doesn’t have enough On-Demand capacity for your request right now, in the Availability Zone you asked for. It isn’t a bug in your template, a quota problem, or a billing problem, so every fix is about asking differently: wait a few minutes, request fewer instances, try another zone, or try another instance type. The twist most people miss is that this error also hits machines you already own. Restarting a stopped instance is one of only two moments AWS says it shows up.

Jake runs a small phone shop. His stock-and-billing app lives on one EC2 instance. EC2 is Amazon’s rental service for virtual computers, and an “instance” is one rented computer. One Saturday morning he tried to start it after a weekend stop, got a red error, and spent the day writing invoices by hand. That was about $400 in sales he would normally have rung up in the app.

(Jake and Ethan are this blog’s long-running pair: Jake asks the honest questions and Ethan explains. They’re a teaching device, so nothing here is “proven” by Jake trying something. Every fix below rests on AWS’s own documentation.) Ethan’s first words to him were the ones worth keeping: “Nothing is wrong with your account. Read the message, then change what you’re asking for.” The rest of this post is the long version, including the cases the short fixes skip: placement groups, Auto Scaling groups, Spot, and what to do when nothing on the list works.

What InsufficientInstanceCapacity actually means

Let’s translate the jargon first, because the error message assumes you already speak it. An instance type is the size and flavor of rented computer you pick, like m5.large: how many virtual CPUs, how much memory. A Region is a geographic area such as Ohio or Mumbai. An Availability Zone (AZ) is one separate data-center location inside a Region. On-Demand just means you pay as you go, with no long-term deal.

Now the error. AWS says you get it in two situations: when you try to launch a new instance, or when you restart a stopped one. The stated cause is that AWS doesn’t currently have enough available On-Demand capacity to fulfill your request. AWS adds a line worth remembering: capacity can shift frequently. This is a snapshot of one moment, not a verdict on your account.

Here’s how the message looks when you launch from the command line:

An error occurred (InsufficientInstanceCapacity) when calling the
RunInstances operation (reached max retries: 4). We currently do not
have sufficient capacity in the Availability Zone you requested.

Ethan: “Picture a multi-story parking garage. Each floor is an Availability Zone, and each kind of vehicle needs its own kind of slot. You drove up to floor two asking for a truck slot, and floor two has none free right now. The garage isn’t closed. Floor three might have plenty, and a smaller vehicle might fit floor two just fine.”

That’s an analogy, not a floor plan. AWS’s documentation doesn’t describe how its capacity is physically arranged, so this post won’t pretend to.

What this error is not: a quota problem (that’s a different error, covered next), a permissions problem, or a broken launch template. If you spend an hour rewriting your template because of this message, you’re fixing the wrong thing.

Read the error before you touch anything

The single best habit is to read the whole message, slowly, before you click anything. Look at the (reached max retries: 4) fragment above. It tells you the tool already tried again several times on its own, so mashing the button for the next ten seconds is unlikely to change anything. (The CLI, short for command line interface, is a program where you type AWS commands instead of clicking around the AWS website, which AWS calls the console.)

Here’s the surprise. The version of this message that Auto Scaling shows is chattier. It says AWS is working on provisioning additional capacity, and that you can currently get that instance type by not specifying an Availability Zone, or by choosing from a list of zones it names. The error can literally hand you the workaround. Scroll to the end of the message before you go searching for answers.

Half the “capacity” errors people paste into forums are really something else. This decoder sorts them out:

If your message doesn’t match the first row, skip this post’s capacity fixes and go to the row that does.

Jake: “Should I file a quota increase just in case? It can’t hurt.”

Ethan: “It can’t hurt, and it can’t help. A quota is your own ceiling. Capacity is AWS’s shelf. Raising the ceiling doesn’t stock the shelf.”

Why a cloud that never seems to run out sometimes does

Why would a cloud that advertises endless computers ever say no? The honest answer from the documentation is short: AWS didn’t have enough available On-Demand capacity for that request at that moment. AWS doesn’t publish a forecast, a schedule, or the internal reasons. Anyone who hands you a confident mechanism, or a “busiest hour of the week,” is guessing.

What the docs do give us is the shape of the problem. The Auto Scaling troubleshooting page talks about the requested instance type and Availability Zone combination. Think of a grid, with instance types down the side and zones across the top. Your request landed on a full square. Every fix in this post tries a different square, asks for less of it, or comes back when the square has changed.

Ethan: “It’s Friday night at a restaurant. You want a table for six at seven o’clock, and it’s gone. A table for two might be free. The place next door might have a six-top. Eight o’clock might be wide open. You don’t argue with the host. You change the question.”

Now the part that surprises people: why can a machine you already own fail to start? AWS’s documentation says that when you start a stopped instance, it’s typically migrated to a new underlying host computer. A start isn’t waking the same machine from sleep. It usually means landing on new hardware, so it isn’t hard to see why a start can fail the way a brand-new launch can. AWS’s stated answer for machines that must always come back is to reserve capacity ahead of time, which we’ll get to in the Capacity Reservations section.

Two more things raise your odds of this error, straight from AWS: big requests (there’s a reason the docs suggest splitting 15 instances into smaller requests) and cluster placement groups, especially when you add instances later or mix types. Both get their own sections below.

The fix ladder: cheapest move first

Work down this list in order. The steps run from cheapest and least disruptive to most drastic, and most people never need step five. This ladder is for new launches. If the failing action is starting an instance that was already running before, jump to the stopped-instance section, because your options differ.

1. Wait a few minutes, then send the same request again. That’s AWS’s first suggestion, and the reason is the line we saw earlier: capacity can shift frequently. “A few minutes” means minutes, not seconds, since your tool already retried on its own. Use the wait productively by preparing steps two through four while the clock runs.
2. Ask for fewer instances. If you requested 15 in one go, AWS suggests trying 3 requests for 5, or 15 requests for 1. Smaller requests can fit where a big one can’t. Even partial success is progress: three of your fifteen running beats zero, and you can keep trying for the rest.
3. Change the zone. How you do this depends on your network setup. A VPC (virtual private cloud) is your private slice of the AWS network, and every account comes with a default one. In the default VPC, AWS says you can submit the launch without specifying an Availability Zone and let AWS place it. In a non-default VPC, your launch is tied to a subnet (a section of your network that lives in one zone), so the fix is to choose a subnet in a different Availability Zone. From the CLI, that means passing a different subnet in the command:

   aws ec2 run-instances \
       --image-id ami-0abcdef1234567890 \
       --instance-type m5.large \
       --subnet-id subnet-0abc1234def567890

   (The IDs above are placeholders. Swap in your own.)
4. Change the instance type. AWS’s advice is to submit the launch again with a different instance type, which you can resize later. A neighboring size or a different family of the same general kind is the usual move. Two cautions: you pay the rate of whichever type you end up on, and not every type fits every setup. The instance-type section covers compatibility.
5. Move the instance to another Availability Zone. You can’t drag an existing instance across zones. You copy it, using an image of its disk. That’s the most drastic step here, so it has its own walkthrough.
6. Contact AWS Support. If the error follows you across zones and across types, you’re past self-service. More on what to send in the “when nothing works” section.

When it’s your own stopped instance that won’t start

This is Jake’s Saturday. He clicked Start instance and got the error. First, the reassurance: AWS says that when you stop an instance, it’s not deleted. A failed start just leaves it stopped, waiting for you. Please don’t terminate it out of frustration. Terminate is the button for “I no longer need this,” and it’s the wrong tool here.

Your options for a stopped instance are narrower than for a new launch, because you can’t relaunch an existing instance in another zone. You can retry the start, change its type, or copy it into another zone. In that order:

First, wait and retry the start

Give it a few minutes, then try again. In the console, select the instance and choose Instance state, then Start instance. From the CLI it’s aws ec2 start-instances --instance-ids i-1234567890abcdef0, with your own instance ID in place of the example.

Second, change the instance type while it’s stopped

This works for an instance whose root volume is EBS (the network disk that holds its operating system) and whose current setup is compatible with the new type. Because the instance is already stopped, you’re halfway there. The steps, from AWS’s documentation:

1. Open the Amazon EC2 console, choose Instances, and select your instance. Confirm its state is stopped. The change option is grayed out otherwise.
2. Choose Actions, then Instance settings, then Change instance type.
3. Under Instance type, pick the new one. If the type you want isn’t in the list, it isn’t compatible with this instance’s configuration. Your route then is launching a new instance from an image instead (see the next section).
4. Choose Change to accept.
5. Select the instance again and choose Instance state, then Start instance. It can take a few minutes to reach running.

Windows instance? AWS recommends updating the PV driver package before changing type, and for Windows Server 2016 or 2019 with EC2Launch v1 there’s an initialization script to run afterward. Be careful with that script, since the administrator password resets unless you change the settings first. AWS documents how.

Third, copy it into another zone

If retrying and retyping both fail, go to the AMI route. One more note for people who use hibernation (saving memory contents to disk so the instance resumes where it left off): AWS says Capacity Reservations do not ensure that a hibernated instance can resume after you try to start it.

Moving to another Availability Zone (the AMI route)

AWS is blunt about this: you can’t move an existing EC2 instance to another subnet, Availability Zone, or VPC. Instead you create an AMI (Amazon Machine Image, a saved copy of the instance’s disk plus its launch settings) and launch a new instance from it in a subnet in the zone you want.

Jake: “So my old server stays where it is, and I build a twin somewhere else?”

Ethan: “A twin, yes. Then the twin becomes the real one.”

1. Optional speed-up: AWS says you can decrease AMI creation time by creating an EBS snapshot of the volume first.
2. Create the AMI and launch the copy. The shortcut is an AWS Systems Manager Automation runbook (a ready-made automated procedure) called AWSSupport-CopyEC2Instance. Give it the instance ID and the destination subnet ID. It creates the AMI and launches the new instance in that subnet. Run it in the same Region as the existing instance, and leave the Region input alone unless you’re crossing Regions. Watch progress under Automation in the Systems Manager console. Prefer doing it by hand? Launch an instance from the AMI and choose the destination subnet.
3. Reassign Elastic IP addresses from the old instance to the new one, if you use them.
4. Windows in a domain? AWS warns that domain security identifier (SID) conflicts can occur when the new instance launches and tries to contact the domain. Plan for that.
5. Back up instance store volumes separately. Creating an AMI doesn’t automatically snapshot them.
6. Retire the old instance only after you’re happy the new one is doing the old one’s job. Anything that pointed at the old instance’s address needs a look too.

If the target zone also throws the capacity error when launching the copy, that’s useful information. Go back to the ladder and change the instance type on the new launch too.

Placement groups: the special case that trips people up

A placement group tells AWS how to physically position your instances relative to each other. A cluster group packs them close together for fast networking. Spread and partition groups do the opposite, to reduce the chance that one hardware failure takes out several of your instances at once. AWS says you can get a capacity error when launching into a cluster placement group, and the rules for avoiding it are specific.

For cluster groups, AWS recommends two habits. Use a single launch request for the number of instances you need, and use the same instance type for all of them. If you add instances later, or launch more than one type in the group, you increase your chances of getting the error. And the stopped-instance trap applies here too: a stopped instance in a placement group stays in the group when restarted, but the start fails if there isn’t enough capacity for it.

AWS gives a specific recovery step. If you get a capacity error when launching into a cluster group that already has running instances, stop and start all of the instances in the group, then try the launch again. Starting them might migrate them to hardware that has capacity for all the requested instances.

Other rules that bite: cluster placement groups don’t support burstable performance instances (the T2 family, for example), Mac1 instances, or M7i-flex instances. A cluster group can’t span multiple Availability Zones. Capacity Blocks (covered below) don’t support placement groups. And a rack-level spread group supports a maximum of seven running instances per zone, so an eighth in the same zone simply won’t launch. That last one isn’t a capacity error, but it feels exactly like one at 11 p.m.

Jake: “So the fast network costs me flexibility?”

Ethan: “It does. Cluster groups are like booking one whole row at the cinema instead of scattered seats. Great if you get the row, awkward when someone else already holds half of it.”

Auto Scaling groups: when the error hits at 2 a.m.

An Auto Scaling group is AWS’s way of automatically adding and removing instances as your workload changes. When it can’t launch one, the group’s activity history records an InsufficientInstanceCapacity or UnfulfillableCapacity error. The good news: the group isn’t giving up. For Spot it keeps trying, and for On-Demand it works with the zones you enabled. The bad news: it can only work with the options you gave it.

AWS’s guidance for these launch failures comes down to giving the group more squares on the grid:

• Specify more instance types. AWS calls it a best practice to specify at least 10 different instance types or families in the group’s overrides. The more you list, the less likely a launch failure.
• Use attribute-based instance selection. Instead of naming types, you describe what you need, such as vCPU count, memory, or family and generation, and the group picks matching types. You can preview the matches, and by default the feature avoids selecting the most expensive instances. A “price protection” attribute controls that limit.
• Enable more Availability Zones. AWS suggests adding more, or all, of the zones in the Region, which spreads instances out and increases overall availability of instance types.
• Set an On-Demand base capacity. That keeps a minimum number of On-Demand instances running even when Spot is unavailable.
• Pick a sensible Spot allocation strategy. AWS calls price-capacity-optimized a best practice for reducing interruptions because it weighs both price and availability. The lowest-price strategy looks only at cost and can raise interruption rates.
• Consider Capacity Rebalancing. It warns you when a Spot Instance is at elevated risk of interruption and proactively replaces it. AWS notes it doesn’t fit every use case and can interact awkwardly with your allocation strategy, so read the trade-offs first.
• Reserve specific types with On-Demand Capacity Reservations if a particular type in a particular zone must be available.

Ethan: “A group that lists one instance type is a one-legged stool. It stands fine until the day someone leans on it.”

Two reservation-related messages deserve a warning label. If the group targets a specific Capacity Reservation and you see “The requested reservation does not have sufficient compatible and available capacity,” you’ve used up what that reservation holds. AWS suggests either raising the reserved amount or using a Capacity Reservation group, so anything beyond the reserved capacity launches as regular On-Demand. With Capacity Blocks, terminating instances need several minutes to finish cleaning up before their space is reusable, and AWS advises scaling in about 30 minutes before the block ends.

Also compare what the group says with what you set. An instance type may simply be missing from a zone you enabled, and AWS documents that failure with a different message (see the decoder table above). Fix it by updating or removing that zone’s subnet.

Spot Instances: a different kind of “no”

Spot Instances are spare EC2 capacity sold at a lower price than On-Demand. AWS can take them back, and sometimes there simply isn’t any spare to sell. In that case you see “There is no Spot capacity available that matches your request.” It’s a cousin of the error in this post, but the advice is different, and it’s opposite in one surprising way.

Here’s that surprise. For a Spot Instance or Spot Fleet request, AWS says don’t change the request. Spot requests continue to make launch attempts automatically, and Amazon EC2 fulfills the request as soon as capacity is available. Cancelling and re-submitting isn’t obviously helpful. For the request status, look for the capacity-not-available code, which means there isn’t enough capacity for what you asked. A running Spot Instance stopped for instance-stopped-no-capacity was stopped for EC2 capacity management needs.

If you see the error often, the durable fix is flexibility. AWS’s advice is to be flexible about instance types and zones when you set up the workload. The capacity-optimized allocation strategy analyzes real-time capacity data and launches into the pools with the most available capacity. And here’s a tool many people never open: Spot placement score.

Using Spot placement score

You describe your Spot needs, and EC2 returns the top 10 Regions or Availability Zones where your request is likely to succeed. Each is scored from 1 to 10, where 10 means highly likely and 1 means unlikely. In the console, open Spot Requests, use the arrow beside Request Spot Instances, and choose Calculate Spot Placement Score. From the CLI it’s the get-spot-placement-scores command.

Three rules from AWS: you give it either instance types or instance attributes, never both in one request; it needs at least three different instance types (or attributes that resolve to three), otherwise it returns a low score; and there’s no additional charge. That second rule doubles as a lesson. If the tool needs three types to score you well, your one-type request was never flexible enough.

Reserving capacity for real: Capacity Reservations

Everything above reacts to the error. This section prevents it. An On-Demand Capacity Reservation reserves compute capacity in a specific Availability Zone for any duration. AWS describes it as reducing the risk of not being able to get On-Demand capacity at a critical time. AWS’s own Knowledge Center calls creating one in advance the best practice for critical machines.

How it works

A reservation matches instances on four attributes: instance type, platform (the operating system), Availability Zone, and tenancy (shared or dedicated hardware). By default, any instance with matching attributes automatically runs in it. That’s the open setting. With targeted, only instances that explicitly target the reservation can use it. In the console: Capacity Reservations, then Create Capacity Reservation. From the CLI:

aws ec2 create-capacity-reservation \
    --availability-zone az_name \
    --instance-type instance_type \
    --instance-count number_of_instances \
    --instance-platform operating_system \
    --instance-match-criteria open|targeted

Two traps. First, platform matching: the reservation’s platform must match the AMI. For most Linux distributions, including Ubuntu, that’s Linux/UNIX, but SUSE and Red Hat Enterprise Linux have their own platform values. Second, an open reservation silently swallows any running instance with matching attributes when it becomes active. If you don’t want that, choose targeted.

The reservation only works once it reaches the active state. Instances launched by AWS services on your behalf, including Auto Scaling, ECS, EKS, EMR, Batch, and Elastic Beanstalk, are eligible to use it as well.

What it costs

Be sober about this part, because it’s where surprises land on your bill. AWS charges Capacity Reservations at the equivalent On-Demand rate whether you run instances in them or not, and unused capacity shows up on your bill as an unused reservation. When an instance runs inside the reservation, you pay for the instance and nothing extra for the reservation. AWS’s example: reserve 20 instances, run 15, and you’re billed for 15 active and 5 unused.

AWS’s billing doc uses an example rate of $0.10 per hour for an m4.large. On that example rate (not a current price), one unused reserved instance would cost about $72 for a 30-day month (24 hours × 30 days × $0.10). Five unused would cost about $360. Billing starts as soon as the reservation is provisioned and continues until you cancel it. Savings Plans and Regional Reserved Instances can discount the charge, but zonal Reserved Instance discounts don’t apply to Capacity Reservations.

Limits worth knowing before you plan around it

• Reservations count toward your On-Demand instance quota, even active and unused ones. You can reserve as many as your quota allows, minus the instances already running.
• Creating a reservation can itself fail if EC2 doesn’t have the capacity at that moment. AWS says to try later, try a different zone, or try a smaller request. That’s the whole point of reserving before the crunch.
• They can’t be used with Dedicated Hosts. Windows instances can’t use them with Bring Your Own License.
• They work in cluster placement groups but not spread or partition groups.
• They aren’t transferable between accounts, though you can share them.

Planning ahead: future-dated reservations and Capacity Blocks

AWS announced future-dated Capacity Reservations on October 3, 2025. You request one between 5 and 120 days ahead, and AWS recommends at least 56 days (8 weeks) in advance. The minimum commitment is 14 days for C, G, I, M, R, and T instances, and 12 weeks for U and X. You need at least 32 vCPUs in total, so at least 8 instances of an m5.xlarge. And they’re for covering incremental instances, not existing running ones.

For GPU work, there are Capacity Blocks for ML. You reserve GPU instances for a window starting up to eight weeks out, for one to 14 days or multiples of seven up to 182 days, with up to 64 instances per block and 256 across blocks. AWS recommends them when you need GPUs for days or weeks and don’t want to pay for a reservation while they sit idle.

Jake: “But that means paying for a computer I’m not even using!”

Ethan: “Sometimes, yes. That’s what insurance feels like until the Saturday you need it.”

Instance-type flexibility without breaking your app

“Try a different instance type” sounds easy until your app refuses to run on it. A few documented constraints decide which alternatives are safe.

Find what a zone offers. The CLI command describe-instance-type-offerings lists the instance types offered in a Region or Availability Zone. To see what one zone offers:

aws ec2 describe-instance-type-offerings \
    --location-type availability-zone \
    --filters Name=location,Values=us-east-2a \
    --region us-east-2

You can also filter by instance type to see whether a specific one is offered. In the console, the Instance types page shows the Availability Zones for each type. Keep the limits of this tool in mind: an offering tells you a type exists in that zone, not that there’s room today. Newer types might not be available in every zone yet, and older ones might not be offered in newer zones.

Match the architecture. If the alternative uses an Arm-based AWS Graviton processor instead of an Intel Xeon, you need an Arm-compatible AMI. An Intel-built AMI won’t simply come along.

Check disk limits. The number of EBS volumes you can attach depends on the instance type and size. AWS says you can’t change to a type that doesn’t support the number of volumes already attached.

Remember the bill. When you change the instance type, you start paying the rate of the new type. AWS also points to AWS Compute Optimizer, a service that recommends the instance type best suited to your existing workload, if you want a second opinion on what to pick.

Know the exclusions. Cluster placement groups exclude burstable types, Mac1, and M7i-flex. Spot Instances can’t be resized in place. If a type isn’t in the “Change instance type” list, it’s incompatible with that instance’s configuration.

The practical advice: before the crunch, decide which two or three alternatives your app can survive on, and write them down. When you’re staring at a red error with a customer waiting is a bad time to discover your app only runs on one architecture.

Where else this error shows up: EMR, ParallelCluster, Dedicated Hosts

The same shortage surfaces under different names when other AWS services launch instances for you.

Amazon EMR (a service for running big-data clusters) reports an event code, EC2 provisioning - Insufficient Instance Capacity, when the chosen zone can’t fulfill a cluster start or resize. AWS’s advice is to wait for capacity to recover, since capacity shifts frequently and the cluster will start or finish resizing once it’s available. The alternative is to terminate the cluster, change the instance type configuration, and create a new one.

AWS ParallelCluster (a tool for building high-performance computing clusters) shows the error in slurm_resume.log when a job fails to run, in clustermgtd.log when cluster creation fails, or as nodes in a DOWN state with the reason code InsufficientInstanceCapacity. Its documentation points you to the same Knowledge Center article this post follows.

Dedicated Hosts (physical servers reserved for your use) can produce a similar “has insufficient capacity” failure. This is the one variant where the documentation I found offers no fix. AWS says Capacity Reservations can’t be used with Dedicated Hosts, so the usual prevention tool is off the table. If you hit it, treat it as a question for AWS Support.

The popular advice that’s wrong

Search this error and you’ll find confident advice that doesn’t hold up against AWS’s own documentation. Here are the ones to ignore.

“Request a quota increase.” A quota increase fixes InstanceLimitExceeded. It does nothing for a capacity shortage. If anything, reserving capacity consumes your quota.

“Raise your Spot maximum price.” AWS says a high maximum price doesn’t guarantee availability. Flexibility across types and zones does more.

“Buy a Reserved Instance or Savings Plan so you always have capacity.” Regional Reserved Instances reserve no capacity, and AWS’s ParallelCluster documentation says plainly that with them you can still get insufficient capacity errors. Savings Plans are a discount. If you need a seat, you need a Capacity Reservation or a zonal Reserved Instance.

“Keep retrying every few seconds.” Your tool has already retried on its own, and AWS’s advice is to wait a few minutes. Spend the wait changing what you ask for.

“Terminate it and start fresh.” A stopped instance isn’t deleted, and a failed start doesn’t change that. Terminating gives up the machine you were trying to keep.

“Cancel the Spot request and submit a new one.” For Spot, AWS says leave the request alone, since it continues to retry on its own.

When nothing works

Let’s be honest about the limits here. If AWS truly has no capacity for what you need in the places you’re allowed to ask, no setting on your side can conjure it. Even a Capacity Reservation can’t be created without available capacity. So when everything above has failed, work through this list:

1. Re-read the exact error. Make sure it really is a capacity error and not a limit, a permission, or an unsupported-configuration message. The decoder table earlier is built for this.
2. Confirm you changed both dimensions. A different zone with the same type and a different type in the same zone are separate attempts. Try the combination (steps three and four together).
3. Consider another Region. That’s a bigger move, and it means copying your AMI across, so weigh latency and where your data has to live. For Spot workloads, Spot placement score can compare Regions.
4. Contact AWS Support. AWS’s Knowledge Center says that if the error continues after you move the instance, you might have an account-level restriction, and Support is the route to resolve it. Send the exact error text, the Region and Availability Zone, the instance type and purchase option, whether it’s a launch or a restart, whether a placement group or Auto Scaling group is involved, and what you’ve already tried. A support case with those details starts halfway to solved.
5. Plan the recurrence away. For planned needs like a launch or a sale, a future-dated reservation can be requested 5 to 120 days ahead.

Notice what’s not on the list: waiting forever. If the error has lasted many hours across many zones and types, treat it as a support ticket, not as bad luck.

Designing so it can’t ruin your Saturday again

You can’t prevent AWS from being short of capacity somewhere. You can make sure your workload doesn’t care. Here’s the checklist, pulled from AWS’s own guidance:

• Reserve the irreplaceable. Give the one machine you can’t lose an On-Demand Capacity Reservation in its zone.
• Stay flexible everywhere else. In Auto Scaling groups, list at least 10 instance types or families, and enable multiple zones.
• Launch in one shot, with one type, for cluster placement groups.
• Know your alternates. Write down which instance types your app can run on before you need them.
• Watch the reservation. AWS provides CloudWatch metrics for Capacity Reservation usage and events for underutilization, so an idle reservation doesn’t quietly drain your budget.
• Think twice before stopping a critical machine if it has no reservation behind it. A stop is a fresh chance for a start to fail.

Remember Jake’s $400 Saturday? On AWS’s example rate of $0.10 per hour, holding one reserved instance for his billing server would run about $72 a month (again, an illustration, not a quote). Whether that’s worth it depends on how much a lost Saturday costs your shop. It’s the same trade Ethan described: a small, steady cost against a rare, painful one. If Jake had made it, his Saturday would have started with a running app instead of a red error.

Frequently asked questions

What does the InsufficientInstanceCapacity error mean in EC2?

It means AWS doesn’t currently have enough available On-Demand capacity to fulfill your request. It appears when you launch a new instance or restart a stopped one. It concerns that instance type, quantity, and Availability Zone at that moment, not a mistake in your configuration.

Is this my fault, or is AWS out of capacity for everyone?

Neither, strictly. It’s specific to what you asked for: that type, that number, that zone, right now. Someone requesting a different type or zone may launch fine. If it persists after you’ve tried other zones and types, AWS’s Knowledge Center says an account-level restriction is possible, and AWS Support is the route.

How long should I wait before trying again?

AWS says to wait a few minutes because capacity can shift frequently. It doesn’t publish a specific timeline. Your tool has already retried several times by the time you see the message, so seconds won’t help. Use the wait to prepare a different zone or type.

Will a service quota increase fix InsufficientInstanceCapacity?

No. Quotas cap how many instances your account may run, and hitting one shows up as InstanceLimitExceeded, or as “instance(s) are already running” in Auto Scaling. Capacity errors come from AWS not having room for the request, so raising your ceiling doesn’t change anything.

Why can’t I start my stopped EC2 instance?

If the message is InsufficientInstanceCapacity, restarting is one of the two moments AWS says it appears. A start typically moves the instance to new hardware, and that placement can fail. Retry after a few minutes, then try changing the instance type, then copy it into another zone with an AMI.

Should I terminate the instance and launch a new one?

No. AWS says stopping doesn’t delete an instance, so a failed start just leaves it waiting. Terminating is what you do when you no longer need the machine. Change its type, retry, or copy it into another zone with an AMI instead.

How do I launch in a different Availability Zone if I use a non-default VPC?

Choose a subnet that lives in a different Availability Zone. Leaving the zone unspecified only helps in the default VPC. With the CLI, pass a different subnet ID to run-instances, then retry the launch.

Can I change the instance type of a stopped instance to get around it?

Yes, for an EBS-backed instance with a compatible type. Stop it, choose Actions, Instance settings, Change instance type, pick another type, then start it. If the type isn’t listed, it isn’t compatible with that instance’s configuration. You can’t change the type of a Spot Instance.

Can I move an existing EC2 instance to another Availability Zone?

Not directly. AWS says you must create an AMI from the instance and launch a new instance from it in a subnet in the target zone. The AWSSupport-CopyEC2Instance runbook automates this. Afterward, reassign Elastic IP addresses and back up instance store volumes separately.

Why does my cluster placement group keep throwing capacity errors?

AWS says adding instances to a cluster placement group later, or mixing instance types in it, raises your odds of the error. Launch everything in one request with one type. If a launch fails while instances are already running, stop and start all of them, then try again.

How do I stop my Auto Scaling group from failing with UnfulfillableCapacity?

Give it options: at least 10 instance types or families, attribute-based instance selection, more Availability Zones, an On-Demand base capacity, and for Spot the price-capacity-optimized allocation strategy. Read the group’s activity history to see which combination failed.

What is the difference between this error and the no Spot capacity available error?

The On-Demand error is about pay-as-you-go capacity. The Spot error is about spare capacity sold at a lower price. For Spot, AWS advises not changing the request, since Spot requests keep retrying, and staying flexible on instance types and zones.

Does a higher Spot maximum price guarantee capacity?

No. AWS says a high maximum price doesn’t guarantee Spot Instance availability, and Spot Instances can be terminated even when your maximum exceeds the Spot price if there isn’t enough capacity. Flexibility across types and zones does more than a bigger number.

What is an On-Demand Capacity Reservation, and does it guarantee capacity?

It reserves capacity for a specific instance type, platform, zone, and tenancy for as long as you keep it. Once active, matching instances can launch into it. You pay the On-Demand rate whether you use it or not. Creating one can fail if AWS lacks capacity at that moment, so do it before the crunch.

Do Savings Plans or Reserved Instances protect me from this error?

Not automatically. Regional Reserved Instances reserve no capacity, and Savings Plans are a billing discount. Zonal Reserved Instances and Capacity Reservations do reserve capacity in a zone. AWS says you can combine Capacity Reservations with Savings Plans or Regional Reserved Instances to get a discount.

What should I tell AWS Support if the error keeps happening?

Give the exact error text, Region, Availability Zone, instance type, purchase option (On-Demand or Spot), and what you already tried, such as other zones and types. Say whether it’s a launch or a restart of a stopped instance, and whether a placement group or Auto Scaling group is involved.

Revision note. Written September 2026, covering Amazon EC2 On-Demand launches and restarts, Spot Instances, Auto Scaling groups, placement groups, and Capacity Reservations as AWS documents them. Console labels, quotas, and reservation rules change over time, so this post will be revised if AWS renames a setting or changes how reservations work. If you’ve been staring at that red error while a customer waits, take a breath: it almost never means you did anything wrong, and one of the steps above is very likely to get you moving again.