Purchase RDS Reserved Instances

Most cloud commitment programs are built around one big mechanism: the Savings Plan. You commit to a dollar-per-hour of spend and AWS discounts your compute. The catch finance partners often miss is that Savings Plans stop at the edge of EC2, Fargate, and Lambda. Your managed databases — RDS, the second- or third-largest line on many cloud bills — are not covered by them at all. For databases the only discount instrument is the Reserved Instance, and if no one is buying them, the database tier is quietly running at full sticker price.

An RDS Reserved Instance is a one- or three-year commitment to a specific database configuration in exchange for a rate cut of up to about 60%. There are three ways to pay — nothing upfront, part upfront, or all upfront — and more upfront means a deeper discount but a larger cash outlay today. Unlike the EC2 world, these commitments can't be reshaped after purchase: there's no "convertible" option for RDS. That makes the buying decision a genuine capital-commitment question, not a reversible toggle, and it belongs on the finance agenda rather than buried in an engineering ticket.

The number to watch is RDS commitment coverage: of all the database hours you ran this month, what percentage were covered by a Reserved Instance versus paid at On-Demand rates. Healthy steady-state databases — the ones that run 24x7 and aren't going anywhere — should be sitting at 80–95% covered. Anything well below that on a stable database fleet is unrealised savings. Anything near 100% with low utilisation of those reservations is the opposite problem: you've over-committed and are paying for reservations no instance is consuming.

Priya is the finance partner embedded with the platform team. At the monthly cost review she notices something the Savings Plan dashboard had been hiding: the company's $38k of monthly RDS spend is almost entirely uncommitted, because the Savings Plan they're proud of doesn't touch databases. Her question is simple: "These databases have run the same shape for a year — why are we paying On-Demand for all of it?"

The conversation that follows is about cash and confidence, not configuration. Priya asks three things: how stable is this fleet really, how much cash can we put upfront, and what's the payback period. The team confirms the PostgreSQL fleet is steady-state. Finance decides a three-year Partial Upfront commitment fits the cash position — deeper discount than No Upfront, without tying up the whole budget. The projected saving is ~58%, about $18k a month, with the upfront portion paying back in under five months.

Crucially, Priya doesn't push to cover 100%. She agrees with the team to commit to ~85% of the stable baseline and leave the rest On-Demand, precisely because these commitments can't be unwound — if engineering right-sizes or moves to Graviton next year, an over-bought reservation becomes stranded waste. She adds two standing numbers to the cost pack: RDS coverage (target 80–95%) and RDS reservation utilisation (must stay near 100%), and the renewal date goes straight onto the finance calendar.

The headline impact is a missed discount on a large, predictable line item. Databases are typically 15–30% of the cloud bill and run 24x7 — the most committable spend you have. Leaving a stable fleet at On-Demand forgoes a discount of up to ~60% on that slice. On a six-figure-a-month RDS bill, that's a seven-figure annual saving sitting uncollected, and unlike most cost-optimisation work it requires no engineering change at all — just a purchase decision.

The reason it gets missed is structural: Savings Plans don't cover databases, so the RDS tier never appears in the commitment-coverage number most finance teams watch. You need a separate coverage metric for RDS — RDS-hours-covered divided by RDS-hours-run — and a separate utilisation metric — the percentage of reserved capacity actually consumed. Coverage tells you how much discount you're capturing; utilisation tells you whether you've over-bought. Both belong on the monthly pack as their own lines, not folded into the compute number.

The three payment options are a genuine cash-versus-discount tradeoff, and that decision is finance's to make. No Upfront ties up no capital but gives the shallowest discount; All Upfront gives the deepest discount but is a real cash outlay today; Partial Upfront sits between. The right choice depends on the cost of capital and cash position, not on engineering preference — which is exactly why this should be a finance-led conversation with an explicit payback calculation, not a default buried in a console wizard.

The risk to guard against is over-commitment, because these reservations cannot be undone. A reservation bought before a right-size, an engine migration, or a Graviton move becomes stranded — billing against capacity no one runs. The protective rule is simple and finance can hold the line on it: commit to roughly 80–90% of the stable baseline only, never the peak, and never ahead of a known architecture change. Coverage in the high-80s with utilisation near 100% is the target; 100% coverage with sagging utilisation means money is being wasted on reservations, which is worse than the original problem.

Managed databases are usually one of the top three cloud costs, and they're the most predictable — they run continuously and rarely change shape week to week. That makes them the ideal candidate for a commitment discount of up to ~60%. The catch is that the company-wide Savings Plan most teams rely on doesn't cover databases at all; they need a separate, deliberate Reserved Instance decision.

The one question worth asking: "What share of our database spend is on a commitment, and is that the right share given how stable these databases are?" A stable, long-lived database fleet running at On-Demand rates is money left on the table. The discipline this category signals is whether the organisation is right-sizing and consolidating before it commits — because these commitments can't be undone, and an undisciplined buy locks in waste for years.

At one company, the cloud-cost review opened for months with a proud slide about Savings Plan coverage — 92% of compute committed. What the slide didn't say was that the entire database tier, a third of the bill, sat outside that number at full On-Demand price. No one had asked the question because "we have a Savings Plan" sounded like the job was done.

The exec sponsor changed the framing with one question: "What share of every major cost category is on a commitment, not just compute?" That surfaced the uncovered database spend immediately. The team did the right preparation — right-sized and consolidated the fleet first — then committed to a multi-year reservation covering the stable baseline, banking roughly 58% on a third of the bill.

The lasting outcome wasn't the one-time saving; it was the principle. Commitments follow stability, and they follow after right-sizing, never before. The review now tracks coverage across all commitment-eligible categories, and the database tier stopped being the quiet exception that everyone assumed was handled.

Databases are usually among the largest and most predictable cloud costs, which makes them the prime candidate for a multi-year discount of up to ~60%. The reason this lands on the report is that the company-wide commitment instrument everyone relies on — the Savings Plan — explicitly doesn't cover databases. So an organisation can look fully committed on its main dashboard while a third of the bill quietly runs at full price. The size of the uncovered database spend is a direct measure of money being left on the table.

The trend and the discipline behind it matter more than any single purchase. Because these commitments are multi-year and can't be reversed, the right pattern is to right-size and consolidate first, then commit to the stable baseline. An organisation that commits carefully after cleanup is banking durable savings; one that over-commits ahead of architecture changes is locking in waste it can't escape for years. Either way, whether RDS is covered at all is the tell for whether the commitment strategy actually reaches past the easy wins.