AWSCostAWS cost · RDS scheduling
Your dev and staging RDS databases are billing 24/7
A production database has to run around the clock. A dev database does not - and almost always does anyway. It gets created, it works, and it quietly bills 168 hours a week for a workload that touches it maybe 40. Nobody turns it off at night because nobody has to, and it never errors, so it runs for years at full price serving an empty office. The fix is not right-sizing or reserving - it is simply not paying for hours nobody is there for.
A non-production RDS database left on around the clock bills for 168 hours a week when it is used maybe 40. Scheduling it to stop nights and weekends cuts the instance charge 50 to 80%. Storage and backups still bill while stopped, but that is a small fraction - and an automated schedule sidesteps the 7-day auto-restart limit.
How much does an off-hours schedule save?
The instance charge scales with hours running, so cutting the hours cuts the bill almost proportionally:
| Schedule | Hours running | Instance saving |
|---|---|---|
| Always on (no schedule) | 168 hrs/week | baseline |
| 12 hrs/day, weekdays | 60 hrs/week | ~64% less |
| 8 hrs/day, weekdays | 40 hrs/week | ~76% less |
Why do dev databases run all night?
Because stopping one is a manual step nobody owns. There is no failure when a dev database runs overnight - it just costs money quietly - so it never rises to anyone's attention. The default state of a database is “on,” and default states are what survive. Automating the off-hours is the only thing that reliably beats that inertia, because it removes the need for anyone to remember.
How do I schedule stop and start?
The real setup is an EventBridge rule on a cron schedule invoking a small Lambda (or the AWS Instance Scheduler solution) to stop in the evening and start in the morning, weekdays only - tagged so it only touches the databases you choose. The core action it automates is a single command, worth running once by hand to confirm the database is a scheduling candidate:
# stop a non-production database now (instance-hours stop billing)
aws rds stop-db-instance --db-instance-identifier my-dev-db
# start it again
aws rds start-db-instance --db-instance-identifier my-dev-dbScheduling handles the hours. The other two RDS levers are making sure the instance is not oversized and that non-production is not running Multi-AZ it does not need.
Want to know how many of your databases are billing around the clock for an 8-hour workload? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
Do I pay for an RDS database when nobody is using it?+
Yes. RDS bills the instance by the hour for as long as it is running, regardless of whether anyone connects. A dev or staging database left on around the clock bills 168 hours a week even if it is only touched during an 8-hour workday.
How much can I save by scheduling RDS stop/start?+
For non-production databases, typically 50 to 80%. A database used 12 hours a day on weekdays runs about 60 of the week's 168 hours - roughly a 64% cut. At 8 hours on weekdays it is closer to 76%. The instance charge only applies while it runs.
How do I automatically stop and start an RDS instance?+
Schedule it. An EventBridge rule triggers a small Lambda (or the AWS Instance Scheduler solution) to stop the database in the evening and start it in the morning, on weekdays only. You tag which databases to include, set the hours, and it runs without anyone remembering to.
Does stopping an RDS instance stop all charges?+
No - it stops the instance-hour charge, which is the big one, but you still pay for provisioned storage and backups while it is stopped. That is usually a small fraction of the running cost, so scheduling still saves most of the bill. There is also a limit: RDS automatically restarts a stopped instance after 7 days.
Why does RDS restart my stopped database after 7 days?+
AWS caps a manual stop at 7 days so that maintenance and patching can still apply. If you need a database off for longer stretches, an automated schedule handles it - the daily start/stop cycle keeps resetting the clock, so the 7-day limit never bites.
Is it safe to schedule stop/start on production?+
Only if the workload genuinely has no off-hours users - which production rarely does. Scheduling is aimed at dev, staging, QA, and demo databases. For anything customer-facing, right-sizing and reservations are the levers, not switching it off.
Related cost breakdowns
Why Athena is expensive: $5 per TB scanned
Athena charges $5 per terabyte scanned, so an unpartitioned CSV table can cost 10 to 100 times more than the same data as partitioned Parquet. Here is where the scan cost comes from and how to cut it.
Why RDS looks expensive - and how to right-size the instance
A low-traffic MySQL database runs fine on db.t4g.small (~$23/month), not the $100+ tier an AI often quotes. Size RDS to your working set, not your row count.
Multi-AZ is doubling your RDS bill - do you need it?
Multi-AZ runs a standby replica around the clock, so it roughly doubles the instance cost. Essential for production, wasteful for dev and staging. Here is how to tell, and how to fix it.
The RDS costs hiding in storage and backups
RDS storage and backups bill separately from the instance - over-provisioned gp2 disk and backups beyond 100% of your DB size add up quietly. Here is how to find and trim them.