RDS DB instances with no reserved DB instance covering their instance hours

What a reserved DB instance does and does not discount

A reserved DB instance is a one-year or three-year billing discount applied to matching DB instance usage in the same Region and engine. AWS is explicit about its limits: the reservation provides no discount for storage, backups or I/O, only for the hourly instance usage. In AWS’s own worked example, a db.r5.large MySQL reservation saves a little over $11 a month on a bill that also carries $64 of storage and backup charges that stay exactly the same.

That split matters for anyone estimating a purchase. Divide an RDS bill by the instance-hour rate and you overstate the saving; the part the reservation touches can be a small share of a storage-heavy database.

Seeing what is already reserved

aws rds describe-reserved-db-instances \
  --query 'ReservedDBInstances[?State==`active`].[DBInstanceClass,ProductDescription,MultiAZ,DBInstanceCount]'

aws ce get-reservation-coverage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --group-by Type=DIMENSION,Key=DATABASE_ENGINE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}'

Coverage is reported in hours, so an engine at 40% means 60% of its instance hours were billed at On-Demand rates last month.

How ZopNight decides a database needs coverage

The check runs on every rds DB instance, production or not:

• Its billing lines carry no Reservation or Savings Plan label. That counts as 0% coverage, under the 50% bar in the rule’s name.
• ZopNight holds a positive monthly cost for it, and that cost comes from the bill rather than from its own price estimate.
• At least 60 days of history, measured uptime of 70% or more, and average CPU of at least 30% (or memory, where reported).
• The reservation still wins on the compute-only comparison described below.

Databases this rule leaves out

A development database that runs nights only fails the uptime floor and is better served by stopping or scheduling. A lightly loaded database should be resized before anyone commits to its class for a year. If the live reserved rate for the class and Region is missing, nothing is priced and nothing is raised. Production databases may also see RDS Reserved Instance Opportunity, which applies stricter production and status checks to the same purchase. Both findings price that one reservation the same way, so for a production database count the saving once, not twice.

Pricing the reservation against instance hours only

basis   = lower of (current monthly bill, On-Demand instance rate x 730)
saving  = basis - (1-year No Upfront reserved rate x 730)

Capping the basis at the On-Demand instance cost removes storage, IOPS and backup from the comparison. When the On-Demand rate for the class is unknown, the full bill is used instead.

Closing the coverage gap

1. List offerings for the exact class, engine and deployment: aws rds describe-reserved-db-instances-offerings --db-instance-class db.r6g.large --product-description postgresql --duration 1 --offering-type "No Upfront"
2. Check whether the engine supports size flexibility (Db2, MySQL, MariaDB, PostgreSQL and BYOL Oracle do; SQL Server and license-included Oracle do not).
3. Match Multi-AZ to how the instance is deployed.
4. Purchase, then confirm coverage rises in the next Cost Explorer report.