Scheduling Amazon RDS Instance
rds:StopDBInstanceCan ZopNight schedule Amazon RDS Instance?
AWS restarts a stopped RDS instance automatically after 7 days. A recurring schedule keeps it off in practice because each stop restarts that clock, but an instance stopped once and forgotten comes back on its own and bills until somebody notices.
How the stop works
| Field | Value |
|---|---|
| Behaviour | instance stopped via rds:StopDBInstance and started via rds:StartDBInstance on schedule. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
The 7-day rule is the thing to understand
RDS does not let you stop an instance indefinitely. After 7 days AWS starts it again, whether or not you want it running. This exists so that pending maintenance and patches can be applied.
A recurring schedule works fine, because each nightly stop resets the counter. The problem case is a one-off stop: an instance shut down “for now” during a project pause reappears a week later and runs until the next invoice makes it visible.
What keeps billing while stopped
Storage, at the full provisioned rate. Automated backups and manual snapshots too. A stopped
db.r6g.xlarge with 1 TB of gp3 saves the instance hours and keeps paying for the terabyte.
Multi-AZ is worth checking before scheduling: you are paying for a standby that is also stopped, so the saving is proportionally larger, but so is the restart time.
Read replicas do not stop with the primary
A replica keeps running when its primary stops, and keeps billing. Stopping a primary while its replica runs saves less than half of what it looks like it should, and leaves a replica replicating from nothing.
Schedule the replicas too, or accept the reduced saving knowingly.
Aurora is different
Aurora clusters stop as a cluster rather than per instance, and Aurora Serverless v2 scales to a minimum ACU rather than to zero, so “stopped” still bills something. For genuinely intermittent Aurora workloads, a low Serverless minimum usually beats a schedule.
Start time is not instant
An RDS instance takes several minutes to become available. A schedule starting at 08:00 means the database is ready some minutes after that, so set the start earlier than the first person needs it rather than at the moment they arrive.