AlloyDB Instance
Does ZopNight manage AlloyDB Instance?
An AlloyDB instance, primary or read pool, bills for its vCPUs and memory every hour of the month, around 730 in total, regardless of query volume. ZopNight inventories each instance via Cloud Asset Inventory, tracks Cloud Monitoring utilization over a 42-day lookback, and surfaces rightsizing opportunities in recommendations.
Rules that fire on AlloyDB Instance
No active rule family targets AlloyDB Instance today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
An AlloyDB instance is the compute node (primary or read pool) inside an AlloyDB cluster that actually serves queries. Each instance bills for vCPUs and memory around the clock, so instance count and sizing drive most AlloyDB cost.
The compute node is where AlloyDB money goes
Storage belongs to the cluster; compute belongs here. An instance’s vCPU count and memory configuration meter continuously from creation to deletion. The primary that takes writes and every read pool instance that scales out reads each bill as their own machine. Since read pools exist precisely to add more nodes, the instance layer is where an AlloyDB footprint multiplies: one primary can quietly accumulate a pool of readers, each metering around the clock whether or not the read traffic that justified them still exists.
Per-node utilization over six weeks
ZopDev inventories every instance via Cloud Asset Inventory, tracks utilization with Cloud Monitoring metrics over a 42-day lookback, and surfaces rightsizing opportunities in recommendations. Node-level granularity is the point: a cluster’s average can hide one saturated primary next to three idle readers, and only per-instance history shows which node earns its size.
Sizing drift on primaries and read pools
The waste patterns here are node-shaped. Primaries sized for a migration’s bulk-load phase and never reduced once steady-state traffic proved lighter. Read pool counts tuned for a traffic spike (a product launch, a reporting season) that ended without anyone revisiting the pool. And uniform sizing across environments, where a development instance wears production’s vCPU configuration because the Terraform module had one variable for both.
Adjusting compute without touching the data
Because storage lives at the cluster layer, resizing an instance or trimming a read pool changes compute cost without any data migration. That separation makes AlloyDB rightsizing lower-risk than on architectures where compute and storage move together; the evidence, not the mechanics, is the hard part, and the 42-day history supplies it.
Where instances sit in the AlloyDB console
Google Cloud console → AlloyDB for PostgreSQL → Clusters → select a cluster: the Instances section lists the primary and each read pool instance with its machine configuration, one row per continuously billing node.