Explanation
Why the waste happens and who it affects.
However, when older versions such as Aurora MySQL 2 (MySQL 5.7) or Aurora PostgreSQL 11, 12 and 13 move into Extended Support, AWS applies automatic surcharges to ensure continued patching. These charges affect all clusters regardless of usage, creating unnecessary cost exposure across both production and non-production environments. For large Aurora fleets, the incremental expense can become significant if upgrades are not proactively managed.
Billing model
The pricing dimensions that drive this cost.
Aurora Extended Support adds a per-vCPU-hour charge (provisioned instances) or a per-ACU-hour charge (Aurora Serverless) for clusters running a MySQL or PostgreSQL major version past its Aurora end of standard support date, which can be later than the community end of life. Rates vary by Region, and a higher rate applies in year 3 of Extended Support. The surcharge applies in addition to normal Aurora instance costs and is incurred even when clusters are idle.
How to detect
4 checks to find it in your estate.
- Inventory all Aurora clusters and identify the engine type and major version in use
- Compare active versions with AWS lifecycle policies to determine if they are under Extended Support
- Analyze billing data for "RDS Extended Support" charges tied to Aurora clusters
- Review development, staging, or idle Aurora environments for avoidable Extended Support spend
How to fix
4 ways to remove the waste.
- Upgrade Aurora clusters to currently supported major versions to avoid Extended Support charges
- Test upgrades in lower environments to validate application compatibility before production cutovers
- Decommission unused or non-critical Aurora clusters rather than paying ongoing surcharges
- Adopt governance practices that monitor version lifecycle timelines and plan upgrades before end of life
Documentation
Vendor references for pricing and configuration.