RDS instances running on-demand with no Reserved Instance coverage
What does ZopNight detect here?
ZopNight flags an RDS instance with no reservation on file only after 60+ days of history, high uptime and real utilization prove it a commitment candidate, then prices a 1-year RI at 730 hours against the compute-only line. Storage, IOPS and backups are excluded because an RI never discounts them.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1507 |
| Category | discount |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | ri_rds_coverage.go |
Where it applies
Coverage comes from billing data, not a tag
The authoritative signal is the reservation-coverage map derived from the AWS Cost and
Usage Report. A database whose usage already carries a Reservation or Savings Plan
label is covered, so the rule abstains rather than recommend re-buying. A database with
no label has no commitment at all: 0% coverage, exactly the below-50% gap this rule
exists to close. When an ri_coverage_pct tag is present it refines the displayed
percentage (and a tagged value of 50 or above suppresses the finding), but the tag
never decides firing. An earlier version gated on that tag alone, and since nothing
ever produced it, the rule was permanently dead.
An RI only discounts compute
An RDS Reserved Instance discounts the instance-hour line and nothing else. Storage, provisioned IOPS and backups go on billing at list price regardless. Feeding the full monthly bill into the break-even would credit the RI with money it never touches: on a 500 GB instance the overstatement approaches 77%. So the break-even basis is capped at the on-demand compute rate times 730 hours whenever that catalog rate is known, and the RI is recommended only when its fixed monthly price undercuts the compute-only basis. The saving is the exact net difference, never a flat percentage.
Proving the database deserves a commitment
A reservation is a 1- or 3-year lock-in, so the rule demands evidence first: at least 60 days of observed history, high uptime, and meaningful utilization. A part-time database gets uptime-suppressed, because buying 730 hours a month for an instance that runs office hours wastes most of the commitment. An underutilized one should be rightsized before anything is locked in.
When nothing is reported
Each of these abstains: existing Reservation or Savings Plan coverage, a coverage tag at or above 50%, a missing or zero monthly cost, a failed eligibility bar, measured uptime below the commitment floor, or missing live RI rates. The rule never falls back to a published average discount when the real rates are absent.
Audit your coverage in one call
aws ce get-reservation-coverage \ --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \ --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}'A CoverageHoursPercentage under 50 across a stable fleet is this rule’s territory.
Before purchasing, match the RI to the engine and instance class, weigh 1-year against
3-year terms, and check Multi-AZ alignment. A reservation that does not match what
actually runs discounts nothing.