AWS Data Transfer Costs Between Regions and AZs

Traffic between EC2 instances, RDS, ElastiCache, and other services within a single AZ, routed over private IPs, is genuinely free; zero dollars. This is why co-locating high-bandwidth services in the same AZ is so attractive.

Now here's the part that trips people up. Route that exact same traffic over a public or Elastic IP, and you're paying $0.01/GB in each direction. Inside the same AZ. On traffic that never leaves the building, so to speak.

This isn't some obscure billing quirk buried deep in the documentation. It's a misconfiguration. The charge triggers on address type, not physical distance. AWS sees a public IP, assumes internet-bound routing, and bills accordingly. The fact that both endpoints are sitting 200 meters apart in the same data center is completely irrelevant to the billing engine — it's like getting charged for a cross-country flight because you walked through the airport's international terminal on the way to your gate. It just doesn't care.

Before you assume intra-AZ is a zero-cost baseline, audit your internal service communication. Check whether your EC2 instances, RDS connections, ElastiCache clients, and VPC-peered services are all talking over private IPs. If anything is using Elastic IPs or public addresses for internal traffic, you are paying for distance you are not actually crossing.

Cross-AZ pricing and how it doubles in practice

The rate sounds almost negligible: $0.01/GB. The problem is the direction.

AWS charges $0.01/GB out of the source AZ and $0.01/GB into the destination AZ. Every gigabyte crossing an AZ boundary costs $0.02 round-trip. It shows up as two separate line items on your bill, which makes it genuinely easy to undercount if you're only scanning totals instead of doing the multiplication yourself.

Services affected include EC2, RDS, Redshift, DAX, ElastiCache, Elastic Network Interfaces, and VPC Peering connections that span AZs. If your architecture touches any of these across zone boundaries, this charge is already somewhere on your bill right now.

At low volumes, the rate looks harmless. It stops looking harmless when workloads making thousands of cross-AZ calls per second turn that penny-per-GB into a meaningful monthly number very quickly. Standard AWS high-availability patterns are built on exactly that kind of volume. The HA default and the cost default are quietly working against each other — like two people trying to save money by each buying half a sandwich, then paying separately for two bags — and most teams don't notice until the bill arrives.

How common distributed architectures turn cross-AZ charges into the largest line item on the bill

Three-AZ deployments are the AWS reliability default. That's not a criticism; it's genuinely the right call for most production workloads. But it means cross-AZ traffic is baked into standard high-availability patterns, including Kafka clusters, multi-AZ RDS reader fleets, and EKS pod scheduling. The reliability you need comes with a transfer cost you probably didn't budget for.

Here's a concrete number. Thirty pods spread across three AZs, each handling 200 requests per second, each request reading 50 KB from a cross-AZ Redis cluster. That load produces roughly 25 TB of cross-AZ traffic per day. At $0.02/GB round-trip, that's $500/day, or around $15,000/month. Just on Redis reads. No inter-Region traffic. No internet egress. Just pods talking to a cache cluster across zone boundaries.

Adding Kubernetes zone-affinity hints so pods prefer same-AZ replicas cuts that bill to roughly $1,500/month. That's a 90% reduction. No code changes. No performance regression. Just a topology hint telling the scheduler to keep traffic local.

This has played out in documented real-world cases where cross-AZ data transfer was the single most expensive AWS service on the bill, representing 25% of total cloud spend. Across the industry, data transfer typically accounts for 10 to 15% of total AWS spend, climbing to 40% for data-intensive workloads like media streaming, analytics, and SaaS platforms with a global user base.

One other fast configuration change for stateless workloads: disable cross-zone load balancing on your ALBs and NLBs. By default, load balancers distribute traffic across all registered targets regardless of AZ. Turning this off routes requests to targets in the same AZ as the original request. It's often the fastest single change you can make to reduce cross-AZ charges, and it takes about ten minutes.

Inter-Region pricing: why the destination Region is the variable that matters most

Inter-Region transfer rates run from $0.02 to $0.17/GB depending on the source-destination pair. Geographic distance has some influence, but it's not the whole story. The specific pairing is what sets your rate, and the difference between pairs can be pretty dramatic.

Consider: 2 TB/month replicated from US-East-1 to SA-East-1 runs about $180/month in transfer charges alone. The same 2 TB replicated to EU-West-1 costs about $40/month. That's a significant monthly difference driven entirely by which Region you picked as the destination. Over a year, that's $1,680 you could have avoided by checking the pricing page before committing to the architecture instead of after.

The billing structure works like this: inter-Region transfers produce two line items. The data transferred out from the source Region gets charged. The data transferred into the destination Region is free. The outbound line from the source carries the full cost, which makes it easy to walk past in Cost Explorer if you're only looking for line items that appear large on their own.

Some adjacent US Region pairs, like US-East-1 to US-East-2, carry lower rates than transfers to premium Regions. Always verify the specific pair on the AWS pricing page before locking in a replication or disaster-recovery architecture. The destination choice compounds month over month. Unwinding it later isn't free, either.

NAT Gateway and Transit Gateway fees that compound on top of the base transfer rate

Base transfer rates are only part of the story. Networking middleboxes add per-GB processing fees on top of whatever base rate already applies, and those fees stack whether you're thinking about them or not.

NAT Gateway charges $0.045/GB in processing fees, plus roughly $0.045/hour per gateway (about $32.40/month per gateway). A standard multi-AZ setup with three NAT Gateways costs close to $100/month before a single byte moves through them. That's just the cover charge.

The most avoidable NAT Gateway trap is S3 traffic. By default, traffic from your VPC to S3 routes through the NAT Gateway, even when the S3 bucket is in the same Region. At high volumes, you're looking at hundreds of dollars per day in processing fees that should cost nothing to route.

The fix is a VPC Gateway Endpoint for S3. It's free. No hourly charge, no processing fee. It routes traffic directly over the AWS backbone instead of through the NAT Gateway. Deployment takes about ten minutes. This is probably the clearest cost-reduction step available in the entire transfer cost hierarchy, and it's also the one most teams leave on the table the longest. VPC Gateway Endpoints for DynamoDB work exactly the same way.

For other services, Interface Endpoints via PrivateLink charge roughly $0.01/GB in processing. Still a charge, but a 78% reduction versus NAT Gateway processing fees.

Transit Gateway adds roughly $0.02/GB in data processing on top of any applicable inter-Region or cross-AZ rate, plus an hourly charge per attached VPC or connection. The compounding gets genuinely ugly: a cross-AZ transfer routed through both NAT Gateway and Transit Gateway can carry three separate per-GB charges simultaneously. The base transfer rate. NAT processing. Transit Gateway processing. All on the same byte.

Internet egress pricing and the 2025 free-tier change

Internet egress is the most expensive tier at $0.09/GB for the first 10 TB/month. The rate steps down at higher volumes, but for most teams, the first 10 TB is where the majority of the bill lives.

In 2025, AWS expanded the monthly free allowance from roughly 1 GB to 100 GB. That's genuinely useful for development environments and low-volume workloads. For production data-intensive pipelines, the math doesn't meaningfully change; the free tier is a rounding error at scale.

S3 internet egress uses the same tiered rate structure as EC2 egress. There's no discount for pulling directly from object storage versus EC2. A lot of teams assume S3 is cheaper to read from when traffic is heading to end users. It isn't.

A scenario that catches teams off guard: serving application assets or model outputs directly from S3 to end users. Each download bills at the full internet egress rate. At low volumes, it's manageable. At scale, it becomes a significant recurring line item that gets worse every month as the product grows.

CloudFront offers a lower per-GB rate than direct S3 egress for high-volume public delivery. It's not free, but the economics improve as volume grows. Worth running the numbers before committing to direct S3 delivery at scale.

One thing the 2025 free-tier expansion does not touch: cross-AZ and inter-Region rates. Those are unchanged.

How AI and ML pipelines amplify every tier of the transfer cost hierarchy

AI and ML workloads don't just incur data transfer costs. They amplify every tier of the hierarchy simultaneously, and they do it at a scale that makes the distributed architecture examples above look modest.

Storage and data transfer typically add 10 to 20% on top of compute costs in AI/ML pipelines. Compute is still the biggest slice, but that overhead compounds across long training runs in ways that are easy to underestimate early in a project, when you're focused on whether the model actually works and not on what it costs to move data around.

The pattern that catches teams off guard is the late-stage cost spike. Early experimentation is compute-heavy but light on data movement. As pipelines mature, datasets grow, distributed nodes multiply, and the biggest data movement often happens after budgets are already set. Trained models get exported. Inference data gets distributed. Evaluation datasets get copied across Regions. The bill that arrives looks nothing like the one from the prototype phase, and by then the architecture is locked.

There's a downstream consequence worth naming: GPU starvation. Average GPU utilization in production AI environments sits around 55 to 65%, meaning a significant chunk of very expensive compute capacity goes unused. The bottleneck is often data feed, not model complexity. Traditional storage delivers sequential reads at 1 to 5 GB/s; a single modern GPU can consume data at 15 to 30 GB/s during training. That gap is what produces the stall. Meta found that 56% of GPU cycles sat stalled waiting for training data, which is what drove them to build a dedicated preprocessing service rather than keep absorbing the loss.

Multi-cloud AI pipelines make everything worse. Moving training data between clouds incurs $0.05 to $0.12/GB in egress. For petabyte-scale workloads, that translates to hundreds of thousands of dollars in data movement costs before any compute work happens.

The NASA situation is worth knowing about. The agency didn't account for egress costs when contracting cloud storage and ended up facing $30 million per year in egress fees on top of a $65 million per year storage contract. That's not a billing misunderstanding; that's an architecture planning failure that showed up very late and very expensively.

It's not rare, either. A 2025 Fivetran report found that 42% of enterprises have seen more than half of their AI projects delayed or underperforming due to poor data readiness. Data transfer bottlenecks are a direct contributor to that number.

Reducing data movement for AI teams isn't just a cost optimization; it's a prerequisite for keeping GPUs fed and pipelines on schedule.

Architectural patterns that reduce transfer costs without changing application logic

Most of the biggest transfer cost reductions don't require rewriting your application. They require smarter decisions about where things live and how they talk to each other. Mostly configuration, not code.

Co-locate compute and data in the same AZ. Highest-leverage decision available. Costs nothing to implement at design time. Make it the default assumption, not the afterthought you revisit when the bill arrives.

Use private IPs for all intra-AZ and intra-Region service communication. Audit existing deployments for public or Elastic IP misrouting. If you find any, fix them first. Savings are immediate and the change is low-risk.

Deploy VPC Gateway Endpoints for S3 and DynamoDB. Free, fast, and eliminates the most common NAT Gateway processing charge. Many teams haven't done this yet; it takes an afternoon.

Add zone-affinity topology hints to Kubernetes workloads. The EKS and Redis example above showed a 90% cost reduction with no code changes. If you're running EKS and haven't done this, it's probably next on your list.

Disable cross-zone load balancing on ALBs and NLBs for stateless services. Keeps traffic within the originating AZ. Fast to change, immediately effective.

Model destination Region costs before committing to replication or DR architectures. The $140/month difference between EU-West-1 and SA-East-1 for 2 TB/month compounds into a significant annual number. Run the math before the architecture is locked.

For AI/ML pipelines, bring compute to data rather than moving data to compute. The mental model shift here is real. Instead of downloading training data to a local volume before a job runs, cloud-native filesystems can mount existing object storage buckets directly as POSIX filesystems with local NVMe caching. The source bucket stays the single source of truth. Cross-Region copies for distributed training runs disappear. The data-movement pipeline as a cost and latency layer simply stops existing. I've watched teams discover this mid-project and feel equal parts relieved and annoyed that nobody told them sooner.

Tools like Archil do exactly this. Archil mounts S3, GCS, Azure Blob, and R2 buckets as a POSIX filesystem, so a training job reads directly from the mounted filesystem without a prior copy step. For teams running agents or iterative workloads, persistent shared filesystems that mount across many nodes simultaneously also eliminate redundant per-run data fetches that each generate billable egress.

Use S3 Express One Zone for hot training data paths. When single-digit-millisecond access matters and data fits within a single AZ, S3 Express One Zone delivers 10x faster access and 2 million transactions per second compared to S3 Standard. That speed reduces the time and repeated-read cost of iterative training loops across a long run.

Check AWS Cost Explorer for inter-Region line items on any replication job. The outbound line from the source Region carries the full charge. It's easy to overlook when you're scanning for large numbers. Find it early, before datasets grow and the number becomes harder to argue with in a budget conversation.

The decisions that produce the biggest transfer bills are almost never made by someone thinking about transfer costs. They're made by someone trying to solve a reliability problem, a latency problem, or a deadline. The cost surfaces later, after the architecture is set, which is exactly when it's hardest to change.