Production RDS databases on On-Demand pricing that would be cheaper reserved

Production databases are the natural reservation candidates

A production RDS instance tends to run every hour of every month, which is exactly the usage pattern a reservation rewards. The reserved DB instance guide describes three offering types. No Upfront bills a discounted hourly rate for every hour of the term and is only sold as a one-year reservation. Partial Upfront takes part of the price at purchase and bills the rest hourly. All Upfront is paid in full at the start. In every case the discount applies to instance hours, never to storage, backups or I/O.

Size flexibility softens the lock-in for most engines: a reservation for one size in a class family can cover other sizes in that family by normalized units. AWS lists MySQL, MariaDB, PostgreSQL, Db2 and bring-your-own-license Oracle as size-flexible; SQL Server and license-included Oracle are not.

Pricing a reservation for one database

aws rds describe-db-instances \
  --query 'DBInstances[?DBInstanceStatus==`available`].[DBInstanceIdentifier,DBInstanceClass,Engine,MultiAZ]'

aws rds describe-reserved-db-instances-offerings \
  --db-instance-class db.m6g.large --product-description mysql \
  --duration 1 --offering-type "No Upfront" --no-multi-az

Compare the offering’s recurring hourly charge with the On-Demand rate for the same class and deployment. The difference times 730 is roughly the monthly saving before storage.

What ZopNight requires before recommending a purchase

1. The DB instance status is available.
2. It reads as production: an environment tag (env, environment, stage or tier) with a production value, or a name containing prod, production, live or prd. A dev or test environment tag vetoes it even if the name says production.
3. No Reservation or Savings Plan label appears in its billing data, and it has no ri_covered=true tag.
4. The monthly cost is positive and comes from the bill, not a ZopNight estimate.
5. At least 60 days of history, 70% or higher uptime, and average CPU (or memory, where reported) of 30% or more.

Cases that produce no recommendation

Anything tagged dev or test, anything in a stopped or modifying state, and anything already covered is skipped. An under-used production database is also skipped: resizing it first means the reservation is bought for the class it actually needs. Without a live reserved rate for the class and Region the rule cannot prove a saving, so it raises nothing. For a coverage view that does not depend on the production label, see RDS RI Coverage Below 50%.

How the figure in the finding is built

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

The headline percentage is that saving divided by the full monthly bill, so it is deliberately smaller than the discount AWS advertises on the instance rate alone.

Purchasing the reserved DB instance

1. Confirm the database will stay on this engine, Region and class family for 12 months.
2. Check the AWS Cost Explorer RDS reservation recommendation as a second opinion.
3. Buy the offering: aws rds purchase-reserved-db-instances-offering --reserved-db-instances-offering-id <offering-id> --db-instance-count 1
4. For Multi-AZ instances, buy the Multi-AZ offering so both nodes are covered.