AWS opens on-demand capacity reservations for Aurora and RDS, with no commitment
On October 21, 2026, AWS launched On-Demand Capacity Reservations for Amazon Aurora and RDS: reserve compute capacity in one or more Availability Zones, immediately or scheduled 5 to 120 days ahead. It is insurance against “insufficient capacity” errors, not a cost cut — reserved capacity is billed even when no instance is running.
October 21, 2026. AWS makes On-Demand Capacity Reservations available for Amazon Aurora and Amazon RDS. October 21, 2026. Capacity can be reserved immediately, with no commitment, or scheduled 5 to 120 days ahead with a minimum commitment. October 21, 2026. The feature is live in all AWS commercial Regions. The point that matters: a database create, restore, scale or start operation can now be guaranteed against “insufficient capacity” failures.
For an SRE or a DBRE, this ends a recurring dread: running a migration or a failover in production and watching instance creation fail because the Availability Zone has no capacity left for the instance class you asked for.
What it does, technically
A Capacity Reservation reserves compute capacity for Aurora or RDS instances in one or more Availability Zones within a Region. You pick the instance class, the engine — say db.r6g.xlarge on PostgreSQL or MySQL —, the AZs, and the amount of capacity reserved per AZ. RDS then holds that capacity for you, and you reference the reservation when you create, restore, modify or start an instance.
A reservation can span two or more AZs to support Multi-AZ deployments. That is the crucial part: a Multi-AZ failover moves the instance to another AZ, and without capacity reserved in the destination AZ, the failover can fail at the worst possible moment.
The pricing model: insurance, not a discount
The economics are the part to understand before you sign. Reserved capacity is billed at On-Demand rates while the reservation is active, whether or not instances are running. Discounts from your existing Reserved DB Instances or Database Savings Plans apply automatically, but the reservation itself adds no reduction.
Two modes coexist:
- Immediate: no commitment, cancel any time. You pay for the capacity from creation, even if no instance consumes it.
- Scheduled (5 to 120 days): you reserve ahead of an event — a migration, a launch, a seasonal peak — with a minimum commitment duration.
The nuance mirrors EC2 Capacity Reservations, of which this is the database counterpart: you are buying a availability guarantee, not a saving. A team that reserves capacity “just in case” and never uses it pays twice — the reservation, then the instances.
When it is worth the cost
The feature does not make sense everywhere. It targets operations where failure has a direct cost:
- Migrations: a database cutover scheduled for a weekend cannot afford an “insufficient capacity” at 2 a.m.
- Product launches and seasonal peaks: reserving the target instance class ahead of time avoids discovering it is exhausted on the day.
- Disaster recovery: reserved capacity in the standby AZ guarantees the restore actually completes.
- High-availability deployments: Multi-AZ only protects you if the second AZ can genuinely take the instance.
Conversely, a steady workload already running 24/7 gains more from negotiating Reserved Instances or a Savings Plan, which lower the bill, than from reserving on-demand capacity. The reservation only pays off where capacity risk is the real problem, not price.
What it shifts in the balance of power
This announcement reaches further than a feature. It formalises that capacity scarcity in certain Regions and instance classes — especially Graviton and memory-optimised classes favoured for databases — has become a problem customers must insure against financially, rather than a rare incident. AWS is monetising scarcity: the same mechanism already exists for EC2, and extending it to RDS and Aurora signals that database capacity demand regularly outstrips supply in the busiest AZs.
It is also a signal for the self-hosting crowd: a capacity guarantee is a selling point of the clouds, but it carries a permanent cost. Teams that host their databases on dedicated hardware pay no “capacity insurance” — they simply have the capacity. The trade-off is that they carry the failure and sizing risk alone.
In practice: the CLI, quotas and limits
Creation is a single command, via the AWS CLI or the RDS API. The reservation name must start with a lowercase letter, and the generated identifier carries the dbcr- prefix:
aws rds create-db-capacity-reservation \
--db-capacity-reservation-name my-reservation \
--engine postgres \
--db-instance-class db.r7g.large \
--availability-zones us-east-1a \
--capacity-per-availability-zone 3For a Multi-AZ deployment, list two or more AZs: the same capacity is reserved in each. A reservation is targeted — an instance draws from it only when you reference it explicitly, by name or identifier.
Two limits are worth knowing before you count on it. First, only the C, M, R, T and X families are eligible, and M and R classes must be generation 7 or later: db.m7g and db.r7g work, db.m6g and db.r6i do not. Second, each AZ in the reservation must hold at least 32 vCPUs — for a 2-vCPU db.r7g.large, that is 16 units minimum per AZ. A team that only needs a small standby instance ends up over-reserving. And the reservation covers compute only: not storage, not I/O.
| Criterion | Capacity Reservations | Reserved DB instances | Database Savings Plans |
|---|---|---|---|
| Commitment | None (immediate); minimum (future) | 1 or 3 years | 1 year |
| Capacity reserved | Yes, per AZ | No | No |
| Billing discount | None | Yes | Yes |
| Stackable | With Savings Plans / Reserved instances | — | — |
Also note: a reservation consumes your On-Demand instance quota — reserving 3 instances across 3 AZs uses 9. For a future-dated reservation, the state moves through assessing then scheduled before turning active on the start date; if AWS cannot deliver on time, the delayed state lets you cancel immediately with the commitment partly waived.
To make it concrete: reserving two db.r7g.xlarge across two AZs for a weekend migration means paying On-Demand rates from the moment the reservation goes active — including the hours before the cutover when no instance runs on it. That is the price of certainty: you pay AWS to hold a slot, not to run a database, and whether that slot is cheaper than a failed migration is rarely a close call. Bear in mind too that compute reservations do not reserve storage or I/O, so a restore can still be throttled elsewhere even when the CPU slot is guaranteed. Treat the reservation as one part of a failover plan, not the whole plan.
Verdict
If you are planning a migration, a launch or a critical database failover in the coming months, reserve capacity in the destination AZ now — the 5–120 day scheduled mode is built for exactly this, and a failed cutover always costs more than the reservation. If your workload is steady with no event on the horizon, do not buy a reservation: negotiate Reserved Instances or a Savings Plan that shrink the bill instead of freezing it. The rule is simple — reserve when you fear a capacity outage, negotiate when you want to pay less.
References
- AWS — Amazon Aurora and Amazon RDS now support On-Demand Capacity Reservations (October 21, 2026)
- AWS Docs — Amazon RDS On-Demand Capacity Reservations
- AWS Docs — Amazon Aurora On-Demand Capacity Reservations
- changes.watch — AWS: Amazon Aurora and Amazon RDS now support On-Demand Capacity Reservations