RDS Non-Graviton Instance
What does ZopNight detect here?
Available RDS instances on Intel or AMD classes with MySQL, MariaDB, or PostgreSQL engines have a cheaper Graviton (db.*g) equivalent. ZopNight computes savings as the compute-rate delta, capped at (srcRate − dstRate) × 730 hours since the swap never touches storage. Deltas beyond the 25% plausibility ceiling abstain.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1514 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | rds_graviton.go |
Where it applies
Engines and classes with an ARM equivalent
- resource.Status: available (DBInstanceStatus; default-deny on absent status; the swap only saves money while the DB bills compute)
- resource.InstanceType: a concrete db.* class (Aurora capacity types like aurora-postgresql-provisioned have no instance-level Graviton class → abstain), non-Graviton, with a real ARM equivalent (skuladder.ARMEquivalent ≠ "")
- Metadata string: engine (discoverer Engine field) gates Graviton support (MySQL/MariaDB/PostgreSQL incl. Aurora variants only; SQL Server/Oracle have none; abstain when absent) and selects the engine-suffixed SKU-rate key
- pricing + SKU rates for both the current class and the ARM target (pre-fetched via TargetSKUCandidates)
Capping the ARM discount at the compute line
savings = min((srcRate − dstRate)/srcRate × cost, (srcRate − dstRate) × 730), where srcRate/dstRate are the on-demand hourly rates AWS lists for the current instance class and its ARM (Graviton) equivalent. The min() bound (RULE-REFERENCE audit): cost (pricing[UID]) is the full monthly RDS bill (compute + storage + IOPS + backup) but the Graviton swap cuts only the compute line, so the ratio×cost term is capped by the direct compute rate delta (srcRate − dstRate) × 730, which is never a larger claim than the ratio formula. The aggregator stores RDS rates per-engine, keying MySQL/MariaDB under the bare {instanceType} key and every other supported engine (PostgreSQL, Aurora MySQL, Aurora PostgreSQL) under an engine-suffixed key ({instanceType}-postgres, {instanceType}-aurora-mysql, {instanceType}-aurora-postgres). RC-1514 resolves the engine-suffixed key first (declared via TargetSKUCandidates so the service layer pre-fetches it) and falls back to the bare key when the suffixed rate hasn’t been ingested, so a PostgreSQL/Aurora instance is priced off its own engine’s rate rather than the MySQL-default rate. Abstains when either rate is missing/non-positive, the ARM class isn’t cheaper, or the rate delta exceeds the ~25% plausibility ceiling (gravitonMaxFraction: an implausible delta signals a SKU mismatch/stale ARM rate row; abstain, don’t clamp).
Testing Graviton on a read replica first
- Verify database engine compatibility with Graviton (MySQL 8.0+, PostgreSQL 12+, MariaDB 10.5+ supported)
- Test with a read replica on Graviton first
- Modify instance class to Graviton equivalent during maintenance window
- Monitor performance for 48 hours after migration
No metrics, just SKU rates on both classes
None (gate: RUNNING state + Graviton-compatible engine + non-Graviton class with ARM equivalent; delta from SKU rates, both required); advisory-only (CLAUDE.md #12)