# 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 as a child of its instance through Cloud Asset Inventory and prices each cluster's own `serveNodes` count, so replica spend is visible per zone.

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

ZopNight tracks each cluster via Cloud Asset Inventory as a child of its instance and prices each cluster's nodes on its own. No recommendation rule evaluates per-cluster utilization today, so compare node counts across clusters in the console. 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 each cluster's utilization in Cloud Monitoring.

## 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.