Stop instances when not in use

Automate stopping RDS instances outside working hours to avoid paying for idle compute on workloads that don't require 24×7 availability.

Why stop instances when not in use

RDS instances bill by the hour whether they’re used or not. Many workloads—dev, staging, internal tools, reporting databases—don’t need 24×7 availability. Stopping them during off-hours can cut compute.1

Key principle: If it’s not serving requests, don’t pay for compute hours. Not every production workload needs to run around the clock.

As a rough illustration, a workload that only needs to run weekdays 9–5 in one region is active for about one-third of the hours in a week, which translates to roughly 65%–70% fewer compute hours (and corresponding instance cost) once you automate stopping it outside those windows.

What you pay when stopped:

  • Storage and backup charges continue (you still have the data).

Automation options

AWS Instance Scheduler

AWS provides a serverless solution that uses tags, Lambda, and EventBridge to stop and start RDS instances on a customized schedule:

  • Define periods (e.g., “weekdays 8 AM–6 PM”) and apply them via tags.
  • Supports both RDS and EC2, so you can align database and application schedules.
  • Free to deploy; you only pay for Lambda invocations and EventBridge rules (typically pennies per month).

AWS Instance Scheduler documentation

EventBridge + Lambda

For simpler requirements, create your own EventBridge rules that trigger Lambda functions:

  1. Tag instances with Environment: Dev or AutoStop: true.
  2. Create a Lambda function that calls rds:StopDBInstance for tagged instances.
  3. Schedule it with EventBridge cron expressions (e.g., 0 18 * * MON-FRI for 6 PM weekdays).
  4. Add a start rule for mornings (e.g., 0 8 * * MON-FRI).

Identify candidates

Ask these questions to find instances that can safely stop:

  • Is it user-facing 24×7? Customer-facing production databases usually need continuous uptime.
  • Does it process background jobs overnight? Batch systems, ETL pipelines, and scheduled reports may only need to run during specific windows.
  • Is it accessed only during business hours? Internal admin tools, BI dashboards, and regional analytics databases often have predictable usage patterns.

Be especially careful with stateful dependencies such as schedulers, integrations, and batch jobs that assume the database is always up—test your stop/start plan in lower environments to make sure those components either tolerate downtime or are coordinated with the schedule.

Limitations

  • RDS instances can remain stopped for up to 7 days; AWS automatically restarts them after that for maintenance.
  • Aurora Serverless v2 – For Aurora workloads with variable demand, serverless can auto-scale capacity instead of stopping/starting instances.
  • Reserved Instances – Avoid RIs for workloads that stop regularly; they only make sense for 24×7 usage, and you’ll keep paying for the commitment even when the instance is stopped.

Resources

Footnotes

  1. AWS Instance Scheduler on AWS ↩