Cross-Zone Data Transfer
Charges incurred when data moves between availability zones within a region — invisible on architecture diagrams and a recurring surprise on cloud bills.
Traffic within a zone is typically free; traffic between zones in the same region is usually charged per gigabyte, often in both directions. At scale this becomes a substantial line item that nobody budgeted, because no diagram shows which zone a component is in.
Where it accumulates: chatty service-to-service calls that happen to be placed in different zones, database replication to a multi-AZ standby, replicated message brokers writing three copies across zones, log and metric shipping, and cross-zone load balancing.
The tension is real and should be named rather than resolved by reflex: cross-zone traffic is what makes you resilient to a zone failure. Eliminating it entirely means single-zone deployments, which is the wrong trade for anything that matters.
The defensible middle: keep chatty, high-volume, latency-sensitive paths zone-local using topology-aware routing (Kubernetes topology-aware hints, or a service mesh preferring same-zone endpoints), while keeping replication and load balancing cross-zone because that is where the resilience comes from. Also check for traffic that should not be crossing anything — object storage accessed via a NAT gateway rather than a private endpoint is a common and pure waste.
Make it visible before optimising: flow logs and per-zone cost allocation turn this from a suspicion into a number.