RDS is usually the biggest line item on your bill after EC2, and the one you're most afraid to touch. "Downsize the production database" sounds like an excellent way to cause an outage and get paged at 2am. That fear is completely reasonable — and it's also exactly the problem, because it's why over-provisioned databases stay over-provisioned for years. This post gives you a conservative, safe procedure: how to know an instance really is oversized, how to make the change with seconds of downtime or none, and what to watch afterward so you don't get a nasty surprise two weeks later.
How do I tell an RDS instance is actually oversized?
Don't guess from the instance class name. Look at what the database actually does over a 14-day window, using these CloudWatch metrics:
CPUUtilization— sustained low CPU (say, a 14-day max well under 40%) suggests headroom you're paying for.FreeableMemory— consistently high free memory means you provisioned more RAM than the workload uses.DatabaseConnections— how busy the database really is; a handful of connections on a large instance is a strong signal.ReadIOPS/WriteIOPS— whether your I/O is anywhere near what the instance and storage can deliver.
For EC2 you can't see memory utilization without installing the CloudWatch agent, which is why EC2
rightsizing is often a guess. RDS is different: FreeableMemory is published by default, no agent
required. That single metric makes RDS rightsizing genuinely more trustworthy than EC2 rightsizing —
you can actually see whether the memory you're paying for is being used, instead of inferring it. Lean
on it.
Pull the memory metric for a candidate instance like this:
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name FreeableMemory \
--dimensions Name=DBInstanceIdentifier,Value=my-prod-db \
--start-time "$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--period 86400 \
--statistics Average Minimum \
--region us-east-1 \
--output table
If free memory never drops much below its ceiling and CPU stays low across two weeks that include your real peak load, the instance is a legitimate downsize candidate.
Is idle the same as oversized? (No — and it matters)
These are two different findings with two different fixes, and treating them the same is how people cause problems.
Oversized means the database is used, just bigger than it needs to be — the fix is to move to a smaller instance class. Idle means it's barely used at all: a dev or staging database with zero or near-zero connections for weeks. You don't downsize an idle database, you stop or delete it. Downsizing something nobody's using still leaves you paying for something nobody's using.
This is the RDS gotcha that catches everyone: when you stop an RDS instance, AWS automatically starts it again after 7 days. People stop a dev database to save money, see the charges stop, and assume it's handled — then a week later it silently comes back and starts billing again, and they never notice. If you truly don't need an idle database, delete it (take a final snapshot first) rather than relying on "stopped." If you need it occasionally, automate a scheduled stop, because a single manual stop will not stay stopped.
For how we flag a database with no real activity, see Idle RDS instance.
What's the safe way to actually downsize?
Here's the good news that defuses most of the fear: whether downsizing is a non-event or a real outage depends almost entirely on one setting — Multi-AZ. Do not let anyone imply that downsizing RDS is always zero-downtime. It isn't. It depends.
- Multi-AZ deployment: when you modify the instance class, AWS applies the change to the standby first, then fails over to it. The interruption is a failover — typically 60–120 seconds — not a full outage. Your application should reconnect and carry on. This is genuinely low-risk, and it's the reason to run production databases Multi-AZ in the first place.
- Single-AZ deployment: there is no standby to fail over to, so the modification takes the database offline while it's applied — real downtime, potentially several minutes. Schedule a maintenance window, tell people, and treat it like the outage it is.
Apply the change (with --apply-immediately only if you accept the failover/downtime happening now rather than in the next maintenance window):
aws rds modify-db-instance \
--db-instance-identifier my-prod-db \
--db-instance-class db.r6g.large \
--apply-immediately
Because this modifies a production database, generating and reviewing the change carefully matters — see running scripts safely before you run anything against prod.
Do it in staging first — and watch the right thing after
The failure mode of downsizing is not immediate, and that's what makes it sneaky. The database won't fall over the moment you resize it. What happens is subtler: p99 latency starts creeping up two weeks later, when peak load lands on the smaller instance and the memory or IOPS headroom you removed turns out to have been doing something after all.
So be conservative:
- Reproduce in staging first with production-like load if you possibly can. A downsize that's fine at Tuesday-afternoon traffic can struggle at month-end batch time.
- After the change, watch for at least a full business cycle — a week or two that includes your real peak, not just the first calm hour. Track
CPUUtilization,FreeableMemory,ReadLatency/WriteLatency, and application p99. If latency drifts upward under load, size back up; one class too small is worse than one class too big.
What about storage and IOPS?
Instance class is only part of the RDS bill. Storage and provisioned IOPS are billed separately, and over-provisioned IOPS is its own quiet waste. If you're on io1/io2 with a high provisioned-IOPS number your ReadIOPS/WriteIOPS metrics never approach, you may be paying for throughput you don't use — and gp3 often delivers the baseline you actually need for less. Right-sizing the instance and forgetting the storage leaves money on the table.
One asymmetry to plan around: RDS lets you grow storage on the fly but not shrink it. So over-provisioned storage can't simply be dialled back the way an instance class can — undoing it means creating a new, smaller instance and migrating data. The lesson is forward-looking: provision storage for the near term and let it grow, rather than allocating a huge headroom you can never reclaim. And if the metrics say your bottleneck was never IOPS in the first place, moving from io2 to gp3 is frequently the single biggest storage saving available, with no change to the instance class at all.
Finally, if you do need to change the engine version or do something riskier than a resize, reach for an RDS Blue/Green deployment rather than modifying in place — it stages the change on a copy and lets you switch over deliberately. Overkill for a simple downsize on Multi-AZ, but the right tool when the change is bigger than an instance class.
What else should I check?
The same "provisioned for a peak that never comes" pattern shows up in compute, not just databases — over-provisioned and idle EC2 instances are the direct analog, and usually more numerous. If you're auditing RDS sizing, audit EC2 too. See how to find idle EC2 instances.
How do I find this across my whole AWS account?
Reviewing one database's metrics by hand is straightforward. Doing it for every RDS instance in every region — correlating CPU, memory, connections, and IOPS, and separating genuinely idle databases from merely oversized ones — is the tedious part, and the part where the fear keeps people from ever starting. That's what a scan is for. Parsivex checks each region, flags over-provisioned and idle RDS instances against real 14-day metrics, and estimates the monthly savings for each.
For what these findings mean once they show up in your report, see Over-provisioned RDS instance and Idle RDS instance.