What triggers this finding
An available RDS instance with average CPU below 10% where a smaller instance class is recommended (idle instances with near-zero connections are flagged separately as rds_idle).
Typical fix
Downsize the instance class during a maintenance window, or migrate to Aurora Serverless v2 for variable workloads.
Example savings
Varies by instance class — typically 25–50% of instance compute cost when moving one size down.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
What a class step is worth, and what it leaves behind
RDS instance classes are priced linearly within a family, so each step down the right-sizing map halves the instance rate: db.r5.2xlarge at $700.80 a month becomes db.r5.xlarge at $350.40, db.m5.xlarge at $277.40 becomes db.m5.large at $138.70. Parsivex reports that difference, and only ever proposes one step.
Multi-AZ multiplies both sides by two, so the saving doubles along with the cost. An over-provisioned Multi-AZ database is worth twice as much to right-size as the same class running single-AZ.
The estimate covers the instance class and nothing else, and on RDS that exclusion is larger than it looks. Allocated storage, provisioned IOPS, backup storage, and data transfer all bill independently of the class and are completely unchanged by a downsize. On a database with 4 TB of gp3 and heavy backup retention, halving the class may move less than half the total bill. Read the finding as "the compute line halves", not "the RDS bill halves".
The band, and why it is narrower than EC2's
Four conditions have to hold: the instance is available, its 14-day average CPUUtilization is above 0% and below 10%, a next class down exists in the right-sizing map, and that class is priced.
Ten percent is deliberately half the 20% threshold used for oversized EC2. Databases are bound by memory and I/O far more often than by CPU, so a low CPU average is much weaker evidence of spare capacity here than it is on an application server. The tighter threshold is the detector being cautious on purpose.
There is also a floor from the adjacent detector. Anything meeting the idle RDS criteria is claimed by that finding first and excluded from this one, so the two never both fire on the same instance. An over-provisioned finding always describes a database that is genuinely serving connections.
The right-sizing map itself is the narrowest constraint: it covers db.r5, db.m5, and db.t3, so a database on db.r6g, db.m6i, or any other family produces no finding regardless of how quiet it is. Unlike the EC2 equivalent there is no size floor — db.t3.medium to db.t3.small is a valid step.
Metrics that veto the recommendation
CPU is what triggers the finding. It is rarely what should decide it.
aws cloudwatch get-metric-statistics --namespace AWS/RDS \
--metric-name FreeableMemory \
--dimensions Name=DBInstanceIdentifier,Value=my-database \
--start-time 2026-07-29T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Minimum Average
FreeableMemory is the number that most often overrules a downsize. A class step halves the instance's RAM, and on a database whose working set currently fits in the buffer pool, that can turn an all-cache workload into a disk-reading one. CPU stays low right up to the point where latency collapses, so the CPU average gives no warning at all. If the minimum freeable memory is already a small fraction of total RAM, the class is not over-provisioned — it is correctly sized for its cache.
Three other checks belong alongside it. Burstable db.t3 classes bank CPU credits and are designed to run at a low average, so a low figure there is the intended behaviour rather than waste — look at CPUCreditBalance before stepping down. Connection limits scale with class, because the default max_connections parameter is a formula over instance memory, and halving memory halves the ceiling a connection pool can reach. And network and EBS bandwidth are provisioned per class too, which matters for replication-heavy or backup-heavy instances.
Commercially licensed engines add a fourth. Where Oracle or SQL Server licences are counted per vCPU, a downsize changes the licence position as well as the instance rate, and the two do not always move together.
Reversibility and what does not change
A class change is reversible in both directions — the same modify call takes the database back up — so the decision is recoverable even when the sizing judgement turns out to be wrong. Storage is the exception, and it is a permanent one: allocated storage on RDS can be increased but never decreased. A database over-provisioned on disk stays that way for its lifetime, so if storage is the larger line, the class change will not address it and neither will anything else short of a migration to a new instance.
Applying the change immediately restarts the database, which means an interruption; deferring it to the next maintenance window trades a scheduled outage for an unscheduled one. Either way, update the infrastructure code that declares the class in the same change — a Terraform module or CloudFormation template still naming the old class will restore it on the next apply, and the finding returns with it.