Cloud SQL Instance
Does ZopNight manage Cloud SQL Instance?
Cloud SQL bills per second for vCPUs and memory around the clock, plus provisioned storage that automatically grows and never shrinks. Stopping is not a stop API but a patch of activationPolicy to NEVER, which ZopNight issues on schedule. Storage, backups, and read replicas keep billing while the instance is stopped.
Rules that fire on Cloud SQL Instance
At a glance
| Field | Value |
|---|---|
| Scheduling notes | sets activationPolicy to NEVER to stop the instance (asynchronous long-running operation), restoring ALWAYS on resume |
Cloud SQL provides managed MySQL, PostgreSQL, and SQL Server instances billed for vCPUs, memory, storage, and licensed editions around the clock. Non-production databases left running overnight and on weekends are one of the largest recoverable costs on GCP.
The meters behind a Cloud SQL bill
An instance bills per second for its vCPUs and memory whether or not any query runs, plus a separate meter for provisioned storage. Storage auto-grows by default and can never shrink, so a one-off import that doubles the disk doubles the storage line permanently. High availability runs a standby in a second zone and doubles the compute meter. SQL Server editions add license charges on top. Only the compute portion responds to stopping; everything else continues.
Stopping is an activationPolicy patch
Cloud SQL has no stop API. ZopNight stops an instance by patching its activation policy from ALWAYS to NEVER, an asynchronous long-running operation, so the platform polls the operation until it reports DONE and then confirms the settled instance state before recording success. On resume the policy is restored to ALWAYS. In audit logs this appears as a configuration change rather than a lifecycle event, which is worth knowing if other tooling watches for stop events.
Discovery, backups, and spend attribution
ZopDev discovers instances via Cloud Asset Inventory, tracks utilization, attributes actual spend from the billing export, and schedules instances off during quiet hours. Backup enrichment reads the billable bytes of the most recent successful backup run, so retention recommendations can quantify real storage savings instead of surfacing a zero-dollar advisory.
What a stopped instance still pays for
Provisioned storage bills at its full rate while stopped, and so do retained backups. Read replicas are the bigger surprise: a replica does not stop when its primary does, so stopping a primary without handling its replicas recovers far less than expected.
Finding it in the console
Google Cloud console → SQL lists every instance with its state and tier. A scheduled-off instance shows as Stopped; its storage line survives on the bill regardless.