Savings Plans do not cover RDS, and the coverage gap sat at 40 to 60 percent

Teams assume the compute Savings Plan blankets the database line. It does not, and the belief is expensive precisely because it feels settled: the estate holds a lever it thinks it already pulled, on the least optimized block of the entire bill.

Prepared by Redress Compliance · August 15, 2026 · AWS advisory. Based on 20 to 30 benchmarked AWS database estates, 2024 to 2025.

• Serverless v2 fits genuinely spiky workloads, and a floor set too high erases the benefit, since a steady workload on a high ACU floor costs more than a reserved provisioned instance doing the same job.
• Storage scales automatically, which makes archive and partition discipline a cost control rather than housekeeping.
• Every read replica is billed compute, so replica counts belong in a quarterly review against actual read traffic.
• License included reprices the licence into the hourly rate, so you pay for it again every hour, while BYOL consumes licences you already own and keeps you inside the vendor's audit perimeter.
• Open source engines on Graviton are the lowest cost stable state on the platform, with no licensing question attached.
• Run both licensing models against your actual shelf before renewal, because estates commonly pay license included while holding shelfware BYOL would have consumed.

The standard advice is to start with an engine migration to open source and treat the rest as noise. In the estates we benchmarked, the unglamorous levers recovered 25 to 45 percent of the database line in under a quarter with no project risk, while engine migrations took 9 to 18 months and stalled about half the time. Both facts can be true, and the sequencing is what matters.

The Savings Plans gap is worth dwelling on because of how it fails. A team that has bought a compute Savings Plan reasonably believes the discount question is handled, and nothing in the bill announces otherwise: the database line simply carries on at on demand rates inside a total that looks optimized. Coverage then drifts to 40 to 60 percent on workloads that run continuously and would justify 80 to 90. The money is not lost to a hard decision anyone made. It is lost to a plausible assumption nobody tested, which is why it survives across years and renewals.

The same pattern explains the non production tier. Idle and oversized development and test instances made up 25 to 35 percent of the RDS line before cleanup, and they persist because they belong to nobody in particular. Production databases have owners who defend them. A test instance spun up for a project that ended has no advocate and no accuser, so it runs. Scheduling and rightsizing that tier is not clever work, but it removes spend that would otherwise be baked into the next commitment forecast as if it were demand.

That is the connection back to the commitment. Database spend draws down the commitment like any other service, so the database growth curve belongs in the commitment model, built after rightsizing rather than before. Forecasting unmanaged database growth and committing against it donates the entire optimization upside to the vendor: you pay for the waste twice, once in the bill and once in the commitment sized around it. Pull the pricing levers, rebaseline, then commit. The commitment sizing sits in the renewal strategy, the support line in the support brief, and the year round controls in the vendor management playbook.

Across roughly 20 to 30 AWS database estates benchmarked in 2024 and 2025, the database line was the least optimized block of the bill:

The patterns: a Savings Plan assumed to cover databases, coverage never measured against steady state hours, and commitment forecasts built on an unoptimized run rate.

The buyer side move is to price the line before you forecast it. The wider library sits in the AWS practice.

Do Savings Plans cover RDS and Aurora?

No. Database instances discount through Reserved Instances only, so a compute Savings Plan does not blanket the database line. That assumption is the single largest miss we find on AWS database estates, because the team believes a lever is already pulled when it was never available.

What Reserved Instance coverage should a database estate hold?

Steady state production databases usually justify 80 to 90 percent coverage. In the estates we benchmarked, actual coverage sat at 40 to 60 percent. Closing that gap is pure price with no engineering work, which is why it is the first lever rather than the interesting one.

When does the Aurora I/O optimized configuration pay?

When I/O charges pass roughly a quarter of your Aurora spend. Aurora bills compute, storage and I/O separately, and the I/O optimized configuration folds I/O into the instance price. On transaction heavy workloads the switch cut Aurora bills 25 to 40 percent in our file.

How much of the RDS line is non production waste?

Idle and oversized non production instances made up 25 to 35 percent of the RDS line before cleanup. Scheduling and rightsizing that tier is unglamorous work that removes spend nobody defends, and it should happen before any commitment is sized around the total.

Should you migrate engines to cut the database bill?

Only after the pricing levers are exhausted. Engine migrations took 9 to 18 months and stalled about half the time, while Reserved Instance coverage, the Aurora configuration switch and non production cleanup recovered 25 to 45 percent in under a quarter with no project risk. Let the migration case stand on strategy, not on savings.

What does license included cost against BYOL?

License included reprices the commercial licence into the hourly rate, so you pay for it again every hour, in exchange for a clean position on those workloads. BYOL consumes licences you already own but keeps you inside the vendor's audit perimeter. Run both models against your actual shelf before renewal.

Does Graviton reduce the database bill?

Yes, on supported engines. Moving MySQL, PostgreSQL and MariaDB workloads to Graviton instances took 10 to 20 percent off compute with no licensing change, which makes it one of the few genuinely low risk moves on the list.

How does database spend affect the commitment?

It draws down the commitment like any other service, so the database growth curve belongs in the commitment model. Build the forecast after rightsizing rather than before, because committing on the assumption of unmanaged database growth hands your own optimization upside to the vendor.