GKE Cross-Zone Traffic Optimization Opportunity
What does ZopNight detect here?
GKE clusters spanning more than 1 zone are detected, but the rule abstains from any recommendation today: GCP's billing export is not read at SKU grain, so the real inter-zone egress cost cannot be separated from compute spend. That cost is the basis for the intended 0.30-reduction saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-123 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | gke_cross_zone.go |
Where it applies
A zones count above one
- resource.Tags zones_count > 1 (multi-zone detection via isGKEMultiZone; fail-closed: single-zone / absent → abstain)
Why GCP has no billed inter-zone egress figure
concrete-or-abstain (cost-driven rightsizing). Currently abstains (returns nil), a documented abstain. The intended saving is the real billed GCP inter-zone egress cost × reductionFactor (a config/annotation-only lever, no power/delete/auto-remediation). PRODUCER-GAP (why GCP cannot mirror the now-concrete AWS twin RC-065): the AWS twin is concrete because the AWS discoverer holds ce:GetCostAndUsage and harvests account-grain billed cross-AZ transfer (GB + UnblendedCost on the DataTransfer-Regional-Bytes axis) in one existing call, stamping cross_az_transfer_cost_usd on a data-transfer-account resource. GCP has no reachable equivalent: (1) the GCP discoverer has no billing access (no BigQuery dep, no billingTable cred, no Cost-Explorer-equivalent SDK); (2) the only GCP billed-cost source, the aggregator’s BigQuery billing-export reader (backend/aggregator/internal/billing/gcp/client.go), groups only by service.description / location.region / resource.name, not by sku.description, so the inter-zone egress SKU (“Network Inter Zone Egress”, a distinct line item under the “Compute Engine” service) is not separable from compute; (3) Cloud Monitoring’s networking.googleapis.com/vm_flow/egress_bytes_count needs VPC Flow Logs (often off) and is GB volume only, not billed cost. r.pricing[uid] is cluster compute cost, not transfer cost, so any fraction would be fabrication. Under the strict no-advisory directive it abstains rather than emit a $0/fabricated-fraction card. The precise close condition works at account/project grain like RC-065, not per-cluster: add a SKU-grained BigQuery producer (SUM(<netCostExpr>) and SUM(usage.amount_in_pricing_units) WHERE LOWER(sku.description) LIKE ‘%inter zone%’ at project grain), surface inter_zone_egress_cost_usd (+ cross_zone_transfer_gb) on a synthetic GCP data-transfer-account/project resource (mirroring AWS data_transfer.go), then re-point RC-123’s ResourceType + Evaluate onto it with SavingsUSD = inter_zone_egress_cost_usd × 0.30 (same reduction factor as RC-065: multi-zone HA inherently needs some cross-zone traffic; GCP inter-zone egress semantics match AWS cross-AZ). No new SDK call / IAM permission; the BigQuery grant already covers an additional SKU-grained query. The prior cost*0.30 fraction and the later $0/”advisory” emission were both removed.
Topology hints and pod placement
- Enable topology-aware hints on Services: set annotation service.kubernetes.io/topology-mode=auto
- Use pod affinity rules to co-locate interdependent workloads in the same zone
- Configure PodTopologySpread constraints to balance across zones without excessive cross-zone calls
- Review Cloud Monitoring inter-zone traffic metrics to quantify actual transfer volume
- Label the cluster with topology_routing=true after implementing