AWS VPC data transfer cost: estimate cross-AZ, cross-region, and egress

VPC data transfer costs often show up as "small" per-GB rates that become large at scale. The hard part is not the math - it is identifying how much traffic crosses pricing boundaries (AZ, region, and internet).

Step 1: Map the traffic boundary (draw the path)

Start with one real request path and draw it end-to-end: client -> edge/CDN -> load balancer -> services -> databases -> third parties. Mark every place traffic crosses AZs, regions, or the public internet.

  • Cross-AZ: service calls between instances in different AZs (often accidental)
  • Cross-region: replication, multi-region reads, active-active patterns, failover tests
  • Internet egress: responses to users/customers/partners and downloads
  • NAT paths: private subnets reaching public endpoints or AWS services through NAT (often avoidable with endpoints)

Step 2: Estimate GB/month (pick the best method you can)

Method A: From billing exports (best for budgets)

  • In CUR/Cost Explorer, group by usage type and identify transfer-related line items.
  • Break down by account and region so "one noisy VPC" does not hide.

Method B: From VPC Flow Logs (best for boundaries)

  • Roll up bytes by source/destination and map them to AZ and region boundaries.
  • Use flow logs to validate whether a suspected cross-AZ path is real (and how big it is).

Method C: From throughput charts (good first pass)

  • Convert Mbps to GB/month with Units Converter.
  • Apply a boundary share (for example, "30% of service traffic crosses AZ") and test sensitivity with low/medium/high scenarios.

Step 3: Price the right path

Once you have GB/month per boundary, use a calculator with an effective $/GB for your situation (cross-AZ, cross-region, egress).

Worked estimate template (copy/paste)

  • Cross-AZ GB/month = GB/month service-to-service calls that cross AZ
  • Cross-region GB/month = replication GB/month + cross-region reads GB/month
  • Internet egress GB/month = bytes delivered to users/partners (separate CDN bandwidth from origin egress)
  • Total transfer cost = (cross-AZ cost) + (cross-region cost) + (egress cost)

Common pitfalls

  • Assuming "same region means free". Many billed paths are within a region (especially cross-AZ).
  • Accidental cross-AZ traffic caused by load balancer routing and uneven capacity.
  • Sending AWS-service traffic through NAT when a VPC endpoint would keep the path private (and may reduce cost).
  • Double-counting CDN bandwidth and origin egress as the same GB.
  • Unit errors: Mbps vs MB/s and GB vs GiB (use the Units Converter if needed).

How to validate the estimate

  • After one billing cycle, reconcile transfer usage types against your modeled GB/month boundaries.
  • Spot-check one suspected path with flow logs to confirm the magnitude and direction.
  • Re-run the estimate after major changes (new region, new CDN, new replication, new endpoints).

Related tools and guides

Sources


Related guides


Related calculators


FAQ

What creates VPC data transfer costs?
Cross-AZ traffic, cross-region traffic, and internet egress are the most common drivers. Many architectures generate unexpected east-west traffic (service calls, replication, cache fill).
How can I estimate GB/month reliably?
Use billing exports, VPC Flow Logs, or service metrics where possible. If you only have throughput charts, convert Mbps to GB/month and sanity-check the share that crosses pricing boundaries.
What's a high-leverage way to reduce transfer spend?
Reduce accidental cross-AZ traffic (placement and routing), keep data locality where possible, and avoid sending AWS-service traffic through NAT by using VPC endpoints when it makes sense.
Why is transfer so hard to budget?
Because the bill depends on the path. The same application can be cheap or expensive depending on where traffic crosses AZ, region, and internet boundaries.

Last updated: 2026-02-07