Why this matters
You can now see which of your Multi-Region Cloud Storage buckets have cross-location read charges worth acting on, and start with the ones where a cache would save the most. It runs automatically for every organization with GCP Cloud Storage, so there’s nothing to set up.
Google bills network data transfer when a Google Cloud service in one location pulls data from a Multi-Region bucket in another. Other Google Cloud services have incurred the charge since Google’s 2022 to 2023 pricing changes, and BigQuery jobs since February 1, 2026, so it can show up on your bill with no change to the bucket.
When a query engine scans the same objects again and again, each scan is billed, so a bucket with a modest amount of data can have transfer charges far larger than its storage charge. The storage line stays small while the transfer charge grows with every scan.
Your Google bill lists the charge but doesn’t say which service made the requests or from which zone, and you need both to choose the fix. When finance asks why Cloud Storage cost went up when stored data barely moved, you can point to specific buckets and the cross-location charges behind the increase. When an engineering lead asks whether the fix means changing applications, a cache doesn’t need any.
Choosing buckets by hand can go wrong in two ways. A bucket with a small storage line can get skipped even though its transfer charges are the largest part of its cost. A bucket that’s scanned once from end to end each month can show high transfer charges and still never recover the cost of a cache. The hit-rate check in the steps covers that second case.
What we built
A new GCP recommendation, Reduce Cross-Location Read Costs, flags a bucket when, over the last 30 days, its cross-location charges are more than 10% of its total cost and at least $100. Those charges include network data transfer, Class B (read) operation fees, and retrieval fees.
Buckets that already have a cache are left out. Multi-region replication and internet egress charges are also left out, since a cache doesn’t change them.
Each bucket gets its own recommendation with an estimated 30-day saving. The estimate assumes 70% of requests are served from the cache and subtracts the cache’s own storage and ingest charges. The recommendation lists the four assumptions behind the estimate, so you can compare them with your own workload.
The recommendation points to two fixes. You can enable Rapid Cache (formerly Anywhere Cache) in the zone the traffic comes from, which works on an existing bucket with no change to applications or APIs. If the traffic comes from one region and you don’t need cross-region redundancy, you can relocate the bucket, which removes the cross-location transfer charge at its source.
How it works
To find the recommendation, go to Optimize, open the Recommendations tab, and use Add Filter to set Cloud Provider to GCP and Service to Cloud Storage. Sort by Potential Savings to see the largest first.
Open a recommendation and the Overview tab lists the steps. They start with finding the service that accesses the bucket, using Cloud Storage data access logs (off by default, so you may need to turn them on), then cover choosing the zone, creating the cache, and tracking its hit rate. If the cache costs more than it saves, disable it.
You can disable this recommendation type for your organization on the Catalog tab.
