Excessive Cross-Zone Data Transfer Between Compute Engine and GKE Workloads

The same pricing applies to GKE nodes, and traffic to Cloud SQL, Memorystore for Redis and Filestore in the same region is priced like VM-to-VM traffic. Regional GKE clusters, managed instance groups spread across zones and replicated databases all place chatty components in different zones by design, and Kubernetes Service load balancing sends requests to endpoints in any zone by default.

For high-throughput paths such as service-to-service calls, cache and database reads, Kafka or other replication, and shuffle-heavy data processing, the per-GiB charge scales with traffic volume and is easy to miss because it is spread across the sending projects as network SKUs. Google's GKE cost guidance notes that multi-zonal clusters are charged for egress between zones, recommends monitoring cross-zone traffic and minimizing it, and recommends single-zone clusters for non-production.

Rates are per GiB and can vary by location; check the Network pricing page for current values.

Same-zone internal traffic

No charge for traffic to the same zone over internal IPv4 or any IPv6 addresses within the same VPC network

Inter-zone traffic

Charged per GiB when source and destination are in different zones of the same region, over internal or external IPs within the same VPC network ($0.01 per GiB listed)

External IPv4 paths

All traffic to and from external IPv4 addresses leaves the zone, so using external IPs between nearby VMs is billed even in one zone

Managed services in region

Traffic to Cloud SQL, Memorystore for Redis, Filestore and GKE in the same region is priced the same as VM-to-VM traffic

• In the Cloud Billing export, group inter-zone data transfer SKUs for Compute Engine by project and label to find where the cost is concentrated (the sending VM's project is billed)
• Enable GKE usage metering with its network egress agent (disabled by default) to attribute cross-zone egress to namespaces and workloads; it is not supported on clusters with more than 150 nodes, Shared VPC or VPC Network Peering
• Use VPC Flow Logs, which record source and destination instance zones, to find the top cross-zone talker pairs
• Check whether clients use external IPs to reach services in the same region, which is billed as leaving the zone

• Keep traffic in-zone where possible: for GKE internal LoadBalancer Services, enable zonal affinity (requires GKE subsetting), which routes new connections to serving Pods in the client's zone and falls back to other zones when none are healthy
• Place tightly coupled, high-volume components (for example a batch job and its cache) in the same zone when their availability requirements allow, and use single-zone clusters and instance groups for non-production
• Use internal IP addresses for traffic inside the region instead of external IPs
• Reduce what crosses zones: compress or batch payloads, read from zone-local replicas where the database supports it, and review replication fan-out

• Network pricingcloud.google.com
• Best practices for running cost-optimized Kubernetes applications on GKEdocs.cloud.google.com
• About LoadBalancer Servicesdocs.cloud.google.com