RDS is one of the top-5 AWS cost drivers for most application teams. Unlike Lambda or S3 where you pay only for what you use, RDS instances run continuously — you're paying 24/7 for provisioned capacity regardless of whether your database is under load. That makes right-sizing and commitment planning critical.
This guide covers the RDS cost optimization levers that produce the largest savings without compromising reliability.
Understanding RDS Cost Components
RDS cost has several components worth tracking separately:
- Instance cost: The largest component. Per-hour pricing for the DB instance class, running continuously.
- Storage cost: GP2/GP3/io1/io2 storage per GB-month, plus provisioned IOPS if using io1/io2.
- Backup storage: Free for up to 100% of your database storage; charges apply beyond that.
- Data transfer: Egress costs for data transferred out of the region or to the internet.
- Multi-AZ premium: Multi-AZ deployments cost ~2x single-AZ (standby replica maintained in a second AZ).
For most teams, instance cost is 60-75% of the total RDS bill. That's where optimization starts.
Step 1: Right-Sizing — The Biggest Win
The most common RDS waste pattern: databases provisioned with a large instance class "just in case" and running at 10-20% CPU utilization. Over-provisioned databases are expensive insurance against a problem that doesn't exist.
CloudWatch metrics to review:
- CPUUtilization: If consistently below 20-30%, you're over-provisioned on CPU
- FreeableMemory: If consistently above 2-4 GB, you have excess memory
- DatabaseConnections: Connection count vs instance maximum
- ReadIOPS / WriteIOPS: IOPS utilization vs instance limits
The right-sizing process: 1. Pull 4 weeks of CPU, memory, and IOPS metrics (P90, not average — average hides spikes) 2. Identify the target instance class that comfortably handles P90 utilization 3. Check the next-smaller instance class for fit 4. Test with a production-like load before committing to the smaller class
Using AWS Compute Optimizer for RDS: AWS Compute Optimizer analyzes CloudWatch metrics and recommends optimal instance classes. Navigate to Compute Optimizer → RDS for automated recommendations. It identifies over-provisioned instances and estimates monthly savings.
Practical example: An db.r5.2xlarge running at 15% CPU and 30% memory utilization can typically be right-sized to db.r5.large or db.r5.xlarge, saving $400-$800/month for a single instance.
Important caveat: Right-sizing Multi-AZ deployments doubles your savings since you're paying for both the primary and standby. A db.r5.2xlarge Multi-AZ running at 15% can be the highest-priority right-sizing target on your account.
Step 2: Reserved Instances — 30-50% Instant Savings
After right-sizing to the correct instance class, Reserved Instances (RIs) lock in significant discounts on the instances you know you'll run continuously.
RDS Reserved Instance discounts:
| Term | Payment | Discount vs On-Demand |
|---|---|---|
| 1-year | No upfront | ~27% |
| 1-year | Partial upfront | ~32% |
| 1-year | All upfront | ~35% |
| 3-year | All upfront | ~50%+ |
For production databases running 24/7 with a predictable instance class, 1-year Partial Upfront is the standard recommendation. The ROI is realized within a few months.
RI strategy for RDS: - Buy RIs for stable production databases with known instance classes - Use On-Demand for dev/test databases and new workloads not yet stable in class - Consider Convertible RIs if you anticipate instance class changes (slightly less discount but exchangeable)
Multi-AZ RIs: Multi-AZ Reserved Instances provide discounts on the full Multi-AZ cost. Confirm your RI purchase is for the correct Multi-AZ flag.
Step 3: Storage Optimization — GP3 Migration
If your RDS instances are still using GP2 storage, migrating to GP3 saves 20% on storage cost with better or equivalent performance.
GP2 vs GP3: - GP2: $0.115/GB-month, IOPS scale automatically with storage size (3 IOPS/GB, up to 16,000) - GP3: $0.092/GB-month, baseline 3,000 IOPS and 125 MB/s throughput included, provisioned IOPS additional
For most databases not requiring extreme IOPS, GP3 at baseline delivers the same performance as GP2 at 20% lower cost. Migration is a modify operation (minimal downtime window).
Large storage databases: For databases using io1 provisioned IOPS storage, evaluate whether actual IOPS usage justifies the cost. io1 IOPS pricing ($0.10/IOPS-month) on over-provisioned configurations can add hundreds to thousands per month in waste.
Step 4: Aurora Serverless v2 for Variable Workloads
For databases with variable traffic patterns — business-hours-only applications, staging environments, batch processing databases — Aurora Serverless v2 can reduce costs dramatically by scaling down to 0.5 ACUs during low-traffic periods.
Aurora Serverless v2 pricing: - $0.12/ACU-hour (Aurora Capacity Units) - Scales from 0.5 to 128 ACUs based on load - 1 ACU ≈ ~2 GB memory + proportional CPU
When Serverless v2 is cost-effective: - Applications with 40%+ of hours at low utilization (nights, weekends) - Staging/dev environments that are idle most of the time - Event-driven applications with periodic burst traffic
When provisioned Aurora is better: - Consistent high-traffic production databases where Serverless v2 scaling overhead affects latency - Applications requiring the absolute lowest latency (Serverless v2 has milliseconds of scaling latency)
Staging environment example: A staging database running on db.r5.large at ~$0.24/hour = $175/month. Migrating to Aurora Serverless v2 that scales to 0.5 ACU during 75% off-hours = ~$0.06/hour average = $43/month. Savings: ~75%.
Step 5: Stop Dev/Test Databases When Not in Use
RDS instances in development and testing environments run 24/7 by default. Stop them outside business hours.
Implementation: - AWS Instance Scheduler or custom Lambda + EventBridge: Start instances at 7 AM, stop at 8 PM weekdays - Skip weekends entirely for dev databases
For a db.r5.large at $0.24/hour:
- Running 24/7: $175/month
- Running business hours (55 hours/week): ~$95/month
- Savings: ~45%
This applies to EC2 as well. A comprehensive instance scheduling policy for non-production environments typically saves 35-50% of dev/test compute costs.
Query Optimization: The Downstream Cost Multiplier
Query performance indirectly affects RDS costs. Inefficient queries drive higher CPU and IOPS utilization, which can cause right-sizing to a smaller instance to fail even when the database is actually under-utilized in aggregate.
Performance Insights (included with most RDS versions): The single best tool for identifying expensive queries. Shows database load broken down by wait events and top SQL statements. Identify the top 10 queries by total load and optimize them before making right-sizing decisions.
Parameter group tuning: Default RDS parameter groups are conservative. Tuning shared_buffers (PostgreSQL), innodb_buffer_pool_size (MySQL), and other memory parameters to better utilize available instance memory can significantly improve performance on the current instance class.
Rutagon's FinOps practice delivers systematic RDS and multi-service cost optimization. Contact us to discuss an RDS cost audit.
Frequently Asked Questions
How do I know if my RDS instance is over-provisioned?
Review 4 weeks of CloudWatch metrics: CPUUtilization, FreeableMemory, ReadIOPS, and WriteIOPS. If CPU P90 is consistently below 30%, memory P90 is above 2-4 GB free, and IOPS are well below instance limits, you're likely over-provisioned. AWS Compute Optimizer provides automated recommendations based on this analysis.
What's the risk of right-sizing a production database?
Right-sizing carries some risk: if your traffic spikes in ways not captured in the 4-week baseline, a smaller instance may struggle. Mitigate risk by: testing on staging first, right-sizing to the next-smaller class (not dramatically smaller), setting up CPU/memory alarms at 80% to catch under-provisioning before it impacts users, and having a plan to scale back up quickly if needed.
Should I use Aurora instead of RDS MySQL/PostgreSQL?
Aurora provides better performance and reliability than standard RDS at a price premium (typically 20-30% more than equivalent RDS instances). For critical production databases, the Aurora advantages (faster failover, automatic storage scaling, Serverless v2 option) often justify the premium. For smaller or less critical workloads, standard RDS MySQL/PostgreSQL is cost-effective and simpler.
What's the best way to handle RDS backup costs?
RDS provides free backup storage equal to 100% of your database storage size. You only pay beyond that. Control backup retention period (7 days is usually sufficient for most applications — 35 days is rarely needed), and for very large databases, consider AWS Backup with lifecycle policies to move old backups to cold storage. Also ensure you're not retaining manual snapshots indefinitely.
Is Multi-AZ always necessary for production RDS?
Multi-AZ provides automatic failover (typically 60-120 seconds) in case of AZ failure. For truly mission-critical databases, it's worth the 2x cost. For applications that can tolerate 5-15 minutes of manual failover, or where the database is a non-critical component, single-AZ is acceptable. Read replicas can also provide read scalability at lower cost than Multi-AZ for read-heavy workloads.