Oversized RDS instances
A database provisioned for a peak that never came bills for the size it has, not the size it uses.
What this problem is
RDS bills for the instance class — provisioned CPU and memory — continuously, regardless of load. A database sized to absorb a traffic peak costs that peak's price all month, whether the peak arrives once a quarter or has never arrived at all.
Oversizing in databases has a specific cause: it is the resource people are most afraid to resize. An idle EC2 instance gets shut down without much deliberation; a production database does not. So the class chosen at the start of a project — usually with generous headroom, out of caution — tends to survive for years, even once the metrics show the headroom is far larger than needed.
Unlike an idle instance, the resource here is legitimately in use: the database serves queries and the application depends on it. What is wrong is the ratio between what was provisioned and what is consumed — and the fix is to step the class down, not to switch it off.
How we detect it
We list database instances with DescribeDBInstances and read the metrics RDS publishes to CloudWatch via GetMetricStatistics — CPU utilization, freeable memory, connection counts — over a window long enough for a genuine peak to appear.
- Over-provisioned RDS databases
What it costs
Pricing varies widely by class: a db.t3.medium runs about $50 a month, a db.m5.large about $125, a db.r5.xlarge about $340 (us-east-1, single instance, on demand). Each step down the family typically halves the price.
Public AWS list prices, us-east-1, subject to change. The figure in your report is computed against your resources in your regions.
How it appears in the report
An illustrative example, with invented resources and figures. In the report each finding carries the real resource, its region, and the fix command where a safe one exists.
Does your account have this?
The scan is read-only and shows you what it found before you pay for anything.
Run a free scan