Amazon RDS / Aurora Cluster
Does ZopNight manage Amazon RDS / Aurora Cluster?
An Aurora cluster bills per instance-hour for every member instance plus per GB-month for shared cluster storage and per million I/O requests on the standard configuration. ZopNight stops whole non-production clusters via rds:StopDBCluster on schedule. AWS restarts a stopped cluster after 7 days, which a nightly schedule never hits.
Rules that fire on Amazon RDS / Aurora Cluster
At a glance
| Field | Value |
|---|---|
| Stop verb | rds:StopDBCluster |
| Scheduling notes | cluster stopped via rds:StopDBCluster and started via rds:StartDBCluster on schedule. |
An RDS cluster groups Aurora or Multi-AZ database instances behind shared cluster storage. All member instances bill continuously, so pausing dev and staging clusters outside working hours removes the full compute charge for those windows.
Instance-hours, shared storage, and I/O
An Aurora cluster bills per instance-hour for every member (the writer and each reader) at the rate of its instance class. Cluster storage is a separate meter, billed per GB-month for what the shared volume actually holds, and standard-configuration clusters add a per-million-I/O-requests charge; the I/O-Optimized configuration trades that away for higher instance and storage rates. Three readers on a dev cluster means four instance meters running against one workload.
One verb stops the whole cluster
rds:StopDBCluster halts every member instance’s compute meter at once, and rds:StartDBCluster brings the cluster back; ZopNight drives this pair on schedule. Storage keeps billing while stopped, and AWS restarts any cluster stopped for 7 consecutive days, the same rule that governs standalone RDS instances, so a recurring nightly schedule never encounters the limit, while a one-off manual stop silently comes back a week later.
Cluster-shaped overspend
Reader counts copied from production into non-production clusters that serve no read traffic. Dev and test Aurora on fixed provisioned instances where Serverless v2 would track their bursty usage down to a fraction of the capacity. And idle clusters holding zero connections for weeks, every member still billing hourly.
What gets watched
Clusters are discovered on the 6-hour cycle, with hourly CloudWatch metrics kept over a 90-day lookback and per-cluster cost from Cost Explorer or CUR 2.0. Recommendations cover off-hours scheduling, instance rightsizing, and Serverless v2 candidates.
Cluster topology in the console
RDS console, then Databases. A cluster renders as a parent row with its writer and reader instances nested beneath it. The member list is the meter list: each nested row is an instance-hour charge of its own.