← Back to RDS Instance Rightsizer

How to right-size an RDS instance

An RDS or Aurora instance is billed by the hour for its class whether the database is busy or idle, and the class is usually chosen once, at launch, with a margin nobody revisits. Four CloudWatch metrics are enough to find the instances that are too big, and the ones that are too small.

The four numbers

aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=orders-prod --statistics Average \
  --extended-statistics p95 --period 3600 --start-time ... --end-time ...

Take a window that includes your busiest period. A quiet two weeks will recommend a class that fails at month-end.

Pick the next class in the same family

Within a family (m6g, r6g, t4g) each step doubles vCPU and memory and roughly doubles the price. The analyzer walks down the family and picks the smallest class that keeps p95 CPU under your target (70% by default), keeps the memory reserve, and still allows your connection peak. If CPU is idle but memory is the limit, it says so: a memory-optimised (r) class with the same memory may be the cheaper fit.

node cli.mjs analyze instances.csv --commands

Burstable classes need the average, not the p95

t3 and t4g instances earn CPU credits at a baseline (20% per vCPU-share on medium, 40% on xlarge) and throttle when they run out. An average above the baseline is a credit drain even if the p95 looks fine, so the tool checks the average against the baseline of the class it recommends.

Graviton and Multi-AZ

Graviton classes list a little below x86 at the same size, so an m5 to m6g move saves money before any downsizing. Multi-AZ keeps a standby billed at the same price, which doubles both the cost and the saving. Oracle and SQL Server cannot run on Graviton.

Apply it safely

aws rds modify-db-instance --db-instance-identifier orders-prod --db-instance-class db.r6g.2xlarge

Without --apply-immediately the change waits for the next maintenance window. Either way it restarts the instance: several minutes for single-AZ, a failover of about one to two minutes for Multi-AZ. Rehearse on a snapshot restore, and watch CPU, freeable memory and replica lag for a week.

What this cannot see

A pasted table is not your workload next quarter. Prices are approximate us-east-1 list prices for MySQL/PostgreSQL-style single-AZ instances; reserved instances, storage, provisioned IOPS and licences are not modelled, so the dollar figure is a rough size of the opportunity, not a bill.

Common questions

Is it safe to move an RDS instance to a smaller class?

Often, but only after checking the busiest period. Look at the p95 of CPUUtilization, the minimum of FreeableMemory and the p95 of DatabaseConnections over at least two weeks, and confirm the smaller class keeps CPU under about 70% and a fifth of memory free at that peak. The change restarts the instance, so plan the window.

Does Multi-AZ double the cost?

For RDS MySQL, PostgreSQL, MariaDB, Oracle and SQL Server, yes: the standby is billed at the same instance price, so every class change saves twice as much, and an unnecessary Multi-AZ on a dev database is its own saving. Aurora is different: readers are separate instances you list individually.

Is moving to Graviton worth it?

Usually. The Graviton classes (t4g, m6g, m7g, r6g, r7g) list about 5 to 12% below the equivalent x86 class at the same vCPU and memory. It needs an engine version that supports Graviton and a restart, so test it on a copy; Oracle and SQL Server cannot use it.