# Dev/Test Aurora Off-Hours Scheduling Opportunity

> Flags idle-off-hours dev/test Aurora provisioned clusters and prices a stop schedule from member instance compute only.

Source: https://zop.dev/integrations/aws/recommendations/dev-test-aurora-off-hours-scheduling-opportunity

---

## Stopped Aurora clusters bill storage, not instances

Aurora lets you stop a whole DB cluster in one action. According to the
[stop and start documentation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-cluster-stop-start.html),
while a cluster is stopped you are charged only for cluster storage, manual snapshots and automated
backup storage within the retention window, not for DB instance hours. The same page limits a stop to
seven days, after which Aurora starts the cluster again on its own.

For a development cluster that nobody touches at night or at weekends, the instance hours in those
windows are the recoverable cost.

## Checking your provisioned clusters

```bash
aws rds describe-db-clusters \
  --query 'DBClusters[?EngineMode==`provisioned`].[DBClusterIdentifier,Engine,Status,DBClusterMembers[0].DBInstanceIdentifier]' \
  --output table

aws rds describe-db-instances \
  --query 'DBInstances[?DBClusterIdentifier==`dev-orders`].[DBInstanceIdentifier,DBInstanceClass]'
```

Then compare the members' `DatabaseConnections` and `CPUUtilization` across a week to see the quiet
hours.

## Conditions for a schedule finding

- The cluster status is `available`. A stopped or transitional cluster is skipped because its
  pricing baseline is wrong until it is running again.
- It runs in provisioned mode and is not already Aurora Serverless v2, which scales down on its own.
- Its name matches a dev or test pattern (dev, test, qa, staging, sandbox) and not a production one.
- ZopNight has a measured weekly usage pattern for the cluster with an idle share above zero.
- The cluster's member instances are known and priced.

## When no schedule is suggested

With no measured pattern, no idle time or unpriced members, the rule is silent. It never applies a
standard evening-and-weekend assumption and never shows a $0 recommendation.

## Member compute times the idle share

```text
saving = monthly compute of member DB instances x idle share (capped at 1)
```

Aurora prices a provisioned cluster's storage separately from its instances, and storage keeps billing
while the cluster is stopped, so it is excluded. The cap stops a malformed idle value from claiming
more than the compute that a stop can remove.

## Stopping and starting the cluster on a schedule

1. Review the suggested start, stop and time zone, then apply the schedule from ZopNight so the
   cluster stops and starts automatically.
2. To test manually: `aws rds stop-db-cluster --db-cluster-identifier dev-orders` and
   `aws rds start-db-cluster --db-cluster-identifier dev-orders`.
3. For bursty workloads, consider Aurora Serverless v2 instead. Its
   [capacity range](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html)
   can go down to 0 ACUs on versions that support auto-pause.

**Note**
A stop that lasts longer than seven days ends with Aurora restarting the cluster, so weekday
schedules are fine but a month-long pause is not possible this way.