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 and collects 42 days of CPU, memory and connection metrics from Cloud Monitoring.
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
ZopNight inventories every instance via Cloud Asset Inventory and collects CPU, memory, and connection metrics from Cloud Monitoring over a 42-day lookback; no rule turns them into a rightsizing recommendation yet. 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 metric history is where to look for 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.