Explanation
While stopping an RDS instance reduces runtime cost, AWS enforces a 7-day limit on stopped state. 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.
Relevant Billing Model
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.
Detection
- 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
Remediation
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