Reserver.Reserve your spot →

Case study — multi-region SaaS

They bought 550 reservations in twelve years.
Here's the $60k that still got away.

A real production account: a B2B SaaS platform running database-per-tenant across six AWS regions. We analyzed its entire reservation ledger, usage history, and CloudTrail. Every number below is measured, and priced at the rates this account actually pays. This is what manual reservation management costs a team that is genuinely good at it.

$2.37Mannual AWS spend
111RDS instances (MySQL)
418EC2 instances
65ElastiCache nodes
550RIs bought since 2014
80–95%RDS coverage, month to month

Finding 01 — the review-cycle tax

Reservations expire weekly. Humans buy monthly.

With 550 one-year reservations, something expires almost every week. But the purchase timestamps tell you how the work actually happens: every reservation bought in the last two years landed on just 27 distinct days. That's a person running a batch review every month or two — and between reviews, expired coverage just sits there, billing at on-demand.

Every reservation purchase, 24 monthsOne dot per purchase day — dot area ∝ units bought that day
Jul '24Jan '25Jul '25Jan '26Jul '2624 units43 units2 units1 units23 units3 units3 units7 units19 units2 units3 units12 units10 units3 units25 units4 units3 units25 units16 units30 units2 units11 units21 units8 units13 units48 units1 units27 purchase days · 24 months
249expiry→repurchase events measured since 2023
8 daysmedian gap — coverage lapsed, still billing
53%of events gapped longer than a week
$8,000of gap premium in 24 months, at their own rates

Worst single case: a db.m6g.4xlarge reservation expired in August 2024 and wasn't re-bought until the following June —309 days of a 4xlarge running at on-demand, $2,129 of premium on one instance, invisible inside a coverage number that still said “~90%, healthy.” Reserver's renewal autopilot re-prices and repurchases the day a term ends. This entire category goes to zero.

Finding 02 — the migration nobody told the renewals about

The fleet moved on. The renewal habit kept buying the old one.

In May 2026 the team executed a clean, well-planned generation migration — CloudTrail shows dozens of old instances deleted over three weeks, each replaced by a newer-generation sibling, and the burstable t4g replica tier retired entirely. The problem: while that migration was being planned, the routine renewal cycle was still re-committing to the outgoing tier — four renewal rounds, ~35 one-year reservations on hardware with weeks to live.

db.t4g.large metered hours vs the renewals bought on itBars: monthly usage (thousand hours, all regions). Ticks below: months the renewal cycle re-bought t4g reservations.
010k20k30kJul: 26.5k hoursJulAug: 27.2k hoursAugSep: 26.7k hoursSepOct: 28.3k hoursOctNov: 27.4k hoursNovDec: 28.9k hoursDecJan: 29.7k hoursJanFeb: 27.1k hoursFebMar: 30.6k hoursMarApr: 31.1k hoursAprMay: 20.3k hoursMay0Jun20252026tier retired — zero hours in June
usage (steady)usage (migration underway)t4g renewals bought that month
~35t4g reservations renewed in the four rounds before retirement
$3,956burned in May–June against zero usage
$7,512still committed through Feb 2027, covering nothing
5 weeksthe new fleet ran on-demand before its RIs arrived

The other half of the same event: the replacement m8g/m7g fleet came up mid-May, and its reservations arrived July 5 — the next scheduled review. June's on-demand premium tripled to $2,992 in a single month. A calendar-driven renewal process and a migration project don't share state. A daily fleet scan is the shared state: expiring RIs whose instances are gone get flagged, not renewed — and the new fleet trips the age rule instead of waiting for a human to notice it.

Finding 03 — drift between reviews

Coverage doesn't fail loudly. It slides.

New tenant databases appear continuously in this account. Each one runs at on-demand until a human notices it at the next review. One instance at a time, that's invisible — until you plot it.

RDS reservation coverage, 2026% of running instance-hours covered by an RI (Cost Explorer)
60%70%80%90%100%Jan 2026: 90.6%JanFeb 2026: 94.7%FebMar 2026: 94.6%MarApr 2026: 92.1%AprMay 2026: 86.7%MayJun 2026: 80.4%Jun94.6%80.4%
What the slide costsMonthly on-demand premium vs their own RI rates ($)
0$1k$2k$3kJul: $424JulAug: $520AugSep: $233SepOct: $412OctNov: $555NovDec: $929DecJan: $859JanFeb: $252FebMar: $339MarApr: $762AprMay: $1728MayJun: $2992Jun$2,99220252026

At scan time, 11 of the 12 uncovered RDS instances were older than 30 days — one 4xlarge had been running on-demand for 171 days. Under Reserver's age rule (“running longer than 30 days → reserve it”), every one is ticketed months earlier. Measured over the full year at their own realized rates: $10,004 in RDS, $1,343 in ElastiCache — same signature, smaller numbers: 13 of 65 cache nodes uncovered.

Finding 04 — the seam between two owners

Two teams manage commitments. The steadiest workload fell between them.

RDS and ElastiCache reservations are managed inside this account; EC2 commitments are handled at the payer level with org-wide Savings Plans. Both layers do their jobs — the org sweeps the Linux fleet, and the account team moved half its EC2 to Spot. But look at what's left after both nets have passed over the account:

EC2 on-demand residual, June 2026 — after org Savings Plans and Spot$10,043 total, by platform
Windows: $9,514Linux + other: $529Windows c5 — $9,514 (95%)ran every hour of all 12 months · AWS's own recommender prices the fix at $456/mo
Windows (c5 family)Linux + other

Too Windows-shaped for the Spot program; invisible to the org-level Savings Plan sizing. $5,470/yr, priced by AWS's own Cost Explorer recommendation — not ours. Split ownership creates seams, and steady workloads leak through them. A scanner that reads this account's actual running fleet surfaces the miss no matter whose job the purchase was.

Finding 05 — the twelve-year habit

550 reservations. Zero three-year terms. Their own ledger says that's backwards.

Every reservation this team bought since 2014 is a 1-year term. The instinct — “our fleet changes too much to commit for three years” — is reasonable. It's also refuted by their own purchase history: every instance family they ever adopted stayed in the fleet 3.7 to 5.4 years. A 3-year term bought at family adoption would never have stranded. Not once, in twelve years.

Instance-family tenure, from their own RI ledger

r3
5.1 yrs
m4
5.4 yrs
m6g
5.3 yrs
t4g
3.7 yrs

the first 3 years — a 3-yr term bought at adoption runs to completion in every case

Same fleet, longer term — annualized cost at live offering pricesSingle-AZ MySQL / Redis, their exact classes, regions, and counts
db.m6g.4xlarge master tier (29)1-yr partial upfront: $207k/yr$207k3-yr partial upfront: $139k/yr$139k−$67k/yrJust-adopted m7g tier (17)1-yr partial upfront: $80k/yr$80k3-yr partial upfront: $59k/yr$59k−$21k/yrElastiCache m6g/m7g tier (29)1-yr partial upfront: $26k/yr$26k3-yr partial upfront: $19k/yr$19k−$7k/yr
1-yr partial upfront (their habit)3-yr partial upfront
The break-even that makes 3 years a decision, not a leapCumulative cash, one db.m6g.4xlarge: serial 1-yr renewals vs a single 3-yr
0$5k$10k$15k$20kstartmo 12mo 24mo 363-yr wins from month ~14median family tenure: 5 yearsserial 1-yrone 3-yr
serial 1-yr renewalssingle 3-yr term

Two honest nuances a recommender must carry — and a spreadsheet doesn't: AWS doesn't offer 3-year terms on this account's newest class yet (db.m8g is 1-year only today), and a 3-year t4g bought in early 2026 would have stranded in the May migration. The policy isn't “always 3-year” — it's 3-year at family adoption, taper as the family ages past the org's own tenure norm. That's a judgment Reserver prices instance-by-instance, because the evidence (this account's twelve-year ledger) is already in the scan. Counting only the airtight segments: $28,120/yr. Across the portfolio as generations roll: up to $95,616/yr.

The bill

≈$60,000 a year, on an account doing almost everything right.

Migration-stranded renewals + uncovered new fleetrenewal autopilot checks the live fleet before rebuying$11,468
New instances left on-demand past 30 daysage rule: notify or auto-reserve$11,347
Windows EC2 floor between management layersone scanner covers the whole fleet, whoever owns the commitment$5,470
Expiry→repurchase gapssame-day renewal, zero gap$4,000
Term optimization (airtight segments only)1-yr/3-yr grid with the org's own tenure history + break-even$28,120
Per year, at this account's own ratesterm ceiling raises it to ≈$128k≈$60,000

And it's live, not historical: at scan time the account carried $976/month of uncovered-instance premium, $7,512 of committed stranded-RI spend, and 57 reservation units — $9,554/month of coverage — expiring in the next 120 days, heading into exactly the manual review cycle that produced every number above.

Method notes — for the skeptical reader (we hope that's you)
  • Every dollar figure is computed from the account's own data: 550 RI purchase records (2014–2026), Cost Explorer usage at usage-type granularity, CloudTrail instance lifecycle events, and a live scan of the running fleet.
  • Lapse gaps are costed at (their realized on-demand rate − their own amortized RI rate) per class and region — never list-price discounts.
  • Stranded-reservation burn is measured against actual metered usage hours, not fleet snapshots — a reservation counts as wasted only in months where RI-hours exceeded metered instance-hours for its class, with AWS size-flexibility normalization applied within each family first. Committed forward burn strands the cheapest reservations first (the conservative choice). The May 2026 migration was verified in CloudTrail, not inferred.
  • The EC2 and ElastiCache figures are AWS's own Cost Explorer purchase recommendations on a 60-day lookback. EC2 was cross-checked from the payer account: the residual Windows floor is net of everything org-level Savings Plans cover.
  • Term figures use live reservation-offering prices for the exact classes, regions, and engine, compared at amortized effective $/hr. Family tenure comes from the account's own ledger. The headline counts only newly adopted or demonstrably stable segments; the full-portfolio number is labeled as the ceiling.
  • Savings requiring workload changes, Spot migration, or right-sizing are excluded. Everything above is pure purchasing mechanics on the fleet exactly as it ran.
Reserved

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.

Reserve your spot →