Reserved Instances
The biggest discount in cloud billing has one silent failure mode.
Reserved Instances cut what you pay for steady RDS, ElastiCache, and EC2 usage — sometimes drastically. They also expire on a fixed date, with no renewal built in. Here's what an RI actually is, why that cliff catches even careful teams, and how to make sure it never catches yours.
First, the basics
A Reserved Instance is a billing commitment, not a resource.
Buying an RI doesn't provision anything new. It's a commitment to pay for a given amount of usage — an instance class, in a region, for a 1-year or 3-year term — in exchange for a lower effective hourly rate than the on-demand price for that same usage. AWS then automatically applies the discount to any of your running usage that matches.
Discount ceilings per AWS published pricing; your actual rate depends on instance class, term, and payment option.
Three payment options, one lever: how much you pay upfront
For EC2 specifically, there's a second choice: Standard Reserved Instances carry the deepest discount but fix the instance's attributes for the term, while Convertible Reserved Instances trade some discount for the ability to exchange into a different instance family, operating system, or tenancy mid-term. RDS and ElastiCache reservations don't have a convertible option — the term and payment option are the only levers there.
The part that catches people
The renewal cliff: RIs don't auto-renew.
AWS has no auto-renew feature for Reserved Instances. When a term ends, the running instance doesn't restart, stop, or degrade — it keeps doing exactly what it was doing. What changes is the price: usage that was covered by the reservation reverts to the standard on-demand rate, immediately and silently, and stays there until somebody notices and buys a new reservation. Nothing in the AWS console interrupts you to tell you this happened.
On this single, illustrative instance, ten days unnoticed costs about $134; a month costs about $403 — and that's one reservation. Multiply by however many terms expire across your fleet in a given week, and a "small" gap stops being small. Use the savings calculator to estimate it against your own spend and your own days-late number.
Why it slips
Nobody planned to miss it. The process just isn't built to catch it.
End dates live in three separate consoles (RDS, ElastiCache, EC2), rarely in the same place as the fleet they cover. Most teams track them in a spreadsheet somebody set up once, backstopped by a calendar reminder nobody formally owns. And because a reservation's discount can apply flexibly across the instance sizes within a family, knowing whether a given RI is still covering anything real gets harder every time the fleet changes shape — exactly the thing fleets do constantly.
A practical checklist
Track every end date in one place
Not in a person's memory, and not split across the RDS, ElastiCache, and EC2 consoles — one list, every reservation, every term end.
Match reservations to what's actually running
A reservation with nothing left to cover — because the instance was resized, moved, or terminated — is dead weight, not savings. Know which of your RIs are covering real usage today.
Decide renew-vs-lapse from current usage
Re-buy based on what's running now, not on what you happened to buy last time. Fleets change generation and shape between terms.
Keep a single coverage view
Across every account you run. A gap is easiest to miss to exactly the degree it isn't visible — the fix is making it visible.
Want item one done today, for real reservations? Paste your ownaws ... describe-reserved-* output into the Expiry Check and get every end date back in seconds — free, nothing uploaded.
How this scales with you
The cliff doesn't care how big your fleet is.
A spreadsheet works fine — right up until the one person who maintains it is out the week a term ends. Small fleets still lose a full reservation's savings to a single missed renewal; there just aren't many of them to hide the gap.
Fleet turnover starts to outrun the review cycle. Coverage decays quietly between reviews — not from anyone doing anything wrong, just from more things changing between the calendar reminders.
Nobody tracks renewals by hand at this scale. Without one coverage view and an approval chain across every account, the math on any single reservation becomes a rounding error nobody can see — until it's thousands of them.
The tooling should scale the same way the problem does: one flat price whether you're covering ten reservations or ten thousand — see pricing — never a cut of what you save.
Where Reserver fits
Everything on the checklist, run automatically.
Reserver connects to your AWS accounts read-only, scans every Reserved Instance you own alongside what's actually running, and builds the single coverage view the checklist above calls for. Expiry radar surfaces every end date before it arrives; the matching engine flags reservations with nothing left to cover; renewal autopilot re-buys expiring RIs on your terms — with the math shown, or with an approval step first, your choice. See features, how it works, and the security model behind the read-only connection — or, for how much of that coverage view to aim for in the first place, read the coverage playbook.
Do Reserved Instances renew automatically?
No. AWS does not auto-renew Reserved Instances for RDS, ElastiCache, or EC2 — when a term ends, you have to purchase a new reservation yourself. If nobody does, the instance keeps running exactly as before, just billed at the standard on-demand rate from that moment on.
What actually happens when an RI expires?
Nothing happens to the running instance — no restart, no downtime. Only the price changes: usage that was covered by the reservation reverts to on-demand billing, immediately and silently, and stays there until a new reservation covers it again.
Should I buy a 1-year or 3-year term?
It depends on instance class, payment option, and how long that instance family tends to stay in your fleet — a 3-year term is typically the deeper discount, but a longer commitment. If a family has a track record of running for years, the longer term usually wins on the math; if it's new or likely to change, a 1-year term costs less certainty. Reserver runs this comparison against your own fleet's history.
Is tracking renewals worth it for only a few reservations?
Usually, yes. Even a single reservation left unrenewed for a couple of weeks typically costs more, in on-demand premium, than tracking it would have — the math doesn't require a large fleet to matter, it just requires someone to notice the date.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list and we'll onboard you as capacity opens up — first recommendation within minutes of connecting.