AWS costs: Cross-AZ traffic - the invisible cent per gigabyte

Cross-AZ data transfer costs $0.01 per GB in each direction inside the same AWS region — so a single gigabyte that crosses an Availability Zone boundary and comes back actually bills you twice, once on the way out and once on the way in. That is the whole answer. The part almost nobody accounts for is the reveal: the Availability Zone your account calls "us-east-1a" is not necessarily the same physical building as the "us-east-1a" in your colleague's account, or in the account running your shared NAT gateway. Two teams can swear their resources are "in the same AZ," both be telling the truth from inside their own account, and still get charged for crossing a zone boundary neither of them can see.

Jake found this one the hard way. He runs a small phone shop, and last year he had a part-time developer set up a simple inventory sync between two EC2 instances "for redundancy." The developer put one instance in each Availability Zone, called it a day, and left. Eight months later Jake's AWS bill had a $340 line item he couldn't explain, buried under a service code that just said "EC2-Other."

"I didn't buy anything called EC2-Other," Jake said. "I don't even know what that is."

What "cross-AZ data transfer" actually means

An AWS Region — something like US East (N. Virginia) or Europe (Ireland) — is made of several Availability Zones. Each Availability Zone is a cluster of one or more physically separate data centers, with independent power, cooling, and networking, connected to the other AZs in the region by high-speed private links. That separation is what makes an AZ-spanning architecture resilient: if a fire or a power failure takes out one AZ, resources in the others keep running.

The trade-off is that the private links between AZs are metered. Any byte your resources send across that boundary — an EC2 instance in one AZ talking to an EC2 instance, an RDS database, a container, or a network interface in another AZ within the same region — is billed as regional data transfer. This is distinct from traffic that stays inside one AZ (usually free) and from traffic that crosses into a different region entirely (a separate, and generally pricier, category).

Ethan's short version

"Think of each AZ as its own building on a campus," Ethan told Jake. "Walking around inside one building is free. Walking to the building next door costs you a toll both ways — once leaving your building, once entering theirs. It doesn't matter that they're on the same campus. It doesn't matter that the walk takes ten seconds. You pay the toll per pound of stuff you're carrying, and most people never notice they're crossing that line until the bill shows up."

Jake pushed back: "So every single request between my two servers costs money, forever, just because someone decided to put them in different buildings?"

"Yes," Ethan said. "And that's not a bug. Multi-AZ is what keeps your shop's point-of-sale system running when one data center has a bad day. You're not being charged for a mistake. You're being charged for insurance you may or may not need at that scale."

The exact price, with no hand-waving

Cross-AZ traffic in the same AWS Region is billed at $0.01 per GB for data leaving the sending resource, and $0.01 per GB for data arriving at the receiving resource. That is a symmetric charge — both sides of the connection pay, which is why the effective round-trip cost is $0.02 per GB, not $0.01. This rate is the same across all AWS commercial regions and applies whether the traffic moves over private IP addresses, public IP addresses, or a VPC peering connection that stays inside one region.

Here is the rate card that actually matters for a typical multi-AZ architecture:

Notice that VPC peering doesn't change the price of crossing an AZ — it just gives you a private path between two VPCs. Peering across AZs in the same region still costs $0.01/GB each way. People sometimes set up peering hoping it will be cheaper than "regular" cross-AZ traffic. It isn't. It's the identical rate.

The catch almost nobody accounts for: your "AZ" isn't the same AZ

Here's the counterintuitive part, and it's the reason so many cross-AZ bills get discovered by accident instead of by design. AWS maps the physical Availability Zones to the names you see — us-east-1a, us-east-1b, and so on — independently and, for accounts created before November 2025, randomly for each AWS account. That means the Availability Zone named "us-east-1a" in your account can be a completely different physical data center from "us-east-1a" in another account, even though both names look identical.

This matters constantly in shared environments: a shared services account running a NAT gateway, a queue, or a cache in one AZ name, and an application account launching instances into what it thinks is the same AZ. If the two accounts' "us-east-1a" don't line up physically, every byte that crosses between them is cross-AZ traffic, billed at $0.01/GB each way, and nothing in either account's console will flag it as unusual — both dashboards genuinely say "same AZ."

AWS's fix for this is the Availability Zone ID, a static identifier like use1-az1 that always points to the same physical location, no matter which account is looking at it. If you're sharing resources across accounts — through AWS Resource Access Manager, a shared VPC, or just two teams comparing notes — the AZ ID, not the AZ name, is the only reliable way to confirm two resources are actually co-located.

To be fair to accounts created going forward: AWS began mapping Availability Zone names consistently across newly created accounts starting in November 2025. If every account involved was created after that point, the "us-east-1a" mismatch problem doesn't apply to them. For anything older, or for any environment mixing older and newer accounts, checking the AZ ID is still the only sure thing.

What's actually free

It's worth being precise here, because "free" gets used loosely in a lot of cost-cutting advice, and an imprecise "free" is how people accidentally build an architecture that still bills them.

Genuinely free, according to AWS's own pricing pages:

• Traffic between resources in the same Availability Zone, over private IP addresses.
• Data transfer between an RDS primary instance and its Multi-AZ standby, for the replication itself — this is explicitly called out as not charged, separate from any other traffic the instance sends.
• Inter-AZ data transfer through AWS PrivateLink VPC interface endpoints, AWS Transit Gateway, and AWS Client VPN, since April 1, 2022.
• Traffic through a VPC Gateway Endpoint to Amazon S3 or Amazon DynamoDB — no hourly charge, no per-GB processing charge for the endpoint itself.
• Cross-zone traffic for an Application Load Balancer or a Classic Load Balancer, because cross-zone load balancing on those two is either always on (ALB) or not billed as a separate regional data transfer charge (Classic).

What's not free, and why it surprises people

Every one of these is a normal, common architecture pattern — none of them are mistakes on their own. They're just charged, and the charge is easy to overlook because it's small per request and enormous in aggregate.

EC2 instance to EC2 instance, different AZ

Application servers in one AZ calling application servers, caches, or microservices in another AZ within the same VPC pay $0.01/GB in each direction. This is the single most common source of the charge, because it happens automatically in any load-balanced or service-mesh architecture that spreads instances across AZs for resilience.

EC2 to RDS, different AZ

If an application server connects to an RDS instance sitting in a different AZ than the server itself, that connection is charged the standard regional data transfer rate on the EC2 side, in and out. This is separate from — and often confused with — Multi-AZ replication traffic, which stays free. The charge here is for your application's actual queries and responses, not for keeping the standby in sync.

VPC peering across AZs

As covered above, peering doesn't get you a discount. If the peered VPCs' resources sit in different AZs, the connection is billed at the same $0.01/GB each-way rate as any other cross-AZ traffic.

NAT Gateway to an instance in a different AZ

A NAT gateway lives in one specific AZ (unless you're using the newer regional NAT gateway option, which runs one gateway per AZ). If an EC2 instance in a different AZ routes through that NAT gateway, you pay the cross-AZ data transfer charge for the hop between the instance and the gateway, on top of the NAT gateway's own $0.045/GB processing fee. This is a genuinely easy trap: teams often provision one NAT gateway to save money, not realizing that "saving money" on the NAT gateway's hourly charge can cost more in cross-AZ transfer than a NAT gateway per AZ would have.

Load balancers: three different billing rules for the same feature

Cross-zone load balancing is the setting that decides whether a load balancer node in AZ A can send a request to a target in AZ B. Whether that costs you anything depends entirely on which load balancer type you're running, and this is one of the more genuinely confusing corners of AWS pricing because the four load balancer types don't agree with each other.

The practical takeaway: if you're running an ALB, you don't need to think about this at all — cross-zone distribution is free and cannot be turned off. If you're running an NLB or a Gateway Load Balancer and you flip on cross-zone load balancing for better distribution across targets, you are opting into regional data transfer charges for whatever traffic actually crosses a zone as a result. For NLB target groups specifically, you can even set the behavior per target group rather than only at the load balancer level, which lets you enable it selectively where the resilience is worth the cost and leave it off elsewhere.

RDS Multi-AZ: the one place replication doesn't cost you

This deserves its own section because it's the opposite of the pattern everywhere else in this article, and getting it wrong in either direction costs you either money or peace of mind.

When you enable Multi-AZ for an RDS instance, AWS creates a standby replica in a different Availability Zone and keeps it synchronized. That synchronization traffic — the actual replication between primary and standby — is not billed as data transfer. AWS states this plainly: you are not charged for the data transfer incurred in replicating data between your primary and standby.

What is billed the normal way is everything else: your application's queries and responses, if your EC2 instances sit in a different AZ than the RDS primary. Failover to the standby doesn't change this rule — whichever instance is currently acting as primary follows the same "same-AZ is free, cross-AZ is $0.01/GB each way" logic relative to whatever's talking to it.

Why this matters for co-location

If cost is a real concern and your application can tolerate the (small) added risk, keeping your application servers in the same AZ as the current RDS primary eliminates the cross-AZ data transfer charge for your database traffic entirely, while the Multi-AZ standby keeps doing its job for free in the background. The trade-off is that after a failover, your app servers are no longer co-located with the new primary until you rebalance them — something worth planning for rather than discovering during an incident.

Containers and Kubernetes: where cross-AZ cost hides at scale

Everything above is manageable when you have a handful of long-lived EC2 instances and you can just look at where they live. It gets much harder once workloads run as containers, because a scheduler — not a human — decides which node a pod or task lands on, and by default most schedulers optimize for balanced load, not for keeping chatty services in the same AZ.

In Amazon EKS, node zone placement is exposed through the standard Kubernetes topology.kubernetes.io/zone label, which EKS populates automatically on each node. Two Kubernetes-native tools build on that label to cut cross-AZ traffic without changing your application code: topologySpreadConstraints, which controls how evenly your pods are spread across zones in the first place, and Kubernetes Service Traffic Distribution set to PreferClose, which tells a Service to route requests to an endpoint in the same zone as the caller whenever one is healthy and available, falling back across zones only when it has to.

Amazon ECS took a similar idea further in July 2026, when zone-aware routing shipped for ECS Service Connect. It's on by default for new and existing services — existing services just need a one-time redeployment to pick it up — and it works by having the built-in Envoy proxy preferentially route service-to-service calls to healthy endpoints in the caller's own AZ, rebalancing automatically as tasks scale up or down. No application code changes, no extra infrastructure.

For diagnosing an existing cluster rather than a new one, AWS's own EKS cost-optimization guidance includes a script for checking pod distribution across AZs and flagging services that would benefit from zone-aware routing, alongside a sample Service manifest configured to keep traffic in-zone. That's a good starting point before assuming you need to rearchitect anything — often the fix is a Service annotation, not a redesign.

Where this charge is hiding on your bill right now

Cross-AZ traffic doesn't show up as a line item called "cross-AZ traffic." It shows up under a usage type code, and if you don't know what to search for, it's easy to see the charge and assume it's something else entirely, the way Jake did with his mystery "EC2-Other" line.

Data transfer between Availability Zones in the same AWS Region carries the usage type Region-DataTransfer-Regional-Bytes, prefixed with the region code — for example, USE2-DataTransfer-Regional-Bytes for US East (Ohio). For any single resource generating this traffic, you'll see two line items, since both the inbound and outbound sides of the same transfer are billed and reported separately.

1. Open Cost Explorer in the AWS Billing and Cost Management console.
2. Group by Usage Type and, if you want to narrow it to one region, also group or filter by Region.
3. Search or filter for entries containing "DataTransfer-Regional-Bytes." This is your cross-AZ traffic.
4. Group by Service in a second view to see which service is generating most of it — most EC2-driven cross-AZ traffic shows up under the "EC2-Other" service line, which is exactly why it's so easy to mistake for something unrelated to networking.
5. For resource-level detail, set up an AWS Cost and Usage Report (CUR). Cost Explorer can tell you the total and which service is responsible; the CUR can tell you which specific resource ID generated the outbound side of the traffic (the inbound side is harder to trace to a specific source, since AWS's billing data shows which resource received the traffic, not which one sent it).

One more wrinkle worth knowing if you're specifically tracking VPC peering costs: as of April 2025, intra-region VPC peering charges moved to their own usage type names, like USE1-VpcPeering-In-Bytes and USE1-VpcPeering-Out-Bytes, separate from the general DataTransfer-Regional-Bytes bucket where they used to live. If you're comparing a bill from before that change to one after it, the peering-specific charges will look like they vanished from the general regional-bytes total — they didn't, they just moved to a more specific label.

Automating detection so you don't have to go looking

Cost Explorer tells you the total and the service responsible. It doesn't tell you which specific instance, pod, or ENI is generating the traffic. For that, you need VPC Flow Logs configured with a custom format that includes the AZ ID field, since the default flow log format doesn't include it.

Once a flow log is capturing the az-id field, you can publish it to CloudWatch Logs or to an S3 bucket for querying with Amazon Athena, then run a query that filters for flows where the AZ ID doesn't match the AZ ID of the network interface recording it, and sums the bytes by source and destination address. That surfaces the specific IP pairs generating the most cross-AZ traffic, which is usually enough to identify the exact service responsible without guesswork.

For the ongoing "make sure this doesn't creep back up" part, AWS Cost Anomaly Detection can watch your spend using machine learning and alert you when a service's cost deviates from its normal pattern, including when a spike is driven by a specific usage type. You can set up a monitor scoped to a service, a linked account, or a cost allocation tag, and route alerts to email, Amazon SNS, or a chat tool like Slack or Microsoft Teams through AWS User Notifications. It's the natural next step after fixing the immediate charge: rather than checking Cost Explorer manually every month, let an anomaly detector tell you the moment cross-AZ traffic jumps again.

AWS-native tools versus third-party cost platforms

It's worth being honest about the trade-off here rather than pretending one path is obviously right. AWS's own tools — Cost Explorer, the CUR, VPC Flow Logs, Cost Anomaly Detection — give you the complete, authoritative data, at no extra cost beyond what you're already paying for logging and storage. The trade-off is that you're the one writing the queries and building the dashboards; there's no pre-built "top cross-AZ contributors" view waiting for you.

Third-party FinOps and observability platforms typically ingest your CUR data and pre-build exactly that kind of dashboard, saving the query-writing step. The trade-off there is a subscription cost and handing a vendor read access to your billing data, which is a real consideration for any organization with sensitivity around what its infrastructure spend reveals about its scale and architecture. For a single team chasing down one unexplained charge, the native tools above are usually enough. For an organization tracking this continuously across dozens of accounts, the time saved by a pre-built platform can be worth the trade-off — it depends on how often you'll actually look.

Before you hand flow logs or billing data to another team

Diagnosing cross-AZ traffic often means sharing flow log data or CUR reports with someone outside your immediate team — a shared services group, a finance analyst, an outside consultant. Two things are worth checking before you do.

First, flow logs and the CUR both contain private IP addresses, resource IDs, and traffic volumes that can reveal the shape of your internal architecture — which services talk to which, how much traffic moves between them, and roughly how large each component is. That's not sensitive in the way customer data is, but it's still internal detail worth limiting to people who need it for the specific investigation at hand, rather than granting standing access to a whole billing bucket.

Second, if you're granting access via IAM rather than just exporting a CSV, scope the permissions to what's actually needed — read access to Cost Explorer or a specific CUR export location — rather than broader billing permissions that happen to include the data someone's asking for. It's a five-minute check that avoids leaving a wider door open than the investigation required.

How to actually stop paying for it

None of these are exotic. They're ordinary architecture decisions, applied deliberately instead of by accident.

1. Co-locate chatty resources. If two services exchange a lot of traffic and don't independently need cross-AZ resilience, put them in the same AZ. This is the single biggest lever, cheapest to do, and easiest to overlook.
2. Verify AZ IDs, not AZ names, across accounts. Before assuming a shared NAT gateway, cache, or queue is "same AZ" as your application, compare AZ IDs. A name match across accounts is not proof.
3. Route AZ-crossing traffic through PrivateLink, Transit Gateway, or Client VPN where it fits the architecture. Those three specifically dropped their inter-AZ charge in 2022; a plain EC2-to-EC2 hop or a VPC peering connection did not.
4. Use VPC Gateway Endpoints for S3 and DynamoDB traffic instead of routing it through a NAT gateway. It sidesteps both the NAT processing fee and any cross-AZ hop to reach the NAT gateway, at no additional charge for the endpoint itself.
5. Run one NAT gateway per AZ if you're relying on NAT for outbound traffic at any real volume. The extra NAT gateway's hourly charge is often smaller than the cross-AZ transfer charge you'd otherwise pay routing every other AZ's traffic through a single gateway.
6. Prefer Application Load Balancer where the workload fits, since its cross-zone distribution is free by design. If you specifically need Network Load Balancer's performance characteristics, decide cross-zone load balancing per target group rather than turning it on everywhere by habit.
7. Keep application servers in the same AZ as the current RDS primary where the added risk after a failover is acceptable, and rebalance after failover events rather than leaving it to chance.
8. Turn on zone-aware routing for ECS Service Connect, or configure topology spread constraints and PreferClose Traffic Distribution for EKS, so container placement doesn't undo everything else on this list without anyone noticing.
9. Set up a Cost Anomaly Detection monitor once you've fixed the current problem, so the next unexpected spike gets caught in days instead of eight months.

When paying for cross-AZ traffic is the right call

None of this is an argument for collapsing everything into one AZ. It's an argument for knowing what you're paying for.

Jake asked Ethan the obvious follow-up: "If it's this annoying, why not just put everything in one Availability Zone and skip the charge completely?"

"Because then one bad day at one data center takes your whole shop offline," Ethan said. "For a lot of small setups, $0.02 a gigabyte is genuinely cheap insurance. The problem was never that your developer used two AZs. The problem was that nobody looked at what it was doing to the bill, and nobody checked whether 'same AZ' between two accounts actually meant the same building."

The honest framing: pay for cross-AZ traffic where the resilience is worth it to your business — a customer-facing database, a payment path, anything where an AZ outage would actually hurt. Don't pay for it by accident on internal batch jobs, logging pipelines, or chatty services that never needed to be split across zones in the first place.

Common mistakes that quietly rack up the bill

Assuming "in the same VPC" means "in the same AZ." A VPC spans an entire region. Two subnets in the same VPC can easily sit in different AZs, and nothing about being in the same VPC changes the cross-AZ billing rule.

Assuming peering is a cost-saving move. As covered above, VPC peering doesn't discount cross-AZ traffic. It's a private routing path, not a pricing tier.

Trusting AZ names across shared accounts without checking AZ IDs. This is the single most common source of "invisible" cross-AZ charges in multi-account setups, precisely because both sides of the connection look correctly configured from where they're standing.

Letting a container scheduler place chatty services with no zone awareness. Without topology spread constraints, PreferClose Traffic Distribution, or zone-aware Service Connect routing, a scheduler optimizing purely for balanced load can scatter two services that talk constantly across every AZ in the cluster, generating cross-AZ traffic that has nothing to do with any deliberate architecture decision — it's simply where the scheduler happened to place things.

Confusing NAT Gateway processing charges with cross-AZ transfer charges. They're two separate line items that often appear together. Fixing one doesn't automatically fix the other, and a bill reduction after fixing NAT placement can hide the fact that the underlying cross-AZ pattern is still there.

Treating this as a one-time cleanup instead of an ongoing check. Architectures change, teams add new services, and a container scheduler's placement decisions shift over time. Without a Cost Anomaly Detection monitor or a periodic Cost Explorer check, a fixed problem can quietly reappear.

Cross-AZ data transfer: the questions people actually ask

What is cross-AZ data transfer in AWS?

It's data that moves between two Availability Zones inside the same AWS Region, such as an EC2 instance in one AZ sending traffic to a database or another instance in a different AZ. It is billed separately from same-AZ traffic and from traffic that crosses into a different region.

How much does cross-AZ data transfer cost?

$0.01 per GB for the outbound side and $0.01 per GB for the inbound side, for an effective $0.02 per GB round trip. This rate is consistent across AWS commercial regions.

Is data transfer within the same Availability Zone free?

Yes, as long as it's over a private IP address. Traffic within the same AZ using a public or Elastic IP address is billed at the same $0.01/GB rate as cross-AZ traffic, so private IP addressing matters here.

Why am I seeing charges even though my instances look like they're in the same AZ?

Three common causes: the traffic is using public or Elastic IP addresses instead of private IPs; the resources are actually in different AZs because they're in different AWS accounts and the AZ names don't map to the same physical location across accounts; or, in a containerized environment, the scheduler placed a pod or task in a different zone than the service it's calling most.

What is DataTransfer-Regional-Bytes on my AWS bill?

It's the usage type AWS assigns to data transfer between Availability Zones in the same region, usually prefixed with the region code, such as USE2-DataTransfer-Regional-Bytes. You'll typically see two line items per resource: one for outbound and one for inbound.

Is Multi-AZ RDS replication free?

Yes. AWS does not charge for the data transfer involved in replicating between an RDS primary instance and its Multi-AZ standby. Ordinary query traffic to and from the instance is billed normally, separate from this replication.

Does enabling cross-zone load balancing cost money?

It depends on the load balancer type. For Network Load Balancer and Gateway Load Balancer, enabling cross-zone load balancing means standard regional data transfer rates apply to traffic that crosses a zone as a result. For Application Load Balancer and Classic Load Balancer, it does not add this charge.

Is Application Load Balancer cross-zone traffic free?

Yes. Cross-zone load balancing is always on for ALB and cannot be disabled, and AWS does not charge separately for the regional data transfer this generates.

Why is Network Load Balancer cross-zone traffic charged when Application Load Balancer's isn't?

NLB and Gateway Load Balancer treat cross-zone distribution as an optional feature that is billed as regional data transfer when enabled. ALB includes cross-zone distribution as a core part of how it works, and that traffic is not billed as a separate line item.

Are Availability Zone names the same across every AWS account?

Not necessarily. For accounts created before November 2025, AWS mapped AZ names to physical locations independently and randomly per account, so the same AZ name can point to different physical data centers in different accounts. Accounts created from November 2025 onward get consistent AZ name mapping.

What is an AZ ID and why does it matter?

An AZ ID, such as use1-az1, is a static identifier that always represents the same physical Availability Zone regardless of which AWS account is looking at it. It's the only reliable way to confirm two resources in different accounts are physically co-located.

Is AWS PrivateLink traffic between Availability Zones free?

Yes, since April 1, 2022. Inter-AZ data transfer for AWS PrivateLink VPC interface endpoints, AWS Transit Gateway, and AWS Client VPN is free, though the endpoints themselves still carry their own hourly and per-GB processing charges.

How do I find cross-AZ charges in AWS Cost Explorer?

Group your costs by Usage Type and look for entries containing DataTransfer-Regional-Bytes. Grouping by Service at the same time usually shows this traffic filed under EC2-Other. For resource-level detail, use VPC Flow Logs configured with the AZ ID field, or the AWS Cost and Usage Report.

Does using a NAT Gateway avoid cross-AZ charges?

Not by itself. A NAT gateway lives in one specific AZ, and instances in a different AZ routing through it pay the cross-AZ data transfer charge for that hop, on top of the NAT gateway's own per-GB data processing fee. Running one NAT gateway per AZ avoids the cross-AZ hop for that traffic.

Do VPC Gateway Endpoints for S3 and DynamoDB reduce cross-AZ costs?

They can help, since Gateway Endpoint traffic to S3 or DynamoDB carries no hourly or per-GB endpoint charge, and routing that traffic through the endpoint instead of a NAT gateway avoids the NAT processing fee and any cross-AZ hop needed to reach the gateway.

Should I avoid cross-AZ traffic entirely for the sake of high availability?

No. Reserve multi-AZ spread for the parts of a system where an Availability Zone outage would genuinely hurt, and keep chatty, non-critical traffic co-located in one AZ, or routed through zone-aware container networking, where the resilience isn't worth the per-gigabyte cost.

Also Read:

AWS costs: The NAT gateway bill - the $32/month nobody planned

 AWS costs: Data transfer pricing - the map of what is free and what is not

 AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app

 AWS costs: Cross-AZ traffic - the invisible cent per gigabyte

 AWS costs: Unattached Elastic IPs and idle load balancers - the standing waste list

AWS costs: S3 request pricing - when storage is cheap but touching it is not

AWS costs: S3 storage classes decided honestly - IA, Glacier, Intelligent-Tiering

AWS costs: Glacier retrieval - the bill for wanting your data back

Revision note. Written September 2026, covering current AWS EC2, VPC, RDS, Elastic Load Balancing, ECS, and EKS pricing and networking behavior, and the Availability Zone ID mapping rules in effect as of this writing. This will need a revisit if AWS changes cross-AZ or load balancer data transfer rates, extends consistent AZ-name mapping to accounts created before November 2025, or expands zone-aware routing to more services. If you've been staring at an unexplained "EC2-Other" charge, you're not missing something obvious — this really is one of the least visible line items on the whole bill, and now you know exactly where to look.