Spanner Instance
Does ZopNight manage Spanner Instance?
Cloud Spanner bills continuously for provisioned compute (nodes or processing units, where 1,000 processing units equal one node) plus storage. ZopNight discovers Spanner instances via Cloud Asset Inventory, reads request counts from Cloud Monitoring, and flags instances that served no requests as idle (RC-1243) so their capacity can be released.
Rules that fire on Spanner Instance
Cloud Spanner is a globally distributed relational database billed for provisioned compute (nodes or processing units) plus storage, continuously. Its per-node price makes over-provisioned Spanner one of the costliest database mistakes on GCP.
Processing units never sleep
Spanner’s compute meter runs on provisioned capacity, expressed as nodes or as processing units: 1,000 processing units make up one node, and fractional-node instances are provisioned in processing-unit increments. Whatever is provisioned bills every hour, transaction or no transaction. Storage bills separately per GB, and a multi-region configuration prices its compute and storage above single-region because every region holds a replica. The combination of premium per-node rate, continuous metering, and multi-region multipliers is why an oversized Spanner instance outspends most other database mistakes on the platform.
Request counts behind the idle call
ZopNight discovers Spanner instances via Cloud Asset Inventory, reads each instance’s request count from Cloud Monitoring, and flags instances that averaged zero requests as idle (RC-1243). Downsizing a busy instance stays a manual call: Spanner publishes recommended CPU targets for latency-sensitive workloads, so the question to answer is not “is CPU low” but “has six weeks of history stayed far enough below target that capacity can come out without touching tail latency.”
Spanner-shaped overspend
The recurring mistakes: instances created at whole-node sizes when a few hundred processing units would carry the workload, because node granularity was the only option when the runbook was written; multi-region configurations chosen for prestige-grade availability on internal tools; and staging instances mirroring production capacity so that load tests “stay realistic”, running 24x7 for tests that run an hour a week.
Capacity changes are the only dial
There is no stop or pause for Spanner; provisioned capacity bills until it is reduced or the instance is deleted. Processing units can be resized without downtime, which makes rightsizing a low-drama change once the utilization evidence is in hand. Databases inside the instance are tracked separately as spanner-db for attribution.
Checking instances in the Spanner console
Google Cloud console → Spanner lists each instance with its configuration (regional or multi-region) and its provisioned compute, the two facts that set the floor of the bill.