RDS MySQL, MariaDB and PostgreSQL instances on x86 classes that have a same-size Graviton class
What does ZopNight detect here?
ZopNight maps x86 RDS classes such as `db.m5`, `db.r5`, `db.m6i`, `db.r6i` and `db.t3` to their Graviton siblings `db.m6g`, `db.r6g`, `db.m7g`, `db.r7g` and `db.t4g` for MySQL, MariaDB and PostgreSQL, including Aurora variants. A finding shows the compute rate difference, and ZopNight rejects rate gaps above 25% as likely price-data errors.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1514 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | x86 class with a same-size Graviton class on a supported engine |
| Source | ZopNight |
| Permissions used | rds:DescribeDBInstances · rds:DescribeOrderableDBInstanceOptions |
Where it applies
Same size, ARM processor, lower hourly rate
AWS publishes Graviton-based DB instance classes alongside the Intel and AMD ones. Graviton classes such as db.m6g, db.r6g, db.m7g and db.t4g have the same size names as their x86 siblings, and the move is an ordinary instance modification. The engine support table shows which engines can use them: MariaDB, MySQL 8.0 and 8.4 and PostgreSQL are supported on db.m6g and db.t4g, while RDS for SQL Server, Oracle and Db2 show “No” for those classes.
Checking an instance’s Graviton options
aws rds describe-db-instances \ --query 'DBInstances[].[DBInstanceIdentifier,Engine,EngineVersion,DBInstanceClass]' \ --output table
aws rds describe-orderable-db-instance-options --engine postgres \ --engine-version 16.4 --db-instance-class db.r6g.large \ --query 'OrderableDBInstanceOptions[].[DBInstanceClass,AvailabilityZones[0].Name]'An empty result from the second command means that class is not offered for that engine version in the Region.
What the rule requires
- The instance status is
available. An instance in any other or unknown state is skipped, since the swap only saves money while compute is billing. - The class is a concrete
db.*class. Aurora capacity types with no instance class are skipped. - The engine is MySQL, MariaDB or PostgreSQL, including Aurora MySQL and Aurora PostgreSQL.
- The class has a mapped Graviton sibling: db.m5 to db.m6g, db.r5 to db.r6g, db.m6i to db.m7g, db.r6i to db.r7g, or db.t3 to db.t4g, keeping the same size.
- ZopNight has hourly rates for both classes, looked up for the instance’s own engine where available.
When no Graviton finding appears
Instances already on Graviton, engines without Graviton classes and classes outside the map produce nothing. So does a pair of rates where the ARM class is not cheaper. If the price difference is larger than 25% of the current rate, ZopNight treats it as a mismatched or stale price row and stays silent instead of clamping the number.
The compute delta, bounded
saving = min( (current rate - Graviton rate) / current rate x monthly cost, (current rate - Graviton rate) x 730 )The monthly cost includes storage, IOPS and backup, which the class change does not touch, so the second term caps the claim at the pure compute difference.
Migrating to Graviton safely
- Confirm the engine version appears for the target class in the support table; upgrade the engine first if not.
- Create a read replica on the Graviton class and run your test suite or a replay against it.
- Modify the primary during a maintenance window:
aws rds modify-db-instance --db-instance-identifier orders-db --db-instance-class db.r6g.large - Compare CPU and query latency for 48 hours before moving other instances.