Explanation
Why the waste happens and who it affects.
These newer families deliver improved performance per vCPU and lower hourly costs, yet are often not adopted due to legacy defaults, inertia, or lack of awareness.When workloads are not tightly bound to architecture-specific extensions (e.g., x86-specific binaries or drivers), switching to Graviton typically requires no application changes and results in immediate savings. Persisting with x86 in eligible use cases results in avoidable overpayment for compute.
Billing model
The pricing dimensions that drive this cost.
RDS is billed per second, with a 10-minute minimum after a billable status change, based on:
- Instance family and size
- Storage and backup usage
Graviton-based instances offer 20-40% better price-performance and can lower compute costs significantly for compatible workloads.
How to detect
4 checks to find it in your estate.
- List all active RDS for MySQL, MariaDB, and PostgreSQL instances and identify those using x86-based families (db.m5, db.r5, etc.) - RDS for SQL Server, Oracle, and Db2 do not support Graviton instance classes
- Cross-reference instance types with available Graviton equivalents for the same engine
- Use Compute Optimizer (where available) or performance data to validate compatibility
- Identify workloads with steady, general-purpose usage patterns that would benefit from Graviton
How to fix
4 ways to remove the waste.
- Evaluate performance requirements and test Graviton-backed RDS instances in staging
- Modify instance class to a db.*g Graviton-based equivalent (e.g., db.r6g.large)
- Update infrastructure templates (e.g., Terraform, CloudFormation) to default to Graviton where applicable
- Revisit instance family selections during each modernization, upgrade, or cost review cycle
Documentation
Vendor references for pricing and configuration.