AWS cross-AZ data transfer cost: causes and estimate steps

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-07-22. Editorial policy and methodology.

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Data Egress Cost Calculator API Response Size Transfer Calculator VPC Data Transfer Cost Calculator Cross-region Transfer Cost Calculator

Cross-AZ data transfer costs appear when bytes move between Availability Zones inside a region. The cost is easy to model once you know GB/month crossing zones, but the hard part is identifying what causes the cross-AZ traffic in your architecture.

This is the AZ-locality diagnosis page in the VPC transfer cluster: use it when the suspected cost driver is traffic between Availability Zones. If you still need to separate internet egress, cross-region, NAT, endpoint, and cross-AZ paths, start with the VPC transfer guide first.

Quick cross-AZ estimate

Total GB/month: service traffic at the boundary.
Cross-AZ share: percent of traffic crossing zones.
Cost: GB/month x cross-AZ rate.

Use this page for locality, not broad transfer routing

Stay here when the question is which clients, targets, pods, databases, or NAT paths are crossing AZs.
Leave this page when the traffic might be internet egress, cross-region replication, or endpoint/NAT processed GB instead.
Use the calculator after diagnosis when cross-AZ GB and the effective path rate are credible enough to convert into spend.

Common causes of cross-AZ transfer

Load balancers: traffic enters one AZ and is forwarded to targets in another (cross-zone patterns).
Databases: multi-AZ replication and client connections crossing AZ boundaries.
Kubernetes: pods in AZ A calling services/endpoints in AZ B (uneven scheduling or service topology).
NAT gateways: workloads in one AZ using a NAT gateway in another can create cross-AZ bytes.
Shared services: centralized logging, proxies, or caches in a single AZ serving multi-AZ workloads.

How to estimate cross-AZ GB/month

Start from traffic volume: total GB delivered/processed for the service boundary (API, LB, service mesh).
Estimate cross-AZ fraction: what percent of traffic crosses zones (0% if perfectly zone-local, often 5-20% in practice).
Cross-AZ GB/month ~= total GB/month x cross-AZ fraction.

VPC transfer cost calculator VPC transfer path classification Unit converter

Where to get the inputs (practical)

VPC Flow Logs: measure bytes between subnets/ENIs tagged by AZ.
Load balancer metrics: identify uneven target distribution and cross-zone behavior windows.
Kubernetes topology: compare client pod AZ vs endpoint AZ distributions.

If you cannot measure yet, use a conservative range (for example 10-30%) and validate later with flow logs.

How to reduce cross-AZ cost safely

Keep traffic zone-local: ensure targets/endpoints are evenly spread across AZs and clients prefer same-AZ targets.
Avoid centralized single-AZ dependencies: caches, proxies, and NAT should be deployed per AZ where possible.
Validate LB and client behavior: confirm routing policies actually keep traffic local under load and during scale events.
Watch failure modes: some cross-AZ traffic is the "safety cost" during partial AZ failures; optimize without reducing resilience.

Validation checklist

Measure cross-AZ GB/day from flow logs for at least 7 days.
Confirm cross-AZ fraction during deploys and scale events (often worse than steady state).
After changes, validate both cost reduction and resilience behavior during AZ degradation.