Explanation
Why the waste happens and who it affects.
Google's pricing page states that node charges are for provisioned resources regardless of node usage and apply even if the cluster is inactive, and each hour is billed at the maximum number of nodes that existed during that hour. A cluster with manual node allocation keeps the same node count until someone changes it, so clusters sized for peak load, a migration backfill or a launch event keep paying for that capacity through nights, weekends and quiet periods.
Replication multiplies the effect because every cluster in a replicated instance carries its own nodes. Google recommends enabling autoscaling in most cases and notes that it can help optimize costs because Bigtable reduces the number of nodes whenever possible, which helps avoid over-provisioning. Clusters stay on manual allocation when they predate the decision to autoscale, when teams worry about latency during rebalancing, or when nobody revisits the node count once performance is acceptable.
Billing model
The pricing dimensions that drive this cost.
Bigtable charges are driven by provisioned nodes plus storage and data transfer.
- Provisioned nodes
- Billed per node-hour by edition (Enterprise or Enterprise Plus) for each cluster, at the maximum node count in each hour, with a one-hour minimum per node
- Committed use discounts
- 1-year and 3-year Bigtable CUDs lower the node-hour rate for committed capacity
- Storage
- SSD and HDD storage billed on the average amount of data stored over the month
- Replication
- Free between clusters in the same region; replication between regions is billed per GiB
How to detect
5 checks to find it in your estate.
- List clusters with gcloud bigtable clusters list or in the console and identify those using manual node allocation rather than autoscaling
- For manually allocated clusters, review Average CPU utilization, CPU utilization of hottest node and Storage utilization (bigtable.googleapis.com/cluster/storage_utilization) over at least a month to find sustained headroom well below the targets in Google's capacity planning guidance
- For autoscaled clusters, compare the provisioned node count with the recommended_node_count_for_cpu and recommended_node_count_for_storage metrics; Google advises lowering the minimum if the cluster consistently runs more nodes than recommended
- Check replicated instances for secondary clusters that carry the same node count as the primary while serving little traffic
- Review Bigtable node-hour cost per cluster in the Cloud Billing export to rank clusters by spend
How to fix
5 ways to remove the waste.
- Enable autoscaling on eligible clusters with a CPU utilization target, a minimum and a maximum node count; when converting from manual allocation, set the maximum to at least the highest node count used in the last month
- Respect autoscaling constraints: the minimum cannot be lower than 10% of the maximum and the maximum cannot exceed 10 times the minimum, and with 2x node scaling both must be even
- Lower the minimum node count when recommended node counts stay below the provisioned count, and lower node counts on clusters that must stay manually allocated
- For predictable bursts or sudden batch loads, which autoscaling alone may not handle well because new nodes take time to rebalance, raise the minimum ahead of the scheduled event and lower it afterward
- Review whether every replicated cluster is still needed, and buy Bigtable committed use discounts only for the node baseline that remains after rightsizing
Documentation
Vendor references for pricing and configuration.