← Back to RDS Instance Rightsizer
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.
max_connections to the instance memory divided by 9531392, so a smaller class has a lower ceiling.aws rds describe-db-instances.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.
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
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 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.
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.
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.
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.
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.
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.