The AZ Tax

Executive Summary

Five thousand and thirteen dollars appeared on the March AWS bill and nobody could explain it. Instances were unchanged. Egress to the internet had barely moved. Cost Explorer showed no spike under "Data Transfer" that matched the number. The finance team asked for a breakdown, the infra team dug for a week, and the answer was hiding in plain sight: a 10,000 requests-per-second three-tier app with 10 KB moving in each direction (a 10 KB request and a 10 KB response), ALB enabled across three AZs, generating roughly 250 TB of internal traffic every month, at $0.01 per GB per direction.

Cross-AZ transfer is the only AWS charge that punishes you for following best practice. Multi-AZ deployment is the documented, default-recommended architecture for availability. And that architecture, at production scale, quietly bills you $0.02 for every GB that round-trips between zones. It never appears on the invoice as "cross-AZ." It is folded into EC2-Other and ELB usage types, which is why teams discover it months late, usually by accident, usually after the cost spike gets questioned.

This briefing does three things. It maps the exact boundary between free and paid east-west traffic — including the traps (same-AZ traffic over a public IP is not free). It prices four real architectures with 2026 rates, from a 3-tier app at $5,013/month to a chatty microservice mesh at $6,266/month. And it gives you the decision logic for AZ-affinity routing: where the fix is nearly free, where it is a genuine architectural trade, and where you should stop optimizing and just pay the tax. If you run multi-AZ anything on AWS, run the numbers for your own workload in the Cross-AZ Data Transfer Cost Calculator before you read further — the result is usually uncomfortable.

Why Cross-AZ Charges Don't Show Up As a Line Item

Start with the billing reality, because it explains everything else. AWS publishes the cross-AZ rate in the VPC pricing page and the EC2 data transfer docs. It is $0.01/GB leaving the source AZ and $0.01/GB entering the destination AZ ($0.02/GB round trip). But nowhere on your invoice does a line item say "cross-AZ." The bytes are attributed to the service that moved them: EC2-Other for instance-to-instance traffic, ELB usage types for load balancer cross-zone fan-out, and so on. AWS CUR does expose a regional data-transfer metric (Region-DataTransfer-Regional-Bytes) and Cost Explorer can group by Availability Zone, so the spend is measurable — but billing data alone will not tell you which application flows caused it. That requires network-level analysis.

The practical split is: billing data tells you how much you paid, VPC Flow Logs tell you which flows caused it. Enable Flow Logs (the logs carry an AZ identifier for each ENI), aggregate bytes by source-AZ / destination-AZ pair, and sum the flows where the zones differ. Teams that have not done this — which is most teams — simply do not know the number. You cannot optimize a cost you cannot see, and the reason cross-AZ spend is so consistently overlooked is that the accounting makes it invisible.

Compounding the invisibility is the unit economics. One dollar per 100 GB reads as harmless. A microservice that calls its neighbor in another AZ a few thousand times a second generates real money, but no single request feels expensive. The tax is diffuse: a cent here, a cent there, across every service boundary in every zone pair. Until the month-end total lands like the case above. It is the same psychological pattern as egress: nobody budgets for it, everybody pays it.

The $0.01 + $0.01 Rule: The Free/Paid Boundary Map

The pricing rule is simple. The implementation of it has four traps. Here is the complete boundary map for AWS data transfer inside a region, based on 2026 published rates:

Three traps in that table cause most of the surprise charges. First, same-AZ traffic over a public or Elastic IP is billed even though the instances sit in the same zone. AWS charges by routing path, not by distance, and teams that reference RDS or ElastiCache by public endpoint out of habit pay a tax a private-DNS change eliminates for free. Second, load balancer cross-zone balancing fans requests out to targets in other AZs, billing every byte of that fan-out. Third, Kubernetes routing does not respect AZ boundaries: in EKS, a pod in AZ-A can call a pod in AZ-C with no awareness that it is crossing a billing boundary; the traffic shows up in flow logs, never in the application.

Step back and the pattern is clear: AWS does not price east-west traffic by distance, and it does not price it by generosity. It prices it by product design — the free boundaries (same-AZ private, RDS sync replication, S3 to EC2) are exactly the ones AWS wants you to use, and the paid boundaries (cross-AZ, public IP, cross-region) are the ones it wants you to architect around. Treat the pricing table as a design document, not a tariff list, and most of the surprise charges stop being surprising.

The one genuinely free exception worth celebrating: RDS Multi-AZ synchronous replication within a region is not billed. AWS does not charge for the primary-to-standby replication stream in the same region. The moment you add a cross-region read replica, that stream is billed at inter-region rates. Same region, same service — one free, one not. The boundary map matters at the service level, not just the network level.

Four Architectures, Four Real Bills

Rates are abstract; bills are not. We priced four architectures that cover the realistic range of production east-west traffic, using $0.01/GB per direction, 730 hours per month, and binary GB (1024³). These are the same scenarios built into the Cross-AZ Data Transfer Cost Calculator, so you can reproduce every number and swap in your own traffic.

1. The 3-Tier App: 10K rps × 10 KB → $5,013/month

A three-tier application (ALB enabled across three AZs, with EC2 targets distributed across those zones) doing 10,000 requests per second with 10 KB moving in each direction (a 10 KB request and a 10 KB response). That is 100 MB/s of cross-AZ traffic, or roughly 250 TB per month. At $0.01/GB each way: $5,013/month. Independent estimates using the same workload land at $5,260 — the small gap is the hour-count convention (730 vs 744 hours/month), not a rate disagreement. This is a mainstream production profile, not an edge case.

2. Chatty Microservices: 5K rps × 25 KB → $6,266/month

Microservice meshes are the worst case, because one user request fans out into several internal hops, and each hop that crosses an AZ boundary bills. At 5,000 requests per second with 25 KB per hop in each direction (the chatty pattern: many small JSON exchanges, each hop carrying 25 KB out and 25 KB back), the mesh generates ~313 TB/month of east-west traffic: $6,266/month. And this is before the NAT Gateway stacking problem below; private-subnet microservices often add another layer on top of this number.

3. Public API: 1K rps × 10 KB → $501/month

A single regional API at 1,000 rps with 10 KB in each direction (a modest, well-utilized service) generates ~25 TB/month of cross-AZ traffic: $501/month. Small enough to ignore on its own, large enough to fund a senior engineer. This is the profile where most teams first notice the tax: it is not catastrophic, it is just annoying, and the fix (AZ-affinity) is cheap because the workload is stateless.

4. Database Replicas: 500 GB/day → $300/month

Two different database patterns, two different bills. Cross-region read replicas: 500 GB/day of replication traffic, one way, at ~$0.02/GB (US-US inter-region rate) = 15 TB/month = $300/month. EC2-to-RDS across AZs in the same region: the charge is a standard EC2 regional transfer — $0.01/GB in and $0.01/GB out on the EC2 side, and RDS does not add a second regional transfer on top. Model it as 500 GB/day each direction at $0.01/GB = $300/month as well, but the unit economics differ and it can be removed entirely by co-locating the app and database in the same AZ. Remember the boundary map: Multi-AZ synchronous replication within the region stays free; cross-region read replicas are not; and application queries that hit a replica in another AZ are not either. For analytics workloads that read replicas heavily, the query path can dominate the replication path.

Taken together as illustrative workload profiles, these figures show how a mid-size AWS estate can reach five figures per month in regional data-transfer charges — none of it labeled, all of it folded into EC2-Other and ELB lines. If your team has never audited cross-AZ traffic, the assumption that "internal traffic is free" may be costing you a line item you have never seen.

The Stacking Problem: Cross-AZ Is the Base Layer, Not the Total

The four bills above assume pure private-IP cross-AZ traffic. Real architectures rarely stop there, because every other AWS transfer charge stacks on top of the same bytes. The most common compound:

The NAT Gateway case deserves emphasis because it is the most avoidable. A Lambda or container in a private subnet calling out through a NAT gateway in a different AZ pays $0.01/GB cross-AZ plus $0.045/GB NAT processing — $0.055/GB in one direction alone. Documented incidents show teams racking up $1,000/month of charges on traffic that never left AWS: internal S3 calls routed through NAT because no VPC endpoint existed. The fix (a free Gateway Endpoint for S3/DynamoDB, or one NAT per AZ so traffic never crosses) is a routing-table change, not a redesign.

The pattern to internalize: cross-AZ is the base layer of the east-west tax, and every routing decision on top of it multiplies the bill. An architecture that looks free on paper (private subnets, NAT egress, multi-AZ for resilience) is frequently the most expensive version of itself.

The AZ-Affinity Fix: Where It's Nearly Free, and Where It's a Real Trade

AZ-affinity means routing consumers to dependencies that live in the same Availability Zone, so traffic never crosses the billing boundary. The idea is simple; the engineering cost varies wildly by workload. The honest decision logic, in order of increasing effort:

Level 1: Configuration changes, near-zero effort. For ALB, cross-zone load balancing is enabled by default — disabling it is a console toggle, and the savings are immediate for stateless workloads with capacity in every AZ. For NLB, cross-zone behavior differs (it is disabled by default, and enabling it triggers EC2 data-transfer charges for the cross-AZ fan-out), so the cost decision runs in the opposite direction: leave it off unless you need the failover behavior, and price the transfer before turning it on. Deploy one NAT gateway per AZ so private-subnet traffic never crosses zones to reach egress. Switch same-AZ references from public/Elastic IPs to private hostnames. These are routing-table and console changes that eliminate the tax leg entirely without touching application code. For most web tiers, this is the entire fix.

Level 2: Service discovery and caching, real but bounded effort. For microservice meshes, make service discovery AZ-aware: prefer a healthy instance in the same AZ before failing over to another zone. Add an AZ-local cache layer for read-heavy fan-out. The payoff can be dramatic: according to the cited case study, a 43 TB/day read-heavy workload cut inter-AZ transfer by 95% (~$12,000/month) with AZ-affinity caching, and latency dropped 49% as a side effect because the data was closer. Caching is the rare fix that reduces both the bill and the p99.

Level 3: When you should stop. AZ-affinity has genuine limits. Stateful workloads with strong consistency requirements (primary database in one AZ, failover in another) cannot be affinity-routed; the replica must stay cross-AZ, and the synchronous replication is free anyway, so there is nothing to save. If a single AZ cannot hold your peak capacity, affinity routing means idle capacity in other zones while one zone runs hot, and the savings may not justify the utilization loss. And per-AZ autoscaling adds operational surface: you are now managing N autoscaling groups instead of one. The rule of thumb: if the workload is stateless or read-mostly, affinity is nearly free; if it is stateful or hot-sharded, the tax is the price of resilience — budget for it rather than chasing marginal savings that cost more in engineering time than they return.

Before choosing a level, quantify the prize. Model your request volume and payload sizes in the Cross-AZ calculator and compare against the engineering cost of the change. The tool also pairs with the ALB vs NLB cost engine, since cross-zone balancing decisions and load balancer choice interact directly with the east-west line, and with egress cost modeling if you need the full data-transfer picture.

How To Audit Cross-AZ Costs This Quarter

None of this requires a FinOps platform. A focused afternoon covers it:

1. Enable VPC Flow Logs if you haven't. They are the only data source that can see AZ boundaries. Send them to S3 (cheap) or CloudWatch, then aggregate bytes by source-AZ and destination-AZ pair. Any significant volume where the zones differ is your cross-AZ tax. If flow logs are already on, this query takes minutes.

2. Check the bill for the hidden lines. In Cost Explorer, filter Data Transfer by usage type and look for EC2-Other and ELB data-processing lines that are not explained by egress. These are the buckets where cross-AZ spend hides. The gap between your known egress volume and the EC2-Other transfer total is your east-west tax.

3. Hunt same-AZ public-IP references. Grep your DNS config and service discovery for public hostnames or Elastic IPs used to reach RDS, ElastiCache, or peer EC2 instances. Every one of those is a free boundary you are paying to cross. Private-DNS resolution or VPC endpoints remove the charge.

4. Review load balancer cross-zone settings. If cross-zone balancing is enabled on stateless workloads, test disabling it in a staging account and measure both the transfer delta and the failure behavior. Per-AZ ASGs are the prerequisite; make sure they exist first.

5. Count your NAT gateways. One NAT per region with instances in multiple AZs means cross-AZ traffic to reach egress, paid twice. One NAT per AZ removes the cross-AZ leg. The hourly cost of the extra gateways is usually far below the transfer it eliminates.

Run the numbers before and after in the Cross-AZ Data Transfer Cost Calculator so the audit produces a dollar figure your team can act on; and if you are already deep in load balancer or NAT costs, the LCU Trap and NAT Gateway Trap briefings cover the adjacent line items.

Frequently Asked Questions

Methodology & Disclosure

Rates are AWS published pricing as of August 2026, with US East (N. Virginia) as the pricing region unless otherwise stated: $0.01/GB per direction for cross-AZ transfer within a region (VPC pricing page), $0.045/GB NAT Gateway data processing, tiered egress from $0.09/GB, ~$0.02/GB inter-region (US-US) for read replicas. All cost figures in this briefing use 730 hours per month and binary gigabytes (1024³). The $5,013 figure for the 10K rps workload is computed by the jslet Cross-AZ Data Transfer Cost Calculator; the $5,260 figure cited for comparison uses 744 hours per month; the opening story uses the 730-hour figure. Pricing changes; verify current rates before budgeting. Workload profiles are illustrative composites, not a specific customer account.

References & Further Reading

1. AWS (2026). "Amazon EC2 Data Transfer Pricing." Cross-AZ rate $0.01/GB each direction; tiered egress. aws.amazon.com
2. AWS (2026). "Amazon VPC Pricing." Data transfer within a region, NAT Gateway processing fees. aws.amazon.com
3. AWS (2026). "S3 Storage Classes." Same-region S3-to-EC2 transfer free; cross-region replication billing. aws.amazon.com
4. AWS (2026). "Amazon VPC Flow Logs." Logs carry the AZ identifier of each ENI, enabling per-zone traffic attribution. docs.aws.amazon.com
5. AWS (2026). "AWS Cost and Usage Report." Regional data-transfer metrics (Region-DataTransfer-Regional-Bytes) for identifying same-region AZ transfer spend. docs.aws.amazon.com
6. usage.ai (2026). "AWS Data Transfer Costs: The Complete 2026 Guide." Independent estimate of the 10K rps × 10 KB-per-direction workload at ~$5,260/month; cross-zone load balancing disable guidance. usage.ai
7. itmagic.pro (2026). "AWS Inter-AZ Data Transfer Costs: 2026 Architect's Guide." 43 TB/day case study: AZ-affinity caching cut inter-AZ fees ~95% (~$12,000/month) with latency down 49%; NAT per-AZ guidance. itmagic.pro
8. egresscost.com (2026). "The Hidden Cloud Egress Costs Nobody Flags." 3-AZ traffic-share modeling (uniform-destination assumption); VPC endpoint break-even analysis. egresscost.com
9. costpulse.cloud (2026). "AWS Data Transfer Costs: The Billing Surprise Nobody Warns You About." Documented Geocodio case: $1,000/month of internal S3 traffic routed through NAT; Flexera 29% cloud waste figure. costpulse.cloud
10. jslet (2026). Related briefings: The LCU Trap · The NAT Gateway Trap · AWS Egress vs DigitalOcean · tools: Cross-AZ Cost Calculator · ALB/NLB Cost Engine · Users-to-Bandwidth · Egress Cost

📜 Copyright & Attribution