GCP Network Egress Costs Explained: Free Traffic & Cost Traps
Network egress is the data that leaves a boundary in GCP: a zone, a region, or Google’s network entirely. Ingress (data coming in) is free. Egress (data going out) is where the charges live. This page explains which traffic patterns cost money, which are free, and how to structure your architecture so you do not get a surprise bill.
The three biggest cost traps are: internet egress at scale (roughly $0.08-0.12 per GB depending on region), inter-region transfers between your own services, and the quiet $0.01/GB cross-zone charge on VM-to-VM traffic that looks harmless until you check the volume. Most teams hit at least one of these before they learn to check for it. For full context on how egress fits into the broader GCP pricing model, start there first if you are new to GCP billing.
All dollar figures on this page are approximate and illustrative. Exact rates vary by source region, destination, network tier, and volume. Always verify against official Google Cloud pricing before making budget decisions.
Fast answer
- All ingress into GCP: free
- Same-zone traffic on internal IPs: free
- Same-region managed-service traffic on internal IPs: free (most services)
- Cross-zone VM-to-VM traffic: ~$0.01/GB each direction
- Inter-region traffic: ~$0.01-0.08/GB depending on the region pair
- Internet egress (Americas/Europe): ~$0.08-0.12/GB, volume discounts at higher tiers
- Internet egress (Asia-Pacific): ~$0.12/GB, higher than other regions
- CDN-served traffic: lower per-GB rate than standard internet egress
Co-locate services that talk to each other in the same region and zone, and use internal IP addresses for all service-to-service communication. This single practice eliminates cross-zone, inter-region, and external-IP charges in one move.
Network egress, simply explained
Think of GCP like a large warehouse complex. Moving boxes between shelves in the same room (same zone) costs nothing. Moving boxes between rooms in the same building (same region, internal IPs) is also free for most purposes. But the moment a box leaves the building, whether to another building across town (another region) or to a customer’s address (the internet), you pay a shipping fee per kilogram. The further it goes, the more it costs.
Here are the terms that matter:
- Egress: data leaving a boundary (zone, region, or Google’s network)
- Ingress: data arriving. Always free in GCP
- Internal IP: a private address (e.g. 10.x.x.x) that keeps traffic on Google’s internal network
- External IP: a public address that routes through the internet, even for same-region traffic
- Same-zone: two resources in the exact same availability zone (e.g. both in us-central1-a)
- Cross-zone: two resources in different zones within the same region (e.g. us-central1-a to us-central1-b)
- Inter-region: traffic between different GCP regions (e.g. us-central1 to europe-west1)
How GCP egress charges work
Whether you pay, and how much, depends on four factors:
- Where the data starts. Which region and zone the source resource lives in
- Where it is going. Same zone, different zone, different region, or the internet
- Which IP path it takes. Internal (private) IPs stay on Google’s backbone. External (public) IPs route through the internet even when both endpoints are in GCP
- Whether traffic leaves Google’s network. Internet egress is the most expensive tier
Every time data crosses a boundary (zone, region, or Google’s network edge), a charge appears. Zero crossings means free. One crossing is cheap. Two or more crossings stack up. Design your architecture to minimise the number of boundaries your data has to cross.
Volume also matters. Internet egress has tiered pricing where the per-GB rate drops at higher monthly volumes (e.g. above 1 TB, 10 TB). But even with volume discounts, egress at scale is a significant budget item. If you need a refresher on how GCP structures its pricing tiers, see GCP pricing models.
Quick comparison: traffic patterns and costs
| Traffic pattern | Example | Usually free? | Cost behaviour | What to check |
|---|---|---|---|---|
| Ingress to GCP | User uploads a file to Cloud Storage | Yes | Always free | Nothing. Ingress is never charged |
| Same-zone internal | VM in us-central1-a reads from Cloud SQL in us-central1-a via internal IP | Yes | Free | Confirm both resources are in the same zone and using internal IPs |
| Same-region internal | Cloud Run service calls a Cloud Storage bucket in the same region | Yes (most services) | Free for managed-service traffic on internal IPs | Confirm same region; use internal IPs or private connectivity |
| Cross-zone VM-to-VM | App in us-central1-a queries database in us-central1-b | No | ~$0.01/GB each direction | Zone placement of VMs; volume of internal data transfer |
| Inter-region | VM in us-central1 reads from Cloud Storage in europe-west1 | No | ~$0.01-0.08/GB depending on region pair | Region alignment of all communicating resources |
| Internet egress | API server responds to a user’s browser | No | ~$0.08-0.12/GB; tiered volume discounts | Monthly volume; source region; Premium vs Standard network tier |
| CDN-served traffic | Static asset served from Cloud CDN edge cache | No, but cheaper | Lower per-GB rate than standard internet egress | Cache hit ratio; whether content is cacheable |
When you pay vs when you do not
Free paths
- All ingress from the internet into GCP
- Traffic between services in the same zone on internal IPs
- Same-region traffic on internal IPs for most managed services (Cloud Run to Cloud Storage, App Engine to Cloud SQL, etc.)
- Traffic to Google API endpoints (googleapis.com) from within GCP
- Traffic to most Google services (BigQuery, Pub/Sub) within the same region
- Internet egress. Any response sent to a user, webhook, or external API outside Google’s network
- Inter-region egress. Traffic between different GCP regions, even if both are your own services
- Cross-zone VM-to-VM. Traffic between VMs in different zones of the same region (~$0.01/GB)
- External IP routing. Two services in the same region communicating via public IPs instead of internal IPs may incur charges because traffic exits Google’s internal network
- Cloud Interconnect / VPN egress. Data sent from GCP to on-premises via Interconnect or VPN has its own rate schedule
The pattern: if traffic stays inside one zone on private addresses, it is free. Every boundary crossing (zone, region, or network edge) adds cost.
How to estimate your egress bill
Monthly egress cost = data volume (GB) x per-GB rate for that traffic type
Add up each traffic type separately. Internet egress, inter-region, and cross-zone each have different rates. For a complete cost estimate that includes egress alongside compute and storage, see the estimating cloud costs guide.
Example 1: cross-zone app + database traffic
A web application in us-central1-a queries a Cloud SQL instance in us-central1-b. The app sends 500 MB of queries and receives 2 GB of results per day.
- Daily cross-zone egress: 2.5 GB x 2 directions = ~5 GB charged
- Rate: ~$0.01/GB
- Monthly cost: approximately 5 GB x 30 days x $0.01 = $1.50/month
Modest here. But scale that to a high-traffic service doing 200 GB/day of database responses across zones, and you are looking at ~$60/month just in cross-zone charges.
Example 2: inter-region compute + Cloud Storage
A batch processing VM in europe-west1 reads 5 TB/month from a Cloud Storage bucket in us-central1.
- Inter-region egress: 5,000 GB x ~$0.08/GB (US-to-Europe rate)
- Monthly cost: approximately $400/month
Moving the VM to us-central1 (same region as the bucket) drops this to $0. This is one of the simplest and most impactful cost fixes in all of GCP.
Example 3: internet delivery with and without CDN
A web app in us-central1 serves 10 TB/month of static assets to users on the internet.
- Without CDN: 10,000 GB x approximately $0.08/GB = approximately $800/month
- With Cloud CDN (75% cache hit rate): 2,500 GB origin egress + 7,500 GB at CDN rate (lower). Exact savings depend on CDN rate tier, but typically a 30-50% reduction on the egress portion
CDN works best for content that many users request repeatedly. For personalised or one-time responses, CDN does not help.
Architecture choices that create or reduce egress
Cloud Storage and compute in different regions
This is the most common accidental egress source. If your Cloud Storage bucket is in us-central1 and your processing VMs are in europe-west1, every read incurs inter-region egress. The fix is straightforward: run compute in the same region as your data.
# Check region alignment between bucket and VM
gcloud storage buckets describe gs://my-data-bucket \
--format="value(location)"
gcloud compute instances describe my-processing-vm \
--zone=us-central1-a \
--format="value(zone)"
# Both should be in the same regionDatabase in a different region from app servers
A Cloud SQL database in us-central1 serving application servers in europe-west1 turns every query into an inter-region round trip. At ~$0.08/GB for US-Europe traffic, a service transferring 10 GB/day of query results pays ~$24/month on database egress alone. Deploy read replicas near your app servers or move the app to the data’s region.
Internal IP vs external IP for service-to-service communication
Two services in the same region communicating via external (public) IP addresses route traffic off Google’s private network. Use internal IPs for all same-region communication. For services that need private connectivity without a public IP, Serverless VPC Access connects Cloud Run and Cloud Functions to your VPC on internal IPs.
# Verify a VM's internal IP
gcloud compute instances describe my-vm \
--zone=us-central1-a \
--format="value(networkInterfaces[0].networkIP)"
# Check Cloud SQL IP configuration (prefer private IP)
gcloud sql instances describe my-instance \
--format="value(ipAddresses)"Multi-zone resilience vs cross-zone cost
Spreading VMs across multiple zones improves availability. If one zone has an outage, your service survives. But all VM-to-VM traffic between zones costs ~$0.01/GB. For stateless web frontends, this is usually minor. For database replicas, distributed caches, or Kafka clusters with heavy replication, calculate the cross-zone transfer volume before committing to a multi-zone layout.
CDN and load balancer effects
Global load balancing with Cloud CDN enabled caches responses at Google edge locations worldwide. Cached content is served at CDN egress rates (lower than origin egress) and avoids hitting your backend entirely. This is effective for static assets, images, and cacheable API responses. It does not help with personalised, authenticated, or rapidly changing content where the cache hit ratio would be low.
External load balancers themselves do not reduce egress. They route traffic to backends. The egress savings come from the CDN layer they optionally enable.
Cloud Run, VMs, and GKE
Cloud Run services that call other GCP resources in the same region on internal IPs do not incur egress. But a Cloud Run service calling a Cloud Storage bucket in another region pays inter-region rates on every request. The same logic applies to GKE pods and Compute Engine VMs: co-locate with the data they access. For services that need to reach the internet through a stable IP, Cloud NAT provides outbound connectivity without assigning external IPs to individual resources.
When egress matters most
Egress is a rounding error for some workloads and a dominant cost for others. Here is who should pay closest attention:
- High-traffic web apps and APIs. If you serve large responses (images, video, downloads, large JSON payloads) to internet users, egress is often your biggest line item after compute
- Data processing pipelines. Reading terabytes from Cloud Storage across regions can cost more than the compute that processes it
- Multi-region architectures. Replicating data between regions for disaster recovery or low-latency global access creates ongoing inter-region egress
- Microservice architectures with high internal chatter. Services that exchange large payloads across zones accumulate cross-zone charges
Egress is usually minor for low-traffic internal tools, small databases with local compute, single-zone development environments, and services that mostly receive data (ingress-heavy workloads). If none of the patterns above match your setup, egress is likely a small part of your bill.
If you are not sure, check your actual bill. The cost breakdown reports guide shows how to find egress-specific SKUs in your billing data.
Finding egress charges in billing data
Export your billing data to BigQuery immediately if you have not already. Billing export does not backfill historical data. Every day you wait is data you lose permanently.
Once billing export is running, query for egress-related SKUs:
-- Find the egress SKUs driving the most cost this month
SELECT
sku.description AS sku,
ROUND(SUM(cost), 2) AS total_cost
FROM `PROJECT.DATASET.gcp_billing_export_v1_BILLING_ACCOUNT_ID`
WHERE
DATE(usage_start_time) >= DATE_TRUNC(CURRENT_DATE(), MONTH)
AND (LOWER(sku.description) LIKE '%download%'
OR LOWER(sku.description) LIKE '%egress%'
OR LOWER(sku.description) LIKE '%transfer%')
GROUP BY sku
ORDER BY total_cost DESC;To identify which traffic flows are generating the charges, enable VPC Flow Logs on your subnets:
# Enable VPC Flow Logs to trace traffic sources and destinations
gcloud compute networks subnets update my-subnet \
--region=us-central1 \
--enable-flow-logs \
--flow-sampling=0.5Set up billing budgets and alerts so you get notified before egress costs spiral. A budget alert at 50% and 80% of expected spend gives you time to investigate before the bill lands.
Common mistakes
Ignoring egress in cost estimates. A service delivering 100 TB/month to internet users incurs ~$8,000-10,000/month in egress from US/Europe regions. Architecture reviews that cover compute and storage but skip egress produce estimates that are wrong by this amount. Always include egress as a line item when estimating cloud costs.
Deploying compute and data in different regions. Processing Cloud Storage data from a VM in another region triggers inter-region egress on every read. Co-locate compute and storage in the same region for data-intensive workloads.
Using external IPs for same-region service calls. Two services in the same region communicating via public IPs route traffic off Google’s internal network, incurring charges. Switch to internal IPs to keep same-region traffic free.
Forgetting cross-zone egress in multi-zone deployments. Cross-zone VM-to-VM traffic costs ~$0.01/GB. Minor for stateless frontends, but significant for database replicas, Kafka clusters, and distributed caches with heavy replication. Calculate the transfer volume before choosing a multi-zone layout.
Assuming multi-region is always better. Multi-region deployments improve availability and latency, but every cross-region data sync incurs egress. A multi-region Cloud Storage bucket with active replication pays inter-region transfer costs continuously. Only go multi-region when the availability or latency requirement justifies the ongoing egress cost.
Waiting for the bill to investigate egress. By the time a surprise appears on an invoice, you have already paid for it. Set up billing export, budget alerts, and VPC Flow Logs proactively. Catching a misconfigured region alignment in week one costs a fraction of discovering it in month three.
Frequently asked questions
What GCP traffic is free?
All ingress into GCP from the internet is free. Traffic between services in the same zone using internal IP addresses is free. Same-region service-to-service traffic on internal IPs is free for most GCP managed services. Traffic to Google API endpoints (googleapis.com) from within GCP is also free. Everything else (internet egress, inter-region transfers, and cross-zone VM-to-VM traffic) has a per-GB charge.
Is same-region traffic in GCP always free?
For most managed GCP services communicating over internal IPs within the same region, yes. The main exception is VM-to-VM traffic that crosses zone boundaries within a region, which costs approximately $0.01/GB. If two VMs are in us-central1-a and us-central1-b, traffic between them is charged even though they are in the same region.
Does cross-zone traffic cost money in GCP?
Yes. VM-to-VM traffic between different zones in the same region costs approximately $0.01/GB in each direction. This is often overlooked because it is cheap per gigabyte, but it adds up fast for workloads with heavy internal data transfer such as database replicas, distributed caches, and message brokers.
Does Cloud CDN reduce egress costs?
Cloud CDN reduces egress costs for cacheable content. CDN egress rates are lower than standard internet egress rates, and cached content is served from edge locations without hitting your origin. The savings depend on your cache hit ratio. For static assets with a 70%+ hit rate, CDN typically produces meaningful net savings even after CDN fees.
How do I find egress charges in my GCP billing data?
Export your billing data to BigQuery, then query for SKUs containing 'egress', 'download', or 'transfer' in the description. Group by SKU and sort by cost to see which egress types are driving your bill. You can also enable VPC Flow Logs on your subnets to see exactly where traffic is flowing before it shows up on the invoice.