Bigtable Instance
Does ZopNight manage Bigtable Instance?
Cloud Bigtable bills for provisioned nodes 24x7 plus SSD or HDD storage, and every replicated cluster brings its own node count. ZopNight inventories instances via Cloud Asset Inventory, reads 42 days of Cloud Monitoring node utilization, and flags over-provisioned node counts, the dominant lever on a Bigtable bill.
Rules that fire on Bigtable Instance
Cloud Bigtable is a low-latency, wide-column NoSQL database for time-series and high-throughput workloads. Instances bill for provisioned nodes, SSD or HDD storage, and replication, running 24x7 regardless of traffic.
Three meters: nodes, stored bytes, and replication
Node-hours dominate a Bigtable invoice. Every node in every cluster of the instance bills continuously at its hourly rate, independent of query volume: a quiet weekend costs the same as a peak Monday. Storage is a second, smaller meter, charged per GB with SSD priced above HDD. Replication is the third: adding a cluster in another zone or region duplicates both the node fleet and the stored data, and cross-cluster replication traffic rides on top. An instance is the billing umbrella; the clusters underneath it (tracked separately as bigtable-cluster) hold the actual nodes.
The instance-level view ZopNight builds
ZopDev discovers Bigtable instances via Cloud Asset Inventory, monitors node utilization with 42-day Cloud Monitoring history, and flags over-provisioned node counts in recommendations. Six weeks of utilization is enough to distinguish a fleet riding near its CPU targets from one that was sized for throughput that never arrived.
How Bigtable budgets get away from teams
Over-provisioned node counts are the classic leak: Bigtable performs best with headroom, and teams add nodes during an incident, then never walk them back. Replication for durability on non-critical data doubles spend silently. And HDD-appropriate archival workloads sometimes land on SSD because the default felt safer, paying the premium storage rate on terabytes that are read once a quarter.
Why there is no off switch here
Bigtable offers no stop operation. An instance either has nodes or it does not exist. Cost recovery therefore runs through rightsizing (fewer nodes, autoscaling where the workload allows), storage-class review, and deleting instances whose pipelines have been decommissioned. ZopNight’s role is producing the utilization evidence that makes those changes defensible.
Reading a Bigtable estate in the console
Google Cloud console → Bigtable → Instances lists every instance; opening one shows its clusters with per-cluster node counts and storage type, the two figures that decide nearly the entire charge.