Right-size instances

Match RDS instance classes to actual workload needs so you’re not paying for idle capacity.

Why it matters

RDS instance hours are often the largest component of relational database cost. Many clusters run on instance classes chosen years ago or sized for peak traffic that rarely occurs, so CPU, memory, and I/O sit underutilized most of the time. Rightsizing is about moving to instance families and sizes that reflect your real workload needs rather than historical assumptions.

How to identify rightsizing opportunities

  • Check utilization in CloudWatch

    • Look at CPUUtilization, FreeableMemory (or enhanced metrics), ReadIOPS/WriteIOPS, and database connections over representative periods (normal days, peaks, and batch windows).
    • Instances that sit at low CPU and comfortable memory with modest I/O even during busy periods are good candidates for smaller sizes.
    • Before drawing conclusions, make sure you understand “noisy” periods like burst tests, one-off migrations, or unusually heavy batch windows so you don’t rightsize based on outlier data.

  • Use Performance Insights and slow query data

    • Determine whether performance issues (if any) are due to instance saturation or to query patterns, indexing, or locking. Rightsizing is appropriate when the instance is clearly oversized, not when inefficient SQL is the real problem.

  • Leverage recommendations

    • Tools like AWS Compute Optimizer or your own internal dashboards can highlight underutilized RDS instances and suggest smaller instance classes that would still meet observed demand.1
    • AWS Trusted Advisor’s database checks can also surface low-utilization RDS instances, but the rightsizing recommendations only appear if your organization has Trusted Advisor enabled through a Business or Enterprise Support plan—call this out as a prerequisite when sharing guidance with teams.

Practical approach

  1. Group instances by environment and criticality

    • Start with non-production and lower-risk workloads, then move to production once you are confident in the process.

  2. Propose one-size-down changes

    • For candidates with sustained low utilization, propose moving down one instance size (for example, db.r6g.2xlarge ➝ db.r6g.xlarge) rather than making large jumps in a single step.
    • For very lightly used databases, consider consolidating workloads or using smaller general-purpose families.

  3. Combine with Graviton migration

    • When rightsizing, consider moving to Graviton-based instance families at the same time for additional price-performance benefits. See Switch to Graviton for compatibility and rollout guidance.

  4. Test and roll out during maintenance windows

    • Apply changes in staging first, then during planned maintenance windows in production to minimize impact.
    • Monitor CPU, memory, I/O, and query latency closely after each change; if a smaller size causes sustained stress, revert or step back up.

When not to downsize

Avoid or be extra cautious with downsizing when:

  • You are already close to CPU, memory, or I/O limits during peak periods.
  • Latency-sensitive workloads have very tight performance SLOs and little tolerance for resource contention.
  • You have not yet addressed obvious query and indexing issues; fixing those may change resource needs significantly.

Resources

Footnotes

  1. AWS Compute Optimizer – RDS rightsizing recommendations ↩