Right-Sizing MySQL EC2 with Production Evidence

Running MySQL on EC2 at scale makes overprovisioning deceptively easy. Our horizontally scaled pools had accumulated oversized, fragmented capacity across 231 instances. Standard utilization dashboards showed low CPU, but they did not answer the crucial question: how much production traffic could each database node safely handle?

We answered it with automated capacity tests against live production traffic. A selected replica was removed from normal rotation, its traffic was increased in controlled steps, and saturation was detected through CPU, disk latency, and connection limits. The results exposed a recurring mismatch: our MySQL workloads were often memory-bound while running on CPU-heavy instance profiles. Those measurements let us replace intuition-driven horizontal scaling with evidence-based rightsizing, pool consolidation, and a shift from various configurations toward memory-oriented r8id instances or IO oriented i7ie’s, with guardrails to preserve regional capacity and database SLOs.

In one validated optimization, the fleet fell from 231 to 111 instances—a reduction of 120 instances—while estimated monthly compute cost decreased by approximately 75.4%. The work also established a broader optimization loop: measure workload limits, identify the real bottleneck, test alternative instance families, consolidate low-utilization pools, then optimize commitments only after the fleet is right-sized. We will also discuss where Savings Plans, and capacity-reservation cleanup fit—and why forecast savings must not be confused with realized results.

Attendees will leave with a production-tested method for reducing MySQL EC2 cost without trading away reliability, based on creating a defensible FinOps scorecard that separates validated savings from forecasts and sequences rightsizing before Savings Plans, reservations, or Graviton commitments.