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 Cloud Monitoring request count and cluster CPU load, and flags instances with zero requests and CPU under 2% across at least 30 days (RC-1244).
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
ZopNight discovers Bigtable instances via Cloud Asset Inventory and reads request count and cluster CPU load from Cloud Monitoring. The idle rule (RC-1244) flags an instance whose requests sit at zero with CPU under 2% across at least 30 days of data, a delete candidate rather than a resize. Node-count rightsizing on an active instance is not a ZopNight finding; the console’s per-cluster CPU view settles that.
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.