AlloyDB Cluster
Does ZopNight manage AlloyDB Cluster?
AlloyDB clusters bill through their member instances (vCPUs and memory metered continuously) plus cluster storage that grows with data. ZopNight discovers every cluster via Cloud Asset Inventory, attributes real spend from the BigQuery billing export, and flags idle or oversized clusters through its 128 GCP recommendation rules.
Rules that fire on AlloyDB Cluster
No active rule family targets AlloyDB Cluster today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
AlloyDB is Google Cloud’s fully managed, PostgreSQL-compatible database service built for demanding transactional and analytical workloads. Clusters run continuously and bill for provisioned compute and storage, making forgotten non-production clusters a common source of waste.
A cluster’s bill is the sum of its parts
An AlloyDB cluster is the organizing unit: it owns the storage layer and contains the instances that do the computing. The charges arrive from both directions: each member instance (a primary, plus any read pool instances, tracked separately as alloydb-instance) meters its vCPUs and memory around the clock, while the cluster’s regional storage bills for the data it holds and grows as the database does. Backups add their own storage charge. Nothing about a cluster is usage-priced; a cluster nobody has queried in a month costs what it cost during its busiest week.
Cluster discovery and spend attribution in ZopNight
ZopDev discovers AlloyDB clusters through Cloud Asset Inventory, attributes actual spend from your BigQuery billing export, and flags idle or oversized clusters through its 128 GCP recommendation rules. The cluster is where whole-workload questions get answered, starting with whether this database is still needed at all. Per-node sizing questions belong to the instance rows beneath it.
How AlloyDB estates accumulate dead weight
The service’s positioning invites two expensive habits. Proof-of-concept clusters spun up to evaluate AlloyDB against Cloud SQL, left running after the evaluation ended. And production-shaped non-production: because AlloyDB targets demanding workloads, staging clusters tend to inherit production’s instance sizes and read pools, multiplying an already premium footprint across environments that sleep 16 hours a day.
Retiring a cluster versus shrinking one
A cluster with no remaining purpose should be deleted, which ends instance, storage, and backup meters together. A cluster that is merely oversized is fixed from the inside, by resizing or removing its member instances; the cluster wrapper itself has no capacity dial of its own.
The AlloyDB cluster list in the console
Google Cloud console → AlloyDB for PostgreSQL → Clusters shows every cluster with its region and member instances. Expand one to see exactly which compute nodes are keeping its meter running.