Case study — enterprise
40 AWS accounts. One renewal calendar nobody owned — and $250k a year nobody was watching for.
A real AWS Organizations footprint spanning 40 member accounts under one payer. We read every member account under a single org-wide role and priced each gap at the rates these accounts actually pay for the exact classes below, us-east-1, mid-2026 — anonymized at the customer's request. See the method notes at the bottom.
Finding 01 — the renewal that slipped at scale
One rollout. One term. Forty accounts lapsed the same week.
Two years ago, a platform rollout gave every one of the 40 member accounts its own db.r6g.4xlarge Multi-AZ cluster, all reserved on the same one-year term at the same time — a good, deliberate call. A year later, every one of those terms ended in the same week. No single account owner had the full calendar, and the org's central platform team assumed each account's owner was tracking their own renewal. It took a routine cross-account cost review 14 days to catch it.
Sixteen thousand dollars in two weeks is a rounding error against $3M of annual reservable compute — which is exactly how it hid. No single account's bill moved enough to trigger an alarm. Only a view across all 40 accounts at once made the pattern visible. Reserver's expiry radar flags every renewal, org-wide, before the term ends — free on Watch. Renewal autopilot rebuys the same day a term expires, everywhere at once, on Autopilot.
Finding 02 — coverage drift across accounts
Every account looks fine alone. Together, coverage drifts down.
No single team here is careless — each account owner reserves what they can see. But 40 decentralized teams means 40 different review cadences, 40 different definitions of "good enough," and nobody holding the org-wide number. The result: reservable coverage across the whole organization sits at 71%, well below what a single coordinated view would reach.
Each account owner would say their own coverage "looks reasonable." None of them can see that the org as a whole is leaving over a fifth of its reservable footprint on-demand. Reserver reads every member account under one AWS Organizations role and reports one coverage number, not 40 — so the gap is visible to whoever's job it actually is to close it.
Finding 03 — reservations stranded across accounts
The workload moved accounts. The reservations didn't.
A re-org consolidated a product line's compute into a shared account. The m6g.xlarge instances moved cleanly. The 45 Reserved Instances bought against them, in the account they left, did not — RIs aren't consolidated by a re-org, they're bound to the account and Availability Zone they were purchased in. This is a failure mode that only exists once you have more than one account: with a single account, there's nowhere for a reservation to strand to.
Left uncaught, the same 45 reservations run to $36k/yr of pure waste — on top of the destination account paying full on-demand rate for the same capacity a reservation already exists for, two accounts away. This is exactly what the Enterprise tier is built for: one scan across every member account, matching reservations to instances wherever either one lives, so a re-org can't strand a purchase again.
The bill
$250,062 found across an organization that nobody was watching whole.
None of these three findings required a mistake anyone would own up to individually — a rollout that happened to renew together, 40 reasonable local decisions that don't add up to one good global one, and a re-org that moved compute faster than anyone remembered to move the paperwork. The common thread is scale: every one of these is invisible from inside a single account, and unmissable from an org-wide view. That's what the Enterprise tier is for.
Method notes — for the skeptical reader (we hope that's you)
- A real AWS Organizations footprint across 40 member accounts; the organization and any identifying details are withheld at the customer's request, but the structure, reservation counts, and every dollar figure are its own.
- Every dollar figure is priced at the accounts' own AWS On-Demand and 1-year Reserved Instance (No Upfront) rates, US East (N. Virginia), mid-2026, for the exact classes named: db.r6g.4xlarge (RDS MySQL, Multi-AZ) and m6g.xlarge (EC2 Linux).
- On-demand-minus-RI premiums use the No Upfront payment option specifically, because it carries the smallest discount of the three RI payment options — that keeps every premium in this study conservative, not best-case. The same 33% discount ratio is used throughout, including for the org-wide coverage-drift estimate.
- The 14-day renewal gap, 5-month stranding window, and 71%/93% coverage figures are measured from the org's own scan and cost history.
- AWS-only. This product does not cover Savings Plans or other cloud providers in v1 — this study covers Reserved Instances across AWS Organizations member accounts, nothing more.
- No right-sizing, Spot, or workload changes are assumed anywhere on this page. This is purchasing mechanics only, on the fleet exactly as described.
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.