TL;DR:
- AWS charges $0.01 per GB for cross-AZ data transfer within the same region, totaling $0.02 for round-trip traffic. Many default configurations, like kube-proxy and load balancers, generate unintended inter-AZ traffic that increases costs without deliberate planning. Using AZ-aware routing, per-AZ NAT gateways, and detailed monitoring tools helps reduce accidental cross-AZ data charges effectively.
AWS inter-AZ data transfer costs are charged at $0.01 per GB in each direction for data crossing Availability Zone boundaries within the same AWS region, producing a $0.02 per GB round-trip fee. That rate is stable across all regions in 2026. For architects running high-throughput workloads, microservices, or multi-AZ Kubernetes clusters, this charge compounds fast. Understanding exactly when AWS bills for cross-AZ traffic, and when it does not, is the foundation of any serious AWS cost reduction strategy.
What triggers AWS inter-AZ data transfer charges?
AWS charges for data transfer the moment traffic crosses an Availability Zone boundary within the same region. The fee applies in both directions: $0.01/GB leaving one AZ and $0.01/GB arriving at another. That bidirectional structure means every round-trip request costs $0.02/GB total.
Several conditions determine whether a transfer is free or billed:
- Same AZ, private IP: Free. Traffic between two EC2 instances using private IPs within the same AZ incurs no charge.
- Same AZ, public or Elastic IP: Charged at $0.01/GB each direction, even though the instances sit in the same zone. This misconfiguration is one of the most common sources of unexpected bills.
- Cross-AZ, any IP type: Always charged at $0.01/GB per direction.
- Inbound from the internet: Free. AWS does not charge for data coming into its network from external sources.
- S3 to EC2 in the same region: Free, regardless of AZ placement.
- Multi-AZ RDS synchronous replication: Free between primary and standby. Cross-region read replica replication, however, is billed at standard inter-region rates.
NAT Gateway adds a separate layer of cost. AWS charges $0.045 per GB for data processed through a NAT Gateway, on top of any inter-AZ transfer fees. If your EC2 instance in AZ-A routes outbound traffic through a NAT Gateway sitting in AZ-B, you pay both the $0.01/GB cross-AZ fee and the $0.045/GB NAT processing fee. That combination reaches $0.055/GB in one direction alone.
Pro Tip: Always confirm that application-level health checks, service discovery, and load balancer target registration use private IPs. Switching from Elastic IPs to private IPs within the same AZ eliminates a charge that many teams never notice until the bill arrives.
VPC peering does not exempt traffic from inter-AZ charges. Traffic between peered VPCs crossing AZ boundaries still incurs the standard $0.01/GB per direction fee.
How does AWS cross-AZ pricing work in common architectural patterns?
Running this on your own AWS setup? IT-Magic is an AWS Advanced Tier Partner — we audit, fix, or fully manage it for you.
Get a free consultationThe $0.01/GB per direction rate looks small in isolation. At scale, it does not stay small.
Cost at different traffic volumes
| Daily cross-AZ traffic | Monthly volume | Monthly cost (one direction) | Round-trip monthly cost |
|---|---|---|---|
| 10 GB/day | 300 GB | $3.00 | $6.00 |
| 100 GB/day | 3,000 GB | $30.00 | $60.00 |
| 1,000 GB/day | 30,000 GB | $300.00 | $600.00 |
| 43,000 GB/day | 1,290,000 GB | $12,900.00 | $25,800.00 |
The 43 TB/day row is not hypothetical. A 2026 case study showed a high-volume read-heavy workload at that scale cutting $12,000/month in inter-AZ fees by 95% through AZ-affinity caching strategies. The latency dropped 49% as a side effect.
Service-specific cost patterns
EC2 to EC2: Direct instance communication across AZs bills at $0.01/GB each way. A three-tier application where the web layer sits in AZ-A and the database replica sits in AZ-B pays this fee on every query response.
EKS pod traffic: Kubernetes default routing does not respect AZ boundaries. A pod in AZ-A can freely call a pod in AZ-C, and AWS bills for every byte that crosses. In a busy microservices cluster, this traffic is largely invisible until you look at VPC Flow Logs.
NAT Gateway: Deploying a single NAT Gateway per region rather than per AZ is a common cost trap. Traffic from instances in AZ-B crossing to a NAT Gateway in AZ-A pays both the inter-AZ fee and the NAT processing fee. Deploying one NAT Gateway per AZ eliminates the cross-AZ leg entirely.
Network Load Balancer: Cross-zone load balancing on an NLB charges $0.01/GB each way for traffic distributed across AZs. Enabling zonal affinity keeps client traffic within the originating AZ and removes that charge.
Pro Tip: Use the AWS Pricing Calculator to model your specific traffic patterns before committing to a multi-AZ architecture. Plug in realistic GB/day estimates for each service boundary, not just peak numbers.
What are the hidden costs and misconceptions about inter-AZ data fees?
The most expensive misconception in AWS networking is that private IP traffic is always free. Private IP traffic is only free within the same AZ. The moment that traffic crosses a zone boundary, AWS bills for it at the standard rate, regardless of whether you use private or public IPs.
Several other hidden cost sources catch architects off guard:
- Kubernetes default behavior: Without explicit topology configuration, kube-proxy routes requests to any healthy pod regardless of AZ. A cluster with 30 pods spread across three AZs will generate substantial cross-AZ traffic on every service call.
- Cross-zone load balancing enabled by default: Application Load Balancers enable cross-zone load balancing by default. Network Load Balancers charge for it explicitly. Many teams leave the default on without realizing it generates inter-AZ data fees.
- NAT Gateway placement: A single shared NAT Gateway in one AZ forces all outbound traffic from other AZs to cross zone boundaries before reaching the internet.
- Monitoring blind spots: AWS Budgets alerts carry an 8–12 hour delay for data transfer costs. By the time an alert fires, a misconfigured deployment may have already run for hours.
Without fine-grained visibility tools, data transfer costs grow invisibly, hidden inside aggregate network charges. VPC Flow Logs and EKS Container Network Observability provide the per-AZ breakdown needed to isolate cost drivers before they compound. Proactive monitoring is not optional for teams running high-throughput workloads across multiple zones.
AWS Cost Explorer shows data transfer charges at the service level, but it does not automatically break them down by AZ pair. Getting that granularity requires enabling VPC Flow Logs and querying them through Amazon Athena, or using EKS Container Network Observability for Kubernetes workloads specifically.
How can architects reduce AWS inter-AZ data transfer costs?
Reducing cross-AZ data transfer charges does not require sacrificing availability. The goal is to eliminate accidental cross-AZ traffic while keeping intentional cross-AZ traffic for genuine redundancy.
-
Deploy NAT Gateways per AZ. One NAT Gateway per Availability Zone eliminates the cross-AZ leg for all outbound internet traffic. The hourly cost of an extra NAT Gateway is almost always less than the combined inter-AZ and NAT processing fees it replaces.
-
Enable AZ-affinity on load balancers. For Network Load Balancers, disable cross-zone load balancing or enable zonal affinity. For Application Load Balancers, evaluate whether cross-zone distribution is genuinely needed or just a default left in place.
-
Apply Kubernetes topology-aware routing. Kubernetes 1.35 introduced the
trafficDistribution: PreferSameZonedirective. Setting this on a Service object instructs kube-proxy to prefer pods in the same AZ before routing cross-zone. This reduces inter-AZ pod traffic without removing cross-AZ failover capability. -
Co-locate tightly coupled services. If Service A calls Service B on every request, placing both in the same AZ eliminates the per-call transfer fee. Use node affinity rules in EKS or ECS task placement constraints to enforce co-location.
-
Use VPC endpoints for AWS service traffic. Traffic from EC2 to S3, DynamoDB, or other AWS services that routes through a NAT Gateway pays the NAT processing fee unnecessarily. VPC Gateway Endpoints for S3 and DynamoDB are free and keep traffic on the AWS backbone.
-
Enable VPC Flow Logs and query by AZ. You cannot reduce what you cannot see. Flow Logs with AZ-level tagging, queried through Athena, reveal exactly which service pairs generate the most cross-AZ traffic. Start there before making architectural changes.
-
Audit Elastic IP usage. Replace Elastic IPs with private IPs wherever instances communicate within the same AZ. This single change eliminates a charge that many teams carry for months without realizing it.
Pro Tip: Run a one-week VPC Flow Log analysis before any architecture review. The data almost always reveals two or three traffic patterns generating the majority of inter-AZ charges. Fix those first.
Key Takeaways
AWS inter-AZ data transfer costs are charged at $0.01/GB per direction for every cross-AZ traffic flow, and eliminating accidental cross-AZ traffic through AZ-affinity routing, per-AZ NAT Gateways, and Kubernetes topology directives is the most direct path to reducing these fees.
| Point | Details |
|---|---|
| Base rate is $0.02/GB round trip | AWS charges $0.01/GB in each direction for all cross-AZ traffic within a region. |
| Private IPs are not always free | Private IP traffic is only free within the same AZ; cross-AZ private traffic is billed at standard rates. |
| NAT Gateway doubles the cost | A cross-AZ NAT Gateway adds $0.045/GB on top of the inter-AZ fee, reaching $0.055/GB in one direction. |
| Kubernetes needs explicit AZ affinity | The PreferSameZone directive in Kubernetes 1.35 reduces cross-AZ pod traffic without removing failover. |
| Monitoring requires per-AZ tools | AWS Budgets has 8–12 hour alert delays; VPC Flow Logs and Cost Explorer provide the granularity needed for real-time control. |
The cost you’re paying for traffic you didn’t plan
After working through hundreds of AWS architecture reviews, the pattern I see most often is not reckless spending. It is accidental spending. Teams build a multi-AZ architecture for the right reasons, availability and resilience, and then leave the default routing behaviors in place without realizing those defaults generate continuous cross-AZ traffic.
The Kubernetes case is the clearest example. A team deploys EKS across three AZs, which is correct. They leave kube-proxy on default settings, which routes to any healthy pod. Every service call now has a two-in-three chance of crossing a zone boundary. Nobody made a bad decision. The defaults just were not designed with billing in mind.
The same logic applies to NAT Gateways. Deploying one per region is the path of least resistance. It works. It just costs more than it should when traffic from AZ-B and AZ-C has to cross into AZ-A before reaching the internet.
My honest recommendation: accept the inter-AZ costs that come from genuine redundancy, like Multi-AZ RDS or cross-zone health checks. Eliminate the costs that come from default configurations that nobody consciously chose. That distinction, intentional versus accidental cross-AZ traffic, is where the real savings live. The AWS cost optimization work that delivers the most durable results always starts with visibility, not guesswork.
— Oleksandr
How IT-Magic approaches AWS inter-AZ cost optimization
IT-Magic is an AWS Advanced Tier Services Partner with over 700 projects delivered since 2010. The team specializes in cloud architecture, DevOps, and cost engineering for startups, fintech, and enterprise clients running complex multi-AZ workloads.
For teams dealing with unexplained AWS networking bills, IT-Magic conducts architecture reviews that identify accidental cross-AZ traffic patterns, misconfigured NAT Gateways, and Kubernetes routing defaults that inflate costs. The work covers VPC Flow Log analysis, EKS topology configuration, and load balancer tuning. If your AWS bill has a networking line item that keeps growing without a clear explanation, IT-Magic’s AWS cost optimization services provide the per-AZ visibility and architectural changes needed to bring it under control.
FAQ
What is the AWS inter-AZ data transfer rate in 2026?
AWS charges $0.01 per GB in each direction for data transferred between Availability Zones within the same region. The round-trip cost is $0.02 per GB, and this rate is consistent across all AWS regions in 2026.
Is private IP traffic between AZs free on AWS?
No. Private IP traffic is only free when both instances are in the same Availability Zone. Cross-AZ traffic using private IPs is billed at $0.01/GB per direction, the same rate as public IP traffic.
How does a NAT Gateway affect inter-AZ data transfer charges?
A NAT Gateway adds a $0.045/GB processing fee on top of any inter-AZ transfer costs. If traffic crosses an AZ boundary to reach the NAT Gateway, the combined charge reaches $0.055/GB in one direction. Deploying one NAT Gateway per AZ eliminates the cross-AZ leg.
How can I see which services are generating cross-AZ charges?
Enable VPC Flow Logs and query them through Amazon Athena with AZ-level filtering. For Kubernetes workloads, EKS Container Network Observability provides pod-level inter-AZ traffic breakdowns. AWS Budgets alerts have an 8–12 hour delay, so they are not reliable for real-time detection.
Does Kubernetes automatically keep pod traffic within the same AZ?
No. Kubernetes default routing sends requests to any healthy pod regardless of AZ. Kubernetes 1.35 introduced the trafficDistribution: PreferSameZone directive, which routes traffic to same-AZ pods first while preserving cross-AZ failover when needed.
Recommended
- AWS Cost Optimization: Best Practices, Principles, and Tools
- GPU Instances AWS Cost Optimization: 2026 Guide
- AWS cost reduction strategies: proven steps for cloud savings
- AWS AI Infrastructure: A 2026 Guide for IT Teams
Alexander founded IT-Magic, an AWS Advanced Tier Services Partner delivering DevOps, cloud architecture, and managed services since 2010. He holds:
- AWS Certified Solutions Architect – Professional
- AWS Certified DevOps Engineer – Professional
- AWS Certified Security – Specialty
- AWS Certified Advanced Networking – Specialty
Talk to a certified AWS team trusted by INTERTOP, Foxtrot, Pandora, and J.Hilburn.
Get a free consultation


