RDS Cost Optimization
Price exercises use hypothetical us-east-1 (US East, N. Virginia) rates for study on 2026-10-12, not current tariffs, unless explicitly identified as a dated published fee.
Optimize database compute, storage, I/O, replicas, backups and transfer while preserving durability and performance targets. Product, engine, Region and deployment topology change the bill.
Right-sizing and availability
Use CPU, free memory, connections, I/O, query latency and Database Insights evidence across representative peaks. Low average CPU alone does not justify downsizing. Verify engine/version/extension and license compatibility for Graviton instead of promising a universal price-performance improvement.
Single-AZ can suit recoverable development databases, but do not disable Multi-AZ merely because the environment is labeled non-production. A Multi-AZ DB instance standby serves failover, not read scaling; Multi-AZ DB clusters have different readable-instance behavior. Price the actual deployment rather than assuming every topology exactly doubles every charge.
Scheduling and serverless
Supported stopped RDS instances restart automatically after seven days. Storage and applicable backup charges remain while stopped; not every configuration supports stopping. Aurora cluster stop/start has separate constraints.
Aurora Serverless v2 scales in 0.5-ACU increments. Supported engine versions/configurations can use a 0-ACU minimum with automatic pause, so 0.5 ACU is not a universal minimum. Include resume latency, connection behavior and pause-blocking features in the decision. A maximum ACU is not a complete hard bill cap: I/O, storage and other services remain.
Storage and commitments
RDS gp3 baseline IOPS/throughput depends on engine and allocated storage. Do not copy EBS’s baseline or a blanket 20% saving into every RDS configuration. Storage autoscaling can reduce preallocation risk but cannot shrink already allocated storage; set an appropriate maximum and growth alarms.
Compare applicable RDS reservations and Database Savings Plans against expected eligible usage. Match reservation scope and deployment attributes. One primary-instance reservation does not make a standby free. Aurora Standard versus I/O-Optimized requires a measured compute/storage/I/O comparison.
Drill
For a supplied database inventory, calculate current compute, replicas, storage, I/O and backup costs. Propose one reversible optimization with query-latency, connection and failover acceptance criteria. Include a restore/rollback test and license review; do not execute stop or resize APIs as an unapproved cost exercise.
Separate database cost components
| Component | Optimization evidence | Risk to preserve |
|---|---|---|
| Instance/ACU compute | Peak CPU, memory, sessions and waits | Tail latency and connection behavior |
| Multi-AZ/readers | Availability and read demand | Failover versus read-scale requirements |
| Storage/performance | Growth, IOPS and throughput | Engine-specific baselines and durability |
| I/O model | Measured query/read-write behavior | Standard versus I/O-Optimized economics |
| Backup/restore | Retention and restore requirements | Recovery points and tested access |
| Transfer/licensing | Traffic topology and license terms | Compatibility, legal rights and availability |
A low average CPU may coexist with lock contention, large working sets or licensing constraints. Use Database Insights and application query evidence instead of repeating an obsolete universal Performance Insights recommendation.
Dev/test scheduling example
Assume a supported instance runs 10 hours on each of 22 weekdays in a 720-hour month. With a hypothetical us-east-1 study compute rate of $0.20/hour on 2026-10-12:
always-on compute = 720 × $0.20 = $144
scheduled compute = 220 × $0.20 = $44
gross avoidance = $100 (69.44%)If continuing storage/backups cost $60, totals become $204 versus $104: the overall reduction is about 49%, not 69%. Fixed commitments can reduce or eliminate actual avoidance. Respect stop support, seven-day restart and start-up readiness; a naive Lambda call is not a production scheduler.
Read-only configuration review, requiring authorized AWS CLI access:
aws rds describe-db-instances --region us-east-1 \
--query 'DBInstances[].{Id:DBInstanceIdentifier,Engine:Engine,Class:DBInstanceClass,MultiAZ:MultiAZ,StorageGiB:AllocatedStorage,Status:DBInstanceStatus}' \
--output jsonThe response does not certify that an instance is safe to stop. Inspect engine/deployment restrictions, replicas, owners and maintenance needs separately.
Serverless and gp3 lab
Compare minimum/maximum ACU, idle periods, resume latency and auto-pause blockers for the actual Aurora version. Test connection pooling and a resumed burst; a maximum ACU can cap capacity and cause errors without eliminating I/O/storage costs.
For gp3, look up the engine/storage-size baseline, required IOPS/throughput and candidate instance limit. Compare the actual configured price with the previous volume; do not apply the EBS baseline or a flat 20% saving. Storage autoscaling addresses growth but does not reclaim an oversized allocation.