# 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, watches CPU utilization across a 42-day lookback, and recommends processing-unit reductions where utilization shows capacity is safe to release.

Source: https://zop.dev/integrations/gcp/spanner
Updated: 2026-08-19

---

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.

## The CPU history behind a downsizing call

ZopDev discovers Spanner instances via Cloud Asset Inventory, monitors CPU utilization over the 42-day lookback, and recommends processing-unit reductions where safe. Spanner publishes recommended CPU targets for latency-sensitive workloads, so the question a recommendation answers 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.