AWS RDS MySQL Cost Optimization - JusDB
AWS RDS MySQL Cost Optimization
By JusDB — practical, battle-tested ways to cut Amazon RDS for MySQL spend without hurting reliability or performance.
TL;DR checklist
- 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
/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)
- 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.