AWS RDS MySQL Cost Optimization

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.

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 to m/r for 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)

1. Measure a week: CPU, memory, read/write IOPS, throughput, connections, slow queries.
2. Right-size on Graviton; switch storage to gp3; enable storage autoscaling.
3. Tune backups (retention per env) and delete stale snapshots.
4. Schedule stop/start for all non-prod.
5. Buy RIs for steady prod once stable.
6. Plan upgrade to MySQL 8+ and enable Optimized Writes/Reads where supported.
7. 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