A B2B SaaS company audited their AWS bill and found $19,400/month going to RDS for MySQL — for a workload that peaked at 8,000 connections and 4TB of data. After a three-week optimization pass (Graviton migration, gp2→gp3 storage, Reserved Instance swap, cross-AZ traffic reduction), their bill dropped to $10,200/month. Same performance. Same HA setup. $110,000 saved annually.
RDS MySQL is expensive because AWS makes it easy to oversize and because the default settings favor safety over cost. This guide covers the specific levers — in priority order — that actually move the bill.
- Right-size on Graviton (t4g/m7g/r7g) before anything else.
- Pick the cheapest deployment that fits your HA needs: Single-AZ → Multi-AZ DB Instance (2 nodes) → Multi-AZ DB Cluster (3 nodes).
- Use gp3 storage with only the IOPS/throughput you need; enable Storage autoscaling.
- Keep backups within free allowance; prune old manual snapshots.
- Stop non-prod nightly; schedule automatic stop/start.
- Use Reserved Instances for steady prod (1–3 years).
- Upgrade to MySQL 8+ to avoid Extended Support fees; enable Optimized Writes/Reads where applicable.
- Minimize cross-AZ data transfer between app and DB.
- Consider RDS Proxy only if connection storms force you to oversize.
1) Right-size the instance (start with Graviton)
- Prefer Graviton families (
db.t4g,db.m7g,db.r7g) for better price/perf. Most MySQL workloads see meaningful savings at the same or better performance. - Use burstable (
t) only for light, spiky loads; move tom/rfor sustained CPU. - Revisit vCPU/RAM after schema and index tuning; many fleets are 1–2 sizes too large.
2) Choose the right HA option (don’t overpay)
- Single-AZ: lowest cost; no automatic failover.
- Multi-AZ DB Instance: 1 primary + 1 standby (roughly double instance hours vs Single-AZ), automatic failover.
- Multi-AZ DB Cluster: 1 writer + 2 readers (3 instances). Faster failover, readable standbys; more expensive but higher performance and availability.
Tip: Match the tier to business impact. Many internal tools/dev/test don’t need Multi-AZ; prod OLTP usually does.
3) Storage: move to gp3 and size IOPS deliberately
- Use gp3 for most MySQL workloads. It decouples capacity from performance and includes a baseline of IOPS/throughput.
- Provision only what you need: set gp3 IOPS/throughput explicitly; avoid over-allocating “just in case”.
- Provisioned IOPS (io1/io2) only for consistently high I/O needs where gp3 can’t keep up; it’s pricier.
- Enable Storage autoscaling so capacity grows when needed (prevents disruptive emergency resizes).
4) Backups & snapshots: keep what you need, not everything
- Automated backup storage is free up to the size of your DB in the Region. Extra retention and manual snapshots beyond that free pool are billed.
- Prune long-lived manual snapshots; copy cross-region only when required for DR.
- Set retention by data-class (prod vs non-prod) and review monthly.
5) Shut down idle environments
- For dev/stage/sandboxes, stop RDS nightly/weekends. You keep paying for storage and backups, but you stop paying instance hours.
- Automate stop/start on a schedule using Systems Manager Maintenance Windows or EventBridge + Lambda.
6) Commit for steady prod: Reserved Instances
- For 24×7 prod, buy RDS Reserved Instances (1 or 3 years) to lock in deep discounts over On-Demand.
- Mix Standard and Convertible RIs when you need some flexibility.
7) Version & engine features that save money
- Upgrade to MySQL 8+ to avoid RDS Extended Support fees on EOL versions.
- Enable Optimized Writes (MySQL 8.0.30+) and Optimized Reads on supported instance types to raise throughput—often lets you run a smaller instance.
8) Watch paid observability
- Performance Insights: 7-day retention is free; longer retention is billed per vCPU per month. Keep only what you actually use for investigations.
- Enhanced Monitoring: useful, but dial down sampling where appropriate.
9) Tame connection storms with care
- RDS Proxy reduces connection overhead and failover pain for spiky/serverless apps, potentially avoiding an oversized DB.
- It has its own charge (per vCPU-hour/ACU). Use when it replaces more expensive instance sizing or fixes Lambda/serverless surges.
10) Minimize data transfer surprises
- Place app and DB in the same AZ to avoid cross-AZ charges between EC2 and RDS.
- Replication to read replicas in the same Region doesn’t incur data transfer charges; cross-Region replication does.
Quick win matrix
| Action | Effort | Typical impact | When to do it |
|---|---|---|---|
| Switch to Graviton | Low–Med | Lower $/perf | Any time you can redeploy or during maintenance |
| Move gp2/PIOPS → gp3 | Low | Lower storage $ | Most workloads not requiring sustained high IOPS |
| Enable storage autoscaling | Low | Avoid emergency resizes | Immediately |
| Right-size instance | Low | Lower instance $ | After a week of metrics/PI review |
| Schedule stop/start (non-prod) | Low | ~50–70% instance $ off-hours | Dev/test/sandbox |
| Buy RIs for prod | Low | Deep discount | Stable 24×7 workloads |
| Prune snapshots | Low | Lower backup $ | Monthly |
| Upgrade to MySQL 8+ | Med | Avoid ES fees + features | Before ES kicks in |
| Add RDS Proxy | Med | Smaller DB possible | Spiky/serverless connection patterns |
JusDB’s recommended rollout (safe & simple)
- Measure a week: CPU, memory, read/write IOPS, throughput, connections, slow queries.
- Right-size on Graviton; switch storage to gp3; enable storage autoscaling.
- Tune backups (retention per env) and delete stale snapshots.
- Schedule stop/start for all non-prod.
- Buy RIs for steady prod once stable.
- Plan upgrade to MySQL 8+ and enable Optimized Writes/Reads where supported.
- Consider RDS Proxy only if connection storms are the bottleneck.
Need hands-on help? JusDB can audit your fleet, implement the above changes safely, and track savings.
Working with JusDB on RDS Cost Optimization
The savings from RDS cost optimization compound quickly — $10K/month is $120K/year, and most teams get there in 2–4 weeks of focused work. The bottleneck is usually knowing which lever to pull first and how to validate that the change didn't introduce a regression.
We run RDS cost audits as part of our AWS database consulting work. We analyze your current spend, identify the highest-ROI changes, and help you implement them safely without downtime. If you're spending more than $5K/month on RDS MySQL, reach out for a cost review.
Related reading: AWS RDS PostgreSQL Cost Optimization | Amazon EBS gp2 vs gp3 Guide | EC2 Instance Selection for Databases