Stop and Start RDS DB Instances on a Schedule

Stopping an Amazon RDS DB instance ends the instance-hour charge while keeping the database, its endpoint and its configuration. It is built for development and test databases. This guide covers single RDS instances; Aurora clusters stop at the cluster level and have their own guide, stopping an Aurora DB cluster.

Which instances can be stopped

Stop and start works for Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle and PostgreSQL, on every instance class and in every Region. The exceptions that matter:

• An instance that has a read replica, or that is a read replica, cannot be stopped.
• RDS for SQL Server does not support stopping an instance in a Multi-AZ deployment.
• A stopped instance cannot be modified, and its option group and DB parameter group cannot be deleted while it is stopped.

Check an instance before you schedule it:

aws rds describe-db-instances \
  --db-instance-identifier dev-orders-db \
  --query "DBInstances[].{status:DBInstanceStatus,engine:Engine,multiAz:MultiAZ,replicas:ReadReplicaDBInstanceIdentifiers,source:ReadReplicaSourceDBInstanceIdentifier}"

An empty replicas list and a null source mean replication will not block the stop.

IAM actions

rds:DescribeDBInstances, rds:StopDBInstance and rds:StartDBInstance. The stop and start actions accept the rds:db-tag/${TagKey} condition key, so you can allow them only on instances tagged, for example, stage=dev.

Stop, then start

aws rds stop-db-instance --db-instance-identifier dev-orders-db

Add --db-snapshot-identifier dev-orders-db-pre-stop if you want a snapshot taken as part of the stop. The status moves to stopping and then stopped; the stop can take several minutes and occasionally up to an hour, because RDS shuts down the engine, detaches the EBS storage and terminates the underlying EC2 instance. There is no CLI waiter for the stopped state, so poll:

aws rds describe-db-instances --db-instance-identifier dev-orders-db \
  --query "DBInstances[0].DBInstanceStatus" --output text

Starting runs instance recovery, which AWS says can take from minutes to hours. Start early enough that the database is ready when people arrive:

aws rds start-db-instance --db-instance-identifier dev-orders-db
aws rds wait db-instance-available --db-instance-identifier dev-orders-db

The seven-day limit

If you do not start a stopped instance within seven consecutive days, RDS starts it for you so it does not fall behind on maintenance. A schedule that stops the database every evening absorbs this: the instance never sits stopped long enough to hit the limit. A database you want off for a month needs a stop event that repeats at least weekly, or it will quietly come back and bill instance-hours until someone notices.

What you keep paying for

While stopped you are not charged for DB instance hours. You are still charged for provisioned storage, including Provisioned IOPS, for backup storage (manual snapshots and automated backups inside the retention window) and, if the instance is publicly accessible, for its public IPv4 address. A stopped instance keeps its instance ID, DNS endpoint, parameter group, security group and option group, so applications reconnect to the same hostname after the start. In Multi-AZ deployments the primary and secondary Availability Zones may swap after a start.

Verify the cycle

aws rds describe-events --source-type db-instance \
  --source-identifier dev-orders-db --duration 1440

This lists the last 24 hours of events for the instance, including the stop and start notifications, and is the quickest way to spot an unplanned automatic start.

With ZopNight

RDS is on ZopNight’s start and stop list. A schedule holds cron start and stop expressions in an IANA timezone and can be attached to the database alone or to a resource group, where automatic ordering starts storage, then databases, then compute, then apps (and stops in reverse), with an optional delay per resource. Start and stop need a read and write account connection. See the RDS scheduling page for per-engine notes.