AWS Data Transfer Fees (2026)

Most AWS pricing is intuitive once you know the rate: a server costs this much an hour, storage this much a gigabyte. Data transfer is the exception, because the price of moving a gigabyte depends not on the gigabyte but on where it is going. The same byte is free between two servers in one Availability Zone, costs a cent to cross into the next zone, two cents to reach another region, nine cents to reach the internet, and four and a half cents more if it happens to pass through a NAT Gateway on the way. Six paths, six prices, one invoice line that almost nobody can explain.

This guide maps every one of those paths with 2026 US rates from the official EC2 data transfer pricing, VPC pricing, and CloudFront pricing pages, shows which charges actually inflate real bills (it is rarely the one people budget for), works through a typical three-tier application, and ends with seven changes that cut transfer costs without rebuilding anything.

Key Takeaways

• Data transfer is priced by path, not volume: free in-zone, $0.01 per GB each way across zones, ~$0.02 across US regions, $0.09 to the internet, plus $0.045 per GB through a NAT Gateway.
• The 100 GB monthly free allowance covers internet egress only; inter-AZ, inter-region, and NAT processing have no free tier.
• In a typical multi-AZ application, cross-zone chatter and NAT processing often cost more than the internet egress everyone budgets for.
• CloudFront is the largest single lever for public content: free from AWS origins, $0.085 per GB out, 1 TB free, and caching that cuts origin volume.
• Gateway VPC endpoints for S3 and DynamoDB are free and remove the NAT charge on the heaviest internal traffic most accounts carry.

The Complete Rate Map

Rates are US East (N. Virginia) list prices as of October 2026 in US dollars per GB; other regions vary and several are higher.

Where the Money Actually Goes

Teams budget for internet egress because it is the rate everyone quotes. In practice three other charges usually dominate, and each is invisible until you look for it.

• Cross-zone chatter. A multi-AZ architecture places application servers in three zones and a database primary in one. Every query from two-thirds of the servers crosses a zone boundary, paying $0.02 per GB round trip. Add a cache in another zone and service-to-service calls and a busy application can move terabytes a month between zones without a single byte reaching the internet.
• NAT Gateway processing. Instances in private subnets reach the internet, and AWS services, through a NAT Gateway, and every byte in either direction pays $0.045. The common surprise is that a large share of that traffic is to S3, DynamoDB, or other AWS APIs, which a VPC endpoint would carry for nothing. A nightly batch job pulling 2 TB from S3 through NAT costs $90 in processing for traffic that should be free.
• Inter-region replication. Cross-region database replicas, S3 replication, and multi-region deployments pay about $0.02 per GB continuously. A replicated database writing 500 GB a day pays roughly $300 a month in transfer before storage, which is often more than the replica's compute.

This is why data transfer is, with public IPv4 addresses, the clearest example of cloud waste that hides in small per-unit charges: the rate is tiny, the volume is invisible, and nobody owns the line.

A Worked Example: A Three-Tier Application

Consider a production web application in US East: a load balancer across three Availability Zones, six application servers spread across those zones, a database primary in one zone with a read replica in another, and an S3 bucket the app reads from through a NAT Gateway because the servers sit in private subnets. It serves 2 TB a month to users.

Internet egress is what the team budgeted: 2 TB less 100 GB free, about 1.9 TB at $0.09, roughly $175. Now the unbudgeted paths. The application servers exchange about 6 TB a month with the database, and because two-thirds of them are in zones other than the primary's, about 4 TB crosses zones at $0.02 round trip: $80. Replication to the read replica moves 1.5 TB across zones one way: $15. Service-to-service calls between app servers in different zones move another 3 TB: $60. And the servers pull 3 TB from S3 through the NAT Gateway: $135 in processing plus about $33 for the gateway itself. The unbudgeted total is around $323, nearly twice the $175 of internet egress the team planned for, and the whole transfer line is about $500 a month.

Apply the levers. A gateway endpoint for S3 removes the $135 NAT processing at no cost. Routing the 2 TB of public content through CloudFront drops the egress to about $85 after the 1 TB free tier and cuts origin traffic further through caching. Zone-aware routing so that servers prefer same-zone database and service calls can halve the cross-zone chatter, saving about $70. The line falls from roughly $500 to about $200, with no change to the application's architecture beyond configuration.

Seven Ways to Cut AWS Data Transfer Fees

1. Put CloudFront in front of anything public

Transfer from AWS origins to CloudFront is free, CloudFront's egress is cheaper than regional egress, its free tier is ten times larger, and caching means much of the traffic never reaches the origin. For static assets, media, downloads, and APIs with cacheable responses, this is the single largest saving available.

2. Replace NAT with gateway endpoints for S3 and DynamoDB

Gateway VPC endpoints are free and route traffic to S3 and DynamoDB privately, removing the $0.045 per GB NAT processing on what is often the heaviest internal traffic in an account. This is a routing-table change with no downside.

3. Use interface endpoints where they are cheaper than NAT

For other AWS services, an interface endpoint costs about $0.01 per GB plus a small hourly fee against NAT's $0.045 per GB. At more than a few hundred gigabytes a month per service, the endpoint wins.

4. Keep chatty tiers in the same zone

Resilience requires multiple zones; it does not require every request to cross one. Zone-aware load balancing, topology-aware routing in Kubernetes, and placing caches and read replicas in the zones that read them keep hot paths local and reserve cross-zone traffic for failover.

5. Compress and cache before you send

Response compression, efficient serialization, and application-level caching reduce every transfer charge proportionally, because they reduce the gigabytes. A 60 percent compression ratio on API responses is a 60 percent cut in egress for that path.

6. Question every cross-region flow

Replication and multi-region designs pay transfer continuously. Keep them where compliance or latency genuinely demands them, and replicate deltas rather than full copies where the service allows.

7. Measure it per resource and give it an owner

Enable VPC Flow Logs, filter the Cost and Usage Report by the transfer usage types, and attribute the result to the teams whose services generate it. Transfer stays high when it is a single unowned line on the bill; it falls quickly once a team can see that its service is the one talking across zones. That attribution is the general practice in our guide to cloud cost allocation, and it is what Opslyft's cost visibility is built to make routine across networking and every other service line.

Where the Charges Are Worth Paying

Not all transfer is waste. Multi-AZ failover traffic is the price of surviving a zone outage. A NAT Gateway serving a private subnet's genuine internet needs is cheaper and safer than public IPs on every instance. Cross-region replication for disaster recovery or data residency is a legitimate cost of the requirement. The aim is not zero transfer; it is zero transfer that a routing change would have made free

The Bottom Line

AWS data transfer fees are confusing because they price the route rather than the data, and expensive because the routes that cost most are the ones nobody looks at. Internet egress is the charge everyone budgets, and in a multi-AZ application it is often the smaller part; cross-zone traffic and NAT processing are where the bill grows. Map your traffic by path, move public content behind CloudFront, replace NAT with endpoints for AWS services, keep hot paths in one zone, and attribute what remains to the teams that cause it. Then revisit it quarterly, because new services default to the expensive paths every time. For the wider set of AWS charges that behave this way, see our guides to AWS cost optimization and S3 cost optimization, where egress is the largest hidden line.