How to reduce data transfer costs on Google Cloud

Why this matters

Google Cloud does not charge you for data coming in. It charges for data going out: across a zone boundary, across a region, or out to the internet. Those charges arrive as many small line items spread across Compute Engine, Cloud Storage, BigQuery and Cloud Run, so nobody ever sees them as one number.

The usual culprits are boring. A GKE cluster with pods spread over three zones. A dashboard that joins a BigQuery table in one region with a dataset in another. Nightly snapshot copies to a backup region nobody tests. Log sinks that ship everything to a central project. Each one looks small on its own.

Transfer cost follows architecture, so you cannot fix it with one toggle. You fix it by moving work next to the data, keeping chatty services in the same zone, and caching what goes out to users. Latency usually improves along the way, which is the part your users notice.

Before you start

Turn on Cloud Billing export to BigQuery before you change anything. Choose the detailed usage cost export, not the standard one. It gives you the cost, usage and SKU description fields you need to find egress lines by service and region.

Make a simple inventory: projects, regions, zones, VPC networks, and the main service-to-service calls. Ask each team which systems talk to which. Most cross-zone traffic comes from pairs that nobody wrote down.

Sort out permissions early: Billing Account Viewer on the billing account, BigQuery Data Viewer on the export dataset, and Compute Network Viewer on the projects. If you plan to use VPC Flow Logs, know that they are billed and sampled. Run them for a day on one busy subnet, not everywhere.

How to do it

Start from the bill, not the architecture diagram. Rank the SKUs by cost, then find the code or config that creates each one. A SKU description containing Network Egress plus a region tells you more than a total ever will.

Fix the structural items first: where compute sits, which network tier you use, and whether calls to Google APIs leave through the internet. Then tune routing and caching. Change one thing at a time and re-measure, otherwise you cannot tell what worked.

1. Rank egress lines in BigQuery. Filter the detailed usage cost table for sku.description values containing Egress or Network. Group by project, region and SKU, then sort by cost. The top ten lines make your work list.
2. Map workloads to zones. List each service with its region and zone, and what it calls. Any pair crossing a zone boundary is a candidate. Move chatty pairs into the same zone where the SLA allows.
3. Try the Standard network tier. Premium tier routes traffic on Google's global network and costs more for internet egress. Standard tier is cheaper for many paths. Test it on one service and measure latency before rolling it out.
4. Keep Google API calls private. Enable Private Google Access on subnets and use internal IPs for Cloud SQL, Memorystore and internal load balancers. Traffic to Google APIs then stays on Google's network. Drop external IPs where a load balancer or Cloud NAT covers the need.
5. Tune GKE routing. Turn on topology aware routing so Service traffic stays in the same zone when capacity allows. Use internalTrafficPolicy set to Local for node-local workloads. Check for hot spots where one zone holds more pods than the others.
6. Cache at the edge. Put Cloud CDN in front of cacheable responses and set Cache-Control headers, with versioned URLs for releases. Track the cache hit ratio every week. Each hit that never reaches your origin is egress you did not pay for.
7. Colocate data and compute. Keep BigQuery datasets and Cloud Storage buckets in the same region as the jobs and VMs that read them. Avoid cross-region joins in scheduled queries. Set Requestor pays on buckets you share outside the company.
8. Trim replication. Cross-region snapshot copies and dual-region buckets suit a small set of data. For the rest, ask whether a second copy earns its cost. Shorten retention where you can.
9. Alert and review monthly. Label resources by team and set budget alerts on the egress SKUs. Send the top lines to their owners each month. Leaks come back after a few releases.

How to check it worked

Compare the same SKUs month over month in BigQuery, not the total bill. Look at bytes and cost separately. A drop in bytes with a flat cost often means the traffic moved to a more expensive destination.

Check latency and error rates after each change. A cheaper path that raises p95 latency or triggers retries will cost you more in the end. Keep a small dashboard with the cache hit ratio, cross-zone bytes, and your top five egress SKUs.

Run VPC Flow Logs for a day on one subnet to confirm the top talkers are what you expect, then turn them off. Also check that budget alerts fire at the thresholds you set, not just on the total.

Mistakes to avoid

Removing external IPs without a NAT or proxy breaks package updates and third-party API calls. Cloud NAT has its own per-GB charge, so compare it with the egress it replaces. Do that math for your own traffic profile, not in the abstract.

Assuming the Standard tier is always cheaper. It is cheaper for many internet paths, but it changes the route your traffic takes. Test latency from the regions where your users sit, and keep Premium where it earns its place.

Leaving VPC Flow Logs at full sampling to hunt for traffic. The logs can cost more than the traffic you find. Cloud NAT, Private Service Connect endpoints and Interconnect attachments carry their own hourly and per-GB charges, so put them in the same comparison.

Trying to do all of it in-house with no spare bandwidth. If the bill is large and nobody has time to chase it, an outside review can help. Cloudverg's Cloud cost audit is a two-week read-only review at $4,500/month, and it includes a data transfer and egress review. Weigh it against the savings you expect to find.

Frequently asked questions