RDS InsufficientDBInstanceCapacity: What It Means, the Fastest Workarounds, and the New On-Demand Capacity Reservations for RDS and Aurora (Pricing, Setup, Multi-AZ, Future-Dated Reservations)

InsufficientDBInstanceCapacity means AWS has no free capacity for the DB instance class you asked for in that Availability Zone, right now. It is not a quota and not a fault in your account. Your create, restore, start or resize simply cannot be placed. The quick fixes: try another Availability Zone, another instance class or generation, or retry a little later. Since October 21, 2026 there is also a lasting fix: On-Demand Capacity Reservations for RDS and Aurora hold capacity for a class, engine and set of AZs until you release it. You then launch into that capacity with --db-capacity-reservation-identifier. The catch that surprises people is the bill: a reservation is charged at full on-demand rates whether or not anything runs in it. Five unused slots of an instance at $0.168 an hour cost about $613 a month for capacity you are only holding.

Jake's shop was moving its stock database from a server in the back room to RDS on a Sunday night, the only quiet window of the week. The restore from snapshot failed at 11 p.m. with InsufficientDBInstanceCapacity, and Ethan spent forty minutes trying instance sizes and zones while the old server sat half shut down. "Next time," he said once it finally worked in another zone, "we book the table before we turn up at the restaurant."

This guide explains the error, gives the workarounds in the order that usually works fastest, and then covers the new RDS and Aurora capacity reservations in full: how to create and use one, what it costs, Multi-AZ, future-dated reservations for a planned migration or peak, and the stop-and-start behavior that can strand an instance. If RDS itself is new to you, start with what Amazon RDS is.

What InsufficientDBInstanceCapacity means

Every RDS DB instance runs on hardware in one Availability Zone, one of a Region's separate data centers. AWS keeps spare capacity for each instance type in each zone, but it is finite, and popular types in busy zones occasionally run out for a while. When your request needs a db.r7g.large in us-east-1a and none is free, RDS refuses it with:

An error occurred (InsufficientDBInstanceCapacity) when calling the CreateDBInstance operation: ...

The RDS API documents this error as "The specified DB instance class isn't available in the specified Availability Zone." It can come from any operation that needs new compute: CreateDBInstance, creating a read replica, RestoreDBInstanceFromDBSnapshot or a point-in-time restore, ModifyDBInstance to a new class, and StartDBInstance on a stopped instance. That last one surprises people: stopping an instance releases its hardware, so starting it again needs capacity like a brand-new instance. Aurora clusters have a sibling error, InsufficientDBClusterCapacity.

It is not your account's DB instance quota (that error mentions a quota or limit), and it is not a subnet running out of IP addresses (that is a separate error; see "not enough free addresses in subnet"). EC2 has the same problem under the name InsufficientInstanceCapacity, and the EC2 version works the same way.

Jake: "So the restaurant was full, not closed."

Ethan: "Full at that table, in that room, at that hour."

How to fix it now, fastest first

1. Try another Availability Zone. Leave out --availability-zone and let RDS choose, or name a different zone. Your DB subnet group must include subnets in the zones you want to use; a subnet group covering three zones gives RDS three chances.
2. Try the same size in another generation or family: db.r6g.large instead of db.r7g.large, or the Intel or AMD variant. Check that your engine version supports the class.
3. Try one size smaller or larger to get the database running, then modify it back during a quieter period.
4. Wait and retry. Capacity frees up as other customers stop and resize; retries a few minutes apart often succeed. For automation, retry with backoff rather than in a tight loop.
5. For Multi-AZ, both the primary and the standby need capacity, so a failure can come from either zone. Creating as Single-AZ and converting to Multi-AZ later is a fallback for urgent cases.
6. For a stopped instance that will not start, the same tricks apply: start it after modifying its class, or restore its latest snapshot into another zone.

Ethan's Sunday-night fix was step 1 in the end: the restore that failed in us-east-1a succeeded at once in us-east-1c. The forty minutes went on steps 2 and 3, which he tried first because he had pinned the zone in his script.

Which zones offer your instance class? Check before you retry

Step 1 of the fix, another Availability Zone, only helps if the class is offered there at all. Not every class is sold in every zone, and retrying in a zone that never offers it fails forever. One call lists the zones where your engine offers the class:

aws rds describe-orderable-db-instance-options \
  --engine postgres \
  --db-instance-class db.r7g.large \
  --vpc \
  --query "OrderableDBInstanceOptions[].AvailabilityZones[].Name" \
  --output text | tr '\t' '\n' | sort -u

The result is a list such as us-east-1a, us-east-1b, us-east-1c. Add --engine-version to check a specific version, because newer classes are often offered only for newer engine versions. Two things this list does not tell you:

• Whether there is free capacity right now. "Offered" means RDS sells the class in that zone; it can still be temporarily out of it, which is exactly what InsufficientDBInstanceCapacity says. Only a launch, or a capacity reservation, proves capacity.
• Whether your network can use the zone. RDS can only place the database in zones covered by your DB subnet group. Compare the list with the zones of the subnets in your subnet group (aws rds describe-db-subnet-groups), and add a subnet in another zone if your group covers only one or two.

The same check works for Aurora with --engine aurora-postgresql or --engine aurora-mysql, where the error is InsufficientDBClusterCapacityFault for cluster-level capacity.

Automating it: a boto3 restore that walks the zones

If a script or pipeline restores or creates databases, build the fallback into it instead of fixing it by hand at midnight. This function tries each zone that offers the class, moves on only when the error is a capacity error, and waits longer between rounds:

import time
import boto3
from botocore.exceptions import ClientError

rds = boto3.client("rds", region_name="us-east-1")


def zones_for(engine, db_class, version=None):
    """Zones where this engine offers this class (offered, not guaranteed free)."""
    kw = {"Engine": engine, "DBInstanceClass": db_class, "Vpc": True}
    if version:
        kw["EngineVersion"] = version
    zones = set()
    for page in rds.get_paginator("describe_orderable_db_instance_options").paginate(**kw):
        for opt in page["OrderableDBInstanceOptions"]:
            zones.update(z["Name"] for z in opt["AvailabilityZones"])
    return sorted(zones)


def restore_anywhere(snapshot, new_id, db_class, zones, subnet_group, rounds=3):
    for attempt in range(rounds):
        for az in zones:
            try:
                r = rds.restore_db_instance_from_db_snapshot(
                    DBInstanceIdentifier=new_id,
                    DBSnapshotIdentifier=snapshot,
                    DBInstanceClass=db_class,
                    AvailabilityZone=az,
                    DBSubnetGroupName=subnet_group,
                )
                print("restoring in", az)
                return r["DBInstance"]["DBInstanceIdentifier"]
            except ClientError as e:
                if e.response["Error"]["Code"] != "InsufficientDBInstanceCapacity":
                    raise
                print("no capacity in", az)
        time.sleep(60 * (attempt + 1))
    raise RuntimeError("no capacity in any zone; try another class")

Run against the RDS API model with the first zone answering InsufficientDBInstanceCapacity, it does what you want at 2 a.m.:

zones: ['us-east-1a', 'us-east-1b', 'us-east-1c']
no capacity in us-east-1a
restoring in us-east-1b
result: shop-db-restored

Three details make it safe to leave running. It checks the error code, not the message, so a permissions error or a missing snapshot still stops the script instead of being retried forever. It returns as soon as RDS accepts the request, because the restore itself then continues in the background. And it gives up after a few rounds with a clear message, which is your cue to fall back to another class (step 2 of the fix) or to a capacity reservation for next time. The same pattern works for create_db_instance and modify_db_instance; for a restore into reserved capacity, add DBCapacityReservationIdentifier to the call.

Ethan put a version of this into Jake's restore script the Monday after. "Next time it can hunt for a zone while I sleep," he said.

The lasting fix: RDS On-Demand Capacity Reservations

A Capacity Reservation holds compute for one combination of DB instance class, engine, license model (for engines with more than one) and one or more Availability Zones, with the same number of instances reserved in each zone. While it is active, launches that target it do not fail for lack of capacity. Creating one takes a single command:

aws rds create-db-capacity-reservation \
  --db-capacity-reservation-name shop-migration \
  --engine postgres \
  --db-instance-class db.r7g.large \
  --availability-zones us-east-1a \
  --capacity-per-availability-zone 3

The reservation gets an ID starting with dbcr- and moves through states such as assessing, pending, scheduled and active (others are delayed, failed, unsupported, expired and cancelled). Check it, including how many slots are still free per zone, with:

aws rds describe-db-capacity-reservations --db-capacity-reservation-identifier shop-migration

Reservations are targeted: nothing uses them unless you say so. Add the reservation to the operation that needs the capacity:

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier shop-db \
  --db-snapshot-identifier shop-final-snapshot \
  --db-instance-class db.r7g.large \
  --availability-zone us-east-1a \
  --db-capacity-reservation-identifier shop-migration

The same --db-capacity-reservation-identifier works on create-db-instance, create-db-instance-read-replica, point-in-time restores, modify-db-instance (to move an existing instance into a reservation) and start-db-instance. The instance's engine, class, license model and zone must match the reservation, and the matching zone must show free capacity, or the call fails with a not-enough-capacity error. In the RDS console, the same choice appears as a Capacity reservation section when you create or restore an instance.

An immediate reservation has no commitment: change the count with modify-db-capacity-reservation --capacity-per-availability-zone, set or remove an end date with --end-date-type limited|unlimited, and release it with cancel-db-capacity-reservation whenever you like.

What a capacity reservation costs

There is no upfront fee and no separate reservation price. Each reserved slot is billed at the on-demand rate of its instance class for as long as the reservation is provisioned, per second with a 60-second minimum. When a matching instance runs in a slot, you pay for the instance and the slot costs nothing extra; an empty slot shows on the bill as an unused reservation at the same rate. Only compute is reserved: storage, I/O and backups are billed as usual.

For a migration window, the routine that keeps the cost to a few dollars:

1. Create the reservation one working day before the window, in the zone and class the restore will use.
2. Check describe-db-capacity-reservations shows active and free capacity.
3. Restore or create the instance with --db-capacity-reservation-identifier.
4. When the instance is available and tested, cancel the reservation (or reduce it to what keeps running).
5. Check the next day's bill for unused reservation hours, so nothing was left behind.

Discounts you already have still work: reserved DB instances and Database Savings Plans apply automatically to reservation usage, so a reservation on top of reserved-instance coverage costs nothing extra while it is full. The second row is the pattern to copy for a migration: reserve shortly before, cancel as soon as the database is running.

Future-dated reservations for a planned migration or peak

For an event you can see coming (a migration weekend, a product launch, a holiday peak), you can schedule the reservation in advance:

aws rds create-db-capacity-reservation \
  --db-capacity-reservation-name holiday-peak \
  --engine postgres \
  --db-instance-class db.r7g.large \
  --availability-zones us-east-1a \
  --capacity-per-availability-zone 16 \
  --start-date 2026-11-20T00:00:00Z \
  --commitment-duration 1209600

• The start must be 5 to 120 days in the future.
• A commitment is required: at least 14 days (1,209,600 seconds), or 12 weeks for the X family, and under 10 years. You cannot cancel an active future-dated reservation during its commitment.
• RDS may grant a shorter commitment than you asked for; read CommitmentInfo.CommitmentEndDate in the response.
• The commitment does not end the reservation; set --end-date for that, at or after the start plus the commitment. For one calendar month, set a commitment of 30 days or fewer, not the month's length.
• Only C, M, R, T and X classes qualify, and M and R must be generation 7 or later (db.m7g, db.r7g yes; db.m6g no).
• Billing starts only when the capacity is provisioned on the start date.

Multi-AZ, read replicas and quotas

• Multi-AZ instances need capacity in two zones, so reserve in at least two. A Multi-AZ instance uses two units of reserved capacity, one per zone.
• A read replica uses one unit, like any instance.
• Capacity in one zone cannot serve another zone, even in the same Region, and a reservation's zones cannot be changed after creation.
• Your DB instance quota counts reserved capacity: reserving 3 instances across 3 zones uses 9 of it, and unused reserved slots count too.
• Reservations apply within one account and Region; create one per Region you need. RDS Custom engines are not supported.

Stopping and starting an instance in a reservation

Stopping an instance that uses reserved capacity releases its slot back to the reservation but keeps the association, so starting it again returns it to the same reservation automatically. Two consequences:

• If another instance takes the freed slot while yours is stopped, the start fails: reserved capacity is targeted and does not fall back to ordinary on-demand capacity. Leave the slot free if you need the restart.
• The reservation keeps billing for the stopped instance's empty slot. To end the association, choose Release reserved capacity when you stop it (console: Actions, Stop temporarily, Additional actions); the instance then starts as a normal on-demand instance.

Capacity reservations vs reserved DB instances vs Database Savings Plans

Jake: "So I've been paying for a reserved instance that doesn't reserve anything?"

Ethan: "It reserves a price. This new thing reserves the hardware."

Despite the similar names, a reserved DB instance is a billing discount and nothing more: it does not hold hardware for you. If you need the database to start when it matters, that is what a capacity reservation is for; if you want it cheaper, that is what the other two are for. Reserved vs Savings Plans vs Spot covers the discount side.

Aurora: the same reservations, cluster by instance

Aurora uses the same feature and the same commands with the aurora-mysql or aurora-postgresql engine. Capacity is reserved for DB instances, not clusters, so you target the reservation when you create each instance in the cluster, the writer and every Aurora Replica:

aws rds create-db-instance \
  --db-instance-identifier shop-aurora-writer \
  --db-cluster-identifier shop-aurora \
  --engine aurora-postgresql \
  --db-instance-class db.r7g.large \
  --availability-zone us-east-1a \
  --db-capacity-reservation-identifier shop-migration

A cluster restore (restore-db-cluster-from-snapshot or restore-db-cluster-to-point-in-time) creates the cluster without instances and does not take a reservation; restore the cluster first, then add its instances with the reservation. modify-db-instance moves an existing Aurora instance into one.

Troubleshooting by symptom

InsufficientDBInstanceCapacity on create or restore

Try another Availability Zone, another class or generation, or retry later. For planned work, reserve capacity first.

A stopped DB instance will not start

Stopping released its hardware. Retry later, modify it to another class before starting, or restore its snapshot into another zone.

The launch into my reservation fails

Engine, class, license model or zone does not match, or the zone shows no free capacity. Check AvailableCapacityPerAvailabilityZoneList with describe-db-capacity-reservations.

My reservation stays in assessing or delayed

RDS is still securing the capacity. Future-dated reservations show scheduled until their start date; failed or unsupported means the request cannot be met as written.

DBCapacityReservationUnsupported

The combination is not supported, for example an older class for a future-dated reservation, or an RDS Custom engine.

I cannot cancel my reservation

An active future-dated reservation cannot be canceled during its commitment period. Reduce later, or let it reach its end date.

The bill shows unused reservation charges

Slots with no running instance bill at on-demand rates. Lower capacity-per-availability-zone or cancel the reservation.

The Multi-AZ launch fails with a reservation

Both the primary and standby zones need free capacity in the reservation. Reserve in at least two zones.

Frequently asked questions

The shop's next migration, a move to a larger instance class three months later, went the new way: a reservation created on Friday, the restore on Sunday straight into it, the reservation canceled on Monday morning. It cost less than lunch. "That's the cheapest insurance I've ever bought," Jake said. Ethan corrected him: "It's the cheapest one you've ever canceled."

Revision note. Written October 23, 2026, two days after RDS and Aurora On-Demand Capacity Reservations launched, with the RDS API (botocore 1.43.118) and user guide as they stood on that date. "Don't count your chickens before they hatch," the saying goes; with capacity, count them only once they are reserved.