RDS instances under 10% CPU for 30 days that can drop one size within the same class family

Instance class is the part of the RDS bill that tracks size

An RDS bill has several lines: instance hours, allocated storage, provisioned IOPS, backup storage and data transfer. Only the instance-hours line depends on the class. RDS instances are billed per second with a 10-minute minimum after a billable change, at an hourly rate set by the class. A database that averages a few percent CPU all month is paying for cores it does not use.

Pulling the three metrics that matter

for m in CPUUtilization FreeableMemory DatabaseConnections; do
  aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name $m \
    --dimensions Name=DBInstanceIdentifier,Value=orders-db \
    --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \
    --period 86400 --statistics Average Maximum Minimum
done

Look at the CPU average and maximum, the minimum of FreeableMemory, and the peak of DatabaseConnections.

Conditions for a downsize finding

1. The instance is available.
2. Average CPUUtilization over 30 days is below 10%, and the trusted peak is below 80%.
3. The lowest FreeableMemory in the window is at least 512 MiB. RDS reports free memory but not total memory, so ZopNight uses this absolute floor as its memory-pressure test.
4. When a connection series is present, it peaked above zero. A database with no connections at all is an idle case, not a downsize.
5. For PostgreSQL, MySQL and MariaDB, average and peak connections stay under 80% of the smaller class’s default max_connections. RDS derives that default from memory; for MySQL the limits page gives it as DBInstanceClassMemory/12582880.
6. The next size down is a class RDS actually offers. ZopNight checks the target against RDS’s published classes, so it never suggests a size that exists on EC2 but not on RDS.

Databases that stay off the list

When the memory series shows pressure, the connection count would crowd the smaller class, no valid smaller class exists, or either hourly rate is missing, ZopNight says nothing. It also stays silent when measured uptime is zero or the smaller class is not cheaper. The rule only recommends; ZopNight never modifies an RDS instance from this finding.

Compute-only saving

saving = (current hourly rate - target hourly rate) x 730 x measured uptime share
capped at monthly cost x (1 - target rate / current rate)

Storage, IOPS and backups do not shrink when the class does, so they are excluded. If uptime is unknown, ZopNight assumes 24x7. Instances that run part-time, such as a nightly test database, get a proportionally smaller figure.

Resizing with the least disruption

1. Review Performance Insights for heavy queries that averages can hide.
2. Schedule the change for the maintenance window, since a class change causes downtime: aws rds modify-db-instance --db-instance-identifier orders-db --db-instance-class db.m5.large
3. Watch CPU, FreeableMemory and read latency for 48 hours afterwards.