To reduce Kubernetes cross-AZ traffic costs, measure inter zone bytes first, then enable topology aware routing, set local traffic policy where safe, co-locate chatty services with pod affinity, and zone align stateful traffic. AWS charges about 0.01 US dollars per GB in each direction across zones, so every avoided hop saves twice. The core trade is cost versus resilience, so keep high volume latency tolerant traffic zone local and leave genuinely critical paths multi zone. Re-measure after each change.
Last updated: June 2026. Written by Fredrik Filipsson and reviewed by Morten Andersen, built on our See, Cut, Lock, Run method.
This article sits in our complete guide to Kubernetes cost optimization, the cluster pillar it links up to, and connects to the broader cloud cost optimization playbook. Once traffic is contained, the next lever is node level efficiency, covered in our companion guide on how to tune Karpenter consolidation for maximum savings. Cutting inter zone traffic is a Cut step move that often pays back the same week.
About 0.01 US dollars per GB, each direction. Because AWS bills cross zone transfer on both the send and the receive side, a gigabyte that crosses a zone boundary costs roughly 0.02 US dollars round trip, while the same gigabyte inside one zone over private IPs is free. Multiply that by a service mesh, replicated databases, and chatty microservices running terabytes a day, and the inter zone line becomes a real number. Every hop you keep local saves on both sides.
How much does cross-AZ traffic cost?
Cross-AZ traffic on AWS costs about 0.01 US dollars per GB in each direction between Availability Zones in the same region, roughly 0.02 US dollars per gigabyte round trip. Per the AWS data transfer charges documentation, traffic within a single zone over private IP addresses is free, which is exactly why keeping calls zone local is the lever. Verify the current rate for your region in that documentation before modeling, because AWS data transfer pricing changes. The same idea applies on other clouds with their own inter zone rates.
Why is cross-AZ traffic so expensive in Kubernetes?
Cross-AZ traffic is expensive in Kubernetes because the scheduler spreads pods across zones for resilience and services load balance across all endpoints without regard to zone, so a request frequently crosses a boundary even when a same zone backend exists. A single user request can fan out through several services, each adding an inter zone hop, and replicated databases and service mesh sidecars multiply the bytes. Since every GB is billed in both directions, those invisible hops compound into one of the larger lines on an EKS bill, usually without anyone deciding to spend it.
How do I reduce it, step by step?
Reduce it by measuring first, then keeping traffic local through routing, policy, and placement. Six steps:
- Measure cross zone traffic. Use VPC flow logs or a service mesh to find which services drive the most inter zone bytes. Result: a ranked list so you fix the biggest flows first.
- Enable topology aware routing. Turn it on so the service prefers endpoints in the caller's zone. Result: most stateless traffic stays local with no app change.
- Set local external traffic policy. Set externalTrafficPolicy and internalTrafficPolicy to Local where safe. Result: traffic stays on the receiving node's zone instead of being re-routed.
- Co-locate chatty services. Use pod affinity to keep tightly coupled services and their caches in one zone. Result: the inter zone hop disappears for the noisiest pairs.
- Pin stateful and replication traffic. Keep databases, brokers, and their clients zone aligned. Result: heavy replication and query traffic stops crossing zones, with the availability trade off you choose.
- Recheck the bill. Re-measure inter zone bytes after each change. Result: you keep what works and revert anything that hurts availability.
How do I balance savings against availability?
Balance it per workload: keep stateless, high volume, latency tolerant traffic zone local for the savings, and keep genuinely critical paths multi zone for resilience. Zone local routing concentrates load and removes some cross zone redundancy, so a blanket setting is the wrong move. Instead, classify each service. A read heavy cache or a stateless API that can tolerate a zone failing is a good candidate for local routing; a payment path that must survive a zone outage is not. Topology aware routing helps here because it falls back to other zones when local endpoints are insufficient, giving you savings with a safety valve.
Want the inter zone line found and cut without breaking resilience?
Our Kubernetes cost audit measures your cross zone flows, ranks them by spend, and applies routing and placement changes with the availability trade offs made explicit. On the performance model, you pay only from realized savings. No savings, no fee.
Book a Kubernetes cost audit →What keeps cross-AZ cost from creeping back?
What keeps it down is monitoring inter zone bytes as a standing metric and adding zone awareness to new service defaults. Cross-AZ cost creeps back when teams ship new chatty services with default routing, so put inter zone transfer on the cost dashboard, alert when it jumps, and make topology aware routing and affinity part of the platform's service template. This is the Lock step: the savings stay only if the guardrails do. The broader networking and egress playbook lives in our Kubernetes guide.
The Kubernetes Cost Optimization Handbook includes the cross zone traffic measurement queries and the zone alignment decision matrix referenced above. It is the downloadable companion to this guide.
Frequently asked questions
How much does cross-AZ traffic cost on AWS?
AWS charges about 0.01 US dollars per GB in each direction for data transferred between Availability Zones in the same region over private IPs, so a gigabyte sent from one zone to another is billed roughly 0.02 US dollars round trip. Traffic between instances in the same zone over private IPs is free. Confirm current rates in the AWS data transfer pricing documentation, because they change.
What is topology aware routing in Kubernetes?
Topology aware routing is a Kubernetes feature that biases service traffic toward endpoints in the same zone as the calling pod, so requests stay within a zone and avoid the cross-AZ data transfer charge. It works through endpoint hints that kube-proxy uses when picking a backend, and it falls back to other zones when local endpoints are insufficient.
Does keeping traffic in one zone hurt availability?
It can, because zone local routing concentrates load and removes the cross zone redundancy that multi-AZ deployments provide. The right approach is to keep stateless, high volume, latency tolerant traffic zone local for savings while keeping genuinely critical paths multi zone. Treat it as a deliberate cost versus resilience trade off per workload, not a blanket setting.
Why is cross-AZ traffic such a large part of Kubernetes bills?
Kubernetes spreads pods across zones for resilience and load balances services blindly, so a request often crosses a zone boundary even when a local endpoint exists. Service meshes, replicated databases, and chatty microservices multiply those hops. Because each GB is billed in both directions, the inter zone line can quietly become one of the largest items on an EKS bill.
The short version
Measure inter zone bytes, enable topology aware routing, set local traffic policy, co-locate chatty services, and zone align stateful traffic, all while keeping critical paths multi zone. Each avoided hop saves on both sides at about 0.01 USD per GB. When you want the flows mapped and cut for you, that is what our rightsizing and waste elimination service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.