Explanation
Why the waste happens and who it affects.
After this period, the instance is automatically restarted and resumes incurring compute charges - even if the database is still not needed. This creates waste in cases where teams intended to pause the environment but failed to manage its lifecycle beyond the 7-day window. Without proper automation or teardown workflows, stopped RDS instances silently become active and billable again. The best practice for long-term inactivity is to snapshot the database and delete the instance entirely. If the instance must remain available for fast recovery, automation should be in place to re-stop it upon restart.
Billing model
The pricing dimensions that drive this cost.
RDS instances are billed based on:
- Instance runtime (per hour)
- Charged only while running
- Provisioned storage and snapshots
- Billed independently of instance state
When an instance is restarted after 7 days without being actively used, runtime charges resume.
How to detect
4 checks to find it in your estate.
- Identify RDS instances that were restarted automatically after reaching the 7-day stop limit
- Check for repeated stop/restart patterns without sustained usage
- Review tags or naming patterns indicating temporary or paused projects
- Engage with workload owners to determine whether reactivation was intentional or overlooked
How to fix
5 ways to remove the waste.
For projects on hold or long-term inactive environments:
- Take a snapshot and delete the RDS instance to avoid all runtime charges
- Restore from snapshot only when the environment is needed again
If the instance must remain stopped for quick recovery:
- Tag eligible instances and implement automation (e.g., AWS Step Functions or Lambda) to monitor for automatic restarts and re-stop them as needed
- Ensure teams are aware of the 7-day stop limit and its cost implications
- Consider integrating this logic into existing environment lifecycle tooling
Documentation
Vendor references for pricing and configuration.