Reserver
Reserved Instances, managed properly.
What problem does it solve?
AWS Reserved Instances are tracked in spreadsheets. They silently lapse when terms expire, reverting the fleet to expensive on-demand rates, while unused reservation capacity goes unnoticed.
Who is it for?
Teams running steady-state fleets on AWS, from startups with a handful of reservations to enterprises managing hundreds across multiple accounts.
Why are we building it?
Every AWS-heavy client eventually asks the same question: are we actually using our Reserved Instances, or are they sitting in a spreadsheet someone updated eight months ago? Almost always, some are already expired and quietly reverted to on-demand rates.
Reserver is what we're building to close that gap. It connects directly to AWS accounts, matches reservations to what's genuinely running, and turns "don't let this lapse" from a calendar reminder into an automated purchase.
How does it work?
- Match reservations to real usage
Reserver is designed to reconcile reservation records against what's actually running across EC2, RDS, and ElastiCache, not against a spreadsheet that's already drifted from reality.
- Coverage maps of reserved vs. on-demand
The plan is a visual map: what's covered by a reservation, and what's paying on-demand rates unnecessarily. That makes the gap visible instead of buried in a billing export.
- Break-even math on purchase recommendations
Every recommended purchase carries its own break-even point and projected annual saving. The case for buying is a number, not a guess.
- Renewal autopilot
Reserver re-buys expiring reservations automatically before they lapse, instead of depending on someone noticing the expiry date in time.
What's the hard part?
Matching a reservation to the exact running instance it covers is the genuinely hard reconciliation problem, especially across regions, instance families, and multiple AWS accounts under an Organization. AWS's own reservation-utilization reporting doesn't make this trivial. That's exactly why the spreadsheet-tracking failure mode is so common in the first place.
What does it do?
- Matches reservations to what's actually running: EC2, RDS, and ElastiCache
- Coverage maps of reserved vs. on-demand capacity
- Purchase recommendations with break-even math and annual savings
- Renewal autopilot re-buys expiring reservations before they lapse
- Multi-account and AWS Organizations support
- Flat pricing that never takes a cut of your savings
What does this prove we can do for you?
Reconciling billing records against real infrastructure state, and automating the fix, is the same discipline we bring to a client's own cloud cost audit.
Where this shows up in client work
Questions, answered.#
The questions we get asked most, answered plainly: no hedging, no marketing copy.
01 Is Reserver available yet?
Not yet. It's in build. Matching reservations to real running usage across accounts is the reconciliation problem we're solving first.
Link to this answer: Is Reserver available yet?02 Does it only cover EC2?
The plan covers EC2, RDS, and ElastiCache reservations, with multi-account and AWS Organizations support.
Link to this answer: Does it only cover EC2?03 How is pricing structured?
Flat pricing is the intent. Reserver won't take a cut of whatever savings it finds.
Link to this answer: How is pricing structured?Connects to your AWS accounts and matches Reserved Instances to running usage. It tells you exactly what to buy next, then turns that purchase into a button or a scheduled rule.
This is the same discipline, real architecture decisions and an honest account of the hard part, that we bring to client engagements.