Renewal timing
AWS lets you queue a purchase. RDS and ElastiCache never do.
An EC2 Regional Reserved Instance can be queued years ahead. RDS and ElastiCache cannot be queued at all, and even a queued EC2 purchase only lands on a UTC midnight, not the exact hour a term ends.
First, the mechanic
An EC2 Regional RI purchase can wait for a future date.
AWS's purchase API accepts a purchase time for an EC2 Regional Reserved Instance, up to three years ahead of the actual purchase. The reservation sits in a state AWS calls "queued" until that date arrives.
AWS documents the command directly: aws ec2 purchase-reserved-instances-offering takes a --purchase-time flag. The console offers a shortcut for the most common case. Its "Renew Reserved Instances" action queues a new purchase with the same configuration as the reservation you are renewing. Change your mind, and aws ec2 delete-queued-reserved-instances cancels it before the date arrives.
What you cannot queue
Six purchase types, and whether AWS lets you queue one.
The queue is an EC2 Regional RI feature first, and a general AWS purchasing feature second. Most reservation types Reserver tracks have no queue at all.
| Purchase type | Can you queue the purchase? |
|---|---|
| EC2 Regional RI | ✓the purchase API takes a purchase time, up to three years ahead |
| EC2 Zonal RI | ✗AWS reserves capacity for a specific zone, and only an immediate purchase does that |
| EC2 RI from the Marketplace | ✗a resold RI is bought as-is, at the moment of purchase |
| RDS reserved DB instance | ✗the purchase API takes an offering id and a count, and nothing else |
| ElastiCache reserved node | ✗the purchase API takes an offering id and a count, and nothing else |
| Savings Plan | ✓the purchase API takes an optional purchase time |
Can you queue the purchase?
- ✓EC2 Regional RIthe purchase API takes a purchase time, up to three years ahead
- ✗EC2 Zonal RIAWS reserves capacity for a specific zone, and only an immediate purchase does that
- ✗EC2 RI from the Marketplacea resold RI is bought as-is, at the moment of purchase
- ✗RDS reserved DB instancethe purchase API takes an offering id and a count, and nothing else
- ✗ElastiCache reserved nodethe purchase API takes an offering id and a count, and nothing else
- ✓Savings Planthe purchase API takes an optional purchase time
Two rows carry the same shape. RDS's purchase API takes exactly four parameters: an offering id, an instance count, an optional reservation id, and tags. There is no time parameter to set. ElastiCache's purchase API takes the same four, with the same gap. On both services, the only way to buy a reservation is to buy it right now.
The console lands on midnight, your term does not
A term ends on the clock. The console only queues to the date.
An RI term runs for a fixed number of seconds from the moment you buy it, so it ends at a clock time, not necessarily a calendar boundary. AWS's own words on the EC2 console: a queued purchase "is queued until 00:00 UTC on this date. To specify a different time for the queued purchase, use an AWS SDK or command line tool."
Take a term that ends at 14:37 UTC. Queue the renewal to that same day's midnight in the console, and the new term starts about 14.6 hours before the old one ends. You pay a second reserved rate for that stretch. Queue it to the next day's midnight instead, and the old term ends about 9.4 hours before the new one starts. That stretch bills at the full on-demand rate. Either way, only the CLI or an SDK can land the purchase at 14:37 UTC itself and skip both costs.
A queued purchase is not a guarantee
The purchase can fail, and nothing tells you.
AWS caps a queued purchase at the price in effect when you queue it. If that price moves before the queued date, the purchase does not happen.
AWS states this plainly: "If the price rises or changes for any reason, the purchase is not completed." There is no notification for a failed queued purchase. The reservation you expected either appears on your queued date, or it does not, and the only way to know is to check. A queued renewal still needs someone to look after the date arrives, the same as a renewal that was never queued at all.
A queued purchase still lands against its purchase date's own monthly purchase quota, not the date it was queued. Queuing a large batch to the same day does not raise that day's default limit of 20 per Region.
How this scales with you
One clock mismatch is a rounding error. Thousands is a budget line.
One person can watch a single date on the calendar. The catch is that a term ends on a clock time, not a date, and the console can only queue to midnight. Even one reservation can land a few hours off.
Dozens of reservations across a few accounts turn that midnight gap into a repeating cost. Every renewal either overlaps and double-bills for a few hours, or lapses and pays on-demand for a few hours, and it adds up fast at this volume.
Thousands of reservations across many accounts, and often more than one cloud, cannot be watched by a person at all. RDS and ElastiCache offer no queue whatsoever, so someone still has to act at the exact hour for two of the three services Reserver scans.
Where Reserver fits
Reserver reports the exact expiry, today. It does not queue a purchase yet.
Reserver scans your RDS, ElastiCache, and EC2 reservations and reports each one's exact expiry timestamp, then warns you ahead of it. Queuing the replacement purchase for you, and renewing it automatically, are both on our roadmap, not shipping yet.
Scheduled purchasesbuilding · M5
Renewal autopilotbuilding · M5
Until then, an exact expiry timestamp and an early warning close most of the gap on their own. You still choose when to queue the purchase, and with what tool, but you never have to go looking for the date. See features and the renewal playbook for the rest of what keeps a renewal from slipping.
Can you schedule an AWS Reserved Instance purchase in advance?
Yes, for an EC2 Regional RI. The purchase API takes a purchase time up to three years ahead, and AWS calls the resulting state "queued". A Zonal RI, a Marketplace RI, an RDS reserved DB instance, and an ElastiCache reserved node cannot be queued at all. Only an immediate purchase works for those four.
Can I queue an exact time, like 14:37 UTC?
Not from the EC2 console. It only queues to 00:00 UTC on a chosen date. AWS's own documentation says a different time needs an SDK or command line tool, since the console has no field for one.
Is a queued purchase guaranteed to complete?
No. AWS places a limit price on the purchase at the time it is queued. If the offering's price rises before the queued date, the purchase does not complete. Nothing alerts you when that happens. The only sign is a reservation that never appears.
Does Savings Plans support the same kind of scheduling?
Yes. The Savings Plans purchase API takes an optional purchase time, the same idea as EC2's queued RI. RDS and ElastiCache have no equivalent for either mechanism.
Sources, fetched and confirmed on 2026-09-08: how to queue a Reserved Instance purchase; PurchaseReservedDBInstancesOffering, the RDS purchase API; PurchaseReservedCacheNodesOffering, the ElastiCache purchase API; and CreateSavingsPlan, the Savings Plans purchase API.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list and we'll onboard you as capacity opens up. Your first recommendation lands within minutes of connecting.