awsnetworkingcost-optimizationdata-transfer

Inter-AZ data transfer cost: the charge hiding inside your VPC

Traffic between availability zones inside the same region is not free. At roughly a cent per GB in each direction, cross-AZ transfer quietly adds up for chatty microservices, replicated databases, and Kafka clusters. Here is how it is billed and how to cut it.

The C3X Team··5 min read

Quick answer

Data transfer between availability zones in the same AWS region is billed at about a cent per GB in each direction, so a round trip costs roughly two cents per GB. It applies to traffic that crosses AZ boundaries even inside one VPC, so chatty microservices, cross-AZ database replication, and replicated streaming clusters all incur it. Same-AZ traffic using private IPs is free. Cut the cost by keeping request paths within an AZ (topology-aware routing), compressing payloads, and being deliberate about which workloads truly need multi-AZ chatter.

Most teams assume traffic inside a single VPC is free. It is not. AWS charges for data that crosses availability zone boundaries, even when both endpoints are in the same region and the same VPC, at roughly a cent per GB in each direction. For a highly available architecture that deliberately spreads workloads across AZs, this cross-AZ chatter becomes a real line item that rarely shows up until you read the bill carefully.

How inter-AZ transfer is billed

Traffic pathApproximate cost
Same AZ, private IPFree
Cross-AZ, same region (out)About a cent per GB
Cross-AZ, same region (in)About a cent per GB
Cross-AZ round tripAbout two cents per GB total

The key detail is that cross-AZ transfer is charged on both the sending and receiving side, so a request and its response that cross a zone boundary are billed twice. A gigabyte of chatter between two services in different AZs therefore costs about two cents once you count both directions. That sounds trivial until a busy service pushes terabytes a day, and it compounds with the other hidden AWS costs that live in the networking part of the bill.

Where it adds up

Three patterns dominate cross-AZ spend. Chatty microservices that fan out many small calls per request pay the round-trip charge on every hop that lands in another zone. Databases replicating synchronously across AZs for durability push their entire write volume over paid links. Streaming systems like Kafka replicate every message to brokers in other zones, which is why Kafka versus Kinesis cost comparisons have to account for replication traffic. In each case the cost scales with volume, not with the number of resources.

How to reduce it

Keep request paths within a single AZ where you can. Topology-aware routing (available in modern Kubernetes and service meshes) prefers a same-AZ endpoint before crossing a zone, which turns most internal calls back into free traffic. Compress payloads so each byte carries more, since the charge is purely per GB. Batch small messages instead of chattering. And be honest about which workloads genuinely need synchronous multi-AZ replication versus which can tolerate a single-AZ hot path with asynchronous backups. This overlaps with the broader egress cost reduction checklist, since the same discipline that trims internet egress also trims internal transfer.

Weighing it against availability

Cross-AZ transfer exists because you chose resilience: spreading across zones protects you when one zone fails. So the goal is not to eliminate it but to avoid paying for chatter that buys no resilience. A stateless service that fans out randomly across AZs pays the charge for nothing, while a database replicating writes across zones pays it for real durability. Attribute the cost to the workloads causing it, fold it into your FinOps KPIs, and optimize the chatter that is pure overhead. Cross-AZ cost is a tax on network topology, and topology is something you can design.

FAQ

How much does inter-AZ data transfer cost on AWS?

Roughly a cent per GB in each direction for traffic that crosses availability zone boundaries within the same region. Because it is charged on both the sending and receiving side, a cross-AZ round trip costs about two cents per GB in total. Same-AZ traffic using private IP addresses is free, so only the traffic that actually crosses a zone boundary is billed.

Is data transfer inside a VPC free?

Only when it stays within one availability zone using private IP addresses. Traffic that crosses AZ boundaries inside the same VPC still incurs the cross-AZ charge of about a cent per GB each way. So a single VPC spread across multiple AZs for high availability will accumulate inter-AZ transfer cost on any traffic that hops between zones.

Why is my cross-AZ transfer bill so high?

Usually chatty microservices, synchronous database replication, or streaming clusters. Microservices that fan out many small calls pay the round-trip charge on every hop landing in another zone; databases replicating writes across AZs push all write volume over paid links; and systems like Kafka replicate every message to brokers in other zones. The cost scales with data volume, so busy services pushing terabytes add up fast.

How do I reduce inter-AZ data transfer cost?

Keep request paths within a single AZ using topology-aware routing that prefers a same-AZ endpoint before crossing a zone, compress payloads since the charge is per GB, batch small messages instead of chattering, and reserve synchronous multi-AZ replication for workloads that genuinely need the durability. The same discipline in an egress reduction checklist also trims internal transfer.

Does keeping traffic in one AZ hurt availability?

It can if taken too far, since spreading across zones is what protects you when a zone fails. The goal is to avoid paying for chatter that buys no resilience, not to collapse everything into one AZ. A stateless service fanning out randomly across zones pays the charge for nothing, while a database replicating writes pays it for real durability. Optimize the overhead, keep the resilience.

Does C3X show inter-AZ transfer cost before deploy?

C3X prices infrastructure from your Terraform against a live pricing catalog before deploy, so the resources and configuration that drive cross-AZ transfer (multi-AZ databases, replicated clusters, subnet placement) are visible in the pull request. That helps you see the architectural choices that create cross-AZ chatter while you can still adjust the topology cheaply.

What to do next

See the networking cost of your topology before you ship it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.

Try C3X on your own Terraform

Free and open source. No API key required. One command to install, one command to estimate.