# Bigtable Cluster

> A Bigtable cluster is the per-zone set of nodes serving an instance, and every additional replica cluster bills its own full node count and storage. ZopNight tracks each cluster through Cloud Asset Inventory and evaluates per-cluster node utilization against its GCP recommendation rules for safe downsizing.

Source: https://zop.dev/integrations/gcp/bigtable-cluster
Updated: 2026-08-19

---

A Bigtable cluster is the set of nodes in a single zone that serves a Bigtable instance, with each additional replica cluster multiplying node and storage cost. Cluster node counts are the primary lever for Bigtable spend.

## Where the nodes actually live and bill

The instance is an umbrella; the cluster is the hardware. Each cluster occupies one zone and runs its own node fleet, and those node-hours, plus the cluster's copy of the data, are what the meter records. An instance with a single cluster pays once. Add a second cluster for replication and the node fleet, the storage, and the replication traffic all appear again on the bill. Because clusters are sized independently, a replica can quietly carry more nodes than the primary it mirrors.

## Per-cluster evidence, not instance averages

ZopDev tracks each cluster via Cloud Asset Inventory and evaluates per-cluster node utilization against its GCP recommendation rules for downsizing. The per-cluster granularity matters: an instance-level average can look healthy while one zone's fleet idles. A serving cluster at high utilization and a replica at near zero average out to a number that flags nothing.

## Replica topologies that quietly double spend

Common patterns: a second cluster added for a migration or failover test and never removed once the exercise ended; replicas placed in a distant region for latency experiments that concluded months ago; and symmetric sizing habits, scaling every cluster whenever the busiest one needs nodes, so one hot zone drags the whole topology's cost upward.

## Shrinking a cluster without breaking the instance

Node counts on a cluster can be lowered live, and removing a replica cluster is an instance-topology change rather than downtime for the primary zone. Neither is a scheduled operation (there is nothing to stop overnight), so the savings path is deliberate resizing backed by the utilization history ZopNight assembles.

## Cluster inventory under each instance

Google Cloud console → Bigtable → Instances → select an instance: the Clusters panel lists every zone, its node count, and its storage type. Effectively, that is one row per line item.