AWS charges for data transfer based on where the traffic goes. Traffic within a single Availability Zone over private addresses is free, but traffic between Availability Zones in the same Region bills per gigabyte in each direction, traffic between Regions bills at a higher per gigabyte rate, and traffic out to the public internet bills at the egress rate that dominates most network lines. The trap is that resilient designs spread workloads across Availability Zones for good reasons, and every cross zone database call, cache miss, replication stream, and load balancer hop then carries a per gigabyte charge that compounds with traffic volume. The fix is not to abandon resilience but to be deliberate: keep high volume chatty traffic inside one zone where availability allows, route service to service traffic over private links rather than public endpoints, and place a NAT gateway and VPC endpoints so that internal traffic never takes an expensive public path. You cannot cut what you cannot see, so the first move is always to read the Cost and Usage Report and find where the transfer charges concentrate.
Here is how each transfer path is priced, which patterns generate the surprise charges, and the design moves that bring the line down.
How does AWS price internal data transfer?
Think of four buckets. Same Availability Zone over private addresses is free. Cross Availability Zone within a Region bills a per gigabyte rate in both the send and receive direction, so a busy database replica in another zone is charged twice over. Cross Region bills a higher per gigabyte rate and is the cost of multi Region replication and global tables. Egress to the public internet bills the highest rate and is usually the largest single network line. The figures move by Region and are indicative, so confirm the current rate on the AWS pricing page, but the ordering is stable: same zone free, cross zone modest, cross Region higher, internet egress highest.
Which patterns generate surprise charges?
A handful of patterns drive most of the bill. A database in one Availability Zone serving application servers spread across three zones pays cross zone charges on every query. A cache that misses to a backing store in another zone pays twice on each miss. Chatty microservices scheduled without zone affinity scatter traffic across zones at random. Inter zone replication for Kafka, Elasticsearch, or a database cluster streams continuously and bills continuously. And traffic to AWS services over a public endpoint instead of a VPC endpoint leaves the network and comes back, picking up NAT processing and egress on the way. None of these show on an architecture diagram, which is why they survive for years.
How do you cut cross zone traffic without losing resilience?
Resilience comes from surviving the loss of a zone, not from spreading every byte across all of them. Keep the high volume, latency sensitive path, typically the application to its primary database or cache, inside a single Availability Zone, and fail over to another zone rather than running split across zones at all times. Use zone aware clients and topology aware routing so a service prefers a same zone replica before reaching across. For stateful clusters, weigh the replication traffic against the resilience it buys and tune replica counts deliberately. The goal is to pay cross zone charges only for the redundancy you actually need, not as an accidental tax on ordinary request traffic.
Where do NAT gateways and VPC endpoints fit?
A NAT gateway charges both an hourly rate and a per gigabyte processing rate, so any internal workload that reaches AWS services through it pays a processing fee on top of any egress. VPC endpoints, both gateway endpoints for S3 and DynamoDB and interface endpoints for other services, keep that traffic on the AWS private network and remove the NAT processing charge for those flows. The decision is mechanical: for high volume access to S3, DynamoDB, and other supported services from private subnets, add the relevant VPC endpoint and route around the NAT gateway. The sibling analysis on NAT gateway costs and the alternatives, linked below, works the trade in detail.
How do you find where the bytes go?
The Cost and Usage Report is the source of truth. Filter to the data transfer usage types and group by usage type and Region to see how much of the line is cross zone, cross Region, and internet egress. Turn on VPC flow logs on the busiest subnets to attribute traffic to specific services and find the chatty pairs. Tag workloads so the transfer charge has an owner. Only once you can see the flows should you change the architecture, because cutting the wrong path can move traffic onto a more expensive one. Measure, then move.
A worked example
A European SaaS company saw its AWS network line grow faster than its compute and assumed it was customer egress. The Cost and Usage Report told a different story: most of the charge was cross zone traffic from application servers spread across three Availability Zones calling a primary database and cache in a single zone, plus S3 access routed through a NAT gateway. Adding zone aware routing so services preferred a same zone path, and a gateway VPC endpoint for S3, removed the NAT processing on that flow and cut the cross zone volume. The data transfer line fell materially within one billing cycle while the multi zone failover posture was preserved. Figures are verified against billing data and anonymised.
Frequently asked questions
Is data transfer within the same Availability Zone free on AWS?
Why is my AWS data transfer bill so high?
Do VPC endpoints reduce data transfer costs?
Bring your AWS network line under control
We help AWS teams read the Cost and Usage Report, attribute internal traffic with flow logs, and redesign the chatty paths so cross zone and egress charges fall without weakening failover, across AWS, Azure, GCP, and OCI. We take zero provider commissions and answer only to you, on a Fixed Fee or a no risk Gainshare basis, with a simple guarantee: we reduce your cloud spend or we reimburse our service fee. Download the network playbook, and read the full AWS method below.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.