Explanation
Why the waste happens and who it affects.
Dual-region and multi-region buckets store a geo-redundant copy of every object, and Google bills for that redundancy through a higher storage rate, inter-region replication charges on every write, and higher Class A operation rates. When a bucket holds data that is re-creatable, short-lived, or read only by compute in one region, that premium buys little.
The pattern is common because the location is chosen once, at bucket creation, and is often picked from a console default, a Terraform module, or a habit of using US or EU for everything. Build artifacts, pipeline staging and intermediate output, caches, log exports and scratch datasets end up geo-replicated even though losing a region would only mean regenerating them. Multi-region buckets add a second cost for regional compute: a region is not treated as the same location as a multi-region, so reads from VMs or GKE clusters in a single region are charged for data transfer.
Billing model
The pricing dimensions that drive this cost.
Cloud Storage charges for storage, data processing and network usage, and the location type affects all three.
- Storage by location type
- Region has the lowest per-GiB storage price, multi-region is higher, and dual-region is highest because it is billed to both underlying regions
- Inter-region replication
- Billed per GiB for all data written to dual-region and multi-region buckets, including puts, rewrites and copies, and higher again with turbo replication
- Operation charges
- Class A operations on Standard storage cost twice as much per 1,000 in dual-region and multi-region buckets as in a single region
- Multi-region read transfer
- Reading from a multi-region bucket always incurs data transfer charges, because a region is not treated as the same location as a multi-region even when it lies inside it
How to detect
5 checks to find it in your estate.
- List buckets and their locationType (region, dual-region or multi-region) with the Cloud Storage JSON API or gcloud, and rank the dual-region and multi-region ones by stored bytes
- In the Cloud Billing report or billing export, filter to Cloud Storage and group by SKU to see how much is spent on dual-region and multi-region storage, inter-region replication and data transfer from multi-region buckets
- For each large geo-redundant bucket, identify where readers and writers run; buckets accessed only by workloads in one region are candidates
- Flag buckets whose contents are re-creatable or short-lived, such as build artifacts, caches, staging and intermediate pipeline output, or temporary exports
- Check the rpo field for ASYNC_TURBO on dual-region buckets that have no documented recovery point objective requiring turbo replication
How to fix
5 ways to remove the waste.
- For re-creatable, short-lived or single-region data, move it to a regional bucket in the same region as the compute that uses it; Google's own guidance is to store short-lived datasets in regions to avoid replication charges
- Use bucket relocation to move an existing bucket to a region without changing its name; it requires Storage Intelligence and charges per GB moved, plus data transfer, operations and temporary double storage during the move
- Alternatively create a new regional bucket and copy data with Storage Transfer Service, then repoint applications; this changes the bucket name and incurs normal copy, operation and transfer charges
- Set turbo replication back to default where the 15-minute RPO is not a real requirement
- Keep dual-region or multi-region only where a documented availability or disaster recovery requirement justifies it, and record that requirement so the choice is reviewed rather than inherited
Documentation
Vendor references for pricing and configuration.