The Silent $1,000/Month AWS Tax: Why Your Cross-AZ Traffic Is Bleeding Money
Most AWS cost optimization guides tell you to purchase Savings Plans or downsize EC2 instances. Yet, engineering teams consistently overlook one of the fastest-growing line items on their cloud bills: Inter-Availability Zone (Cross-AZ) Data Transfer. Here is how standard high-availability patterns secretly double your networking costs, and the 3 architectural rules to eliminate the tax without sacrificing resilience.
The Hidden Trap: "High Availability" Isn't Free
AWS charges $0.01 per GB in each direction ($0.02/GB round-trip) for data moving across Availability Zones within the same region.
That sounds negligible until you look at how modern distributed systems communicate:
- Microservice A in
us-east-1acalls Microservice B behind an Application Load Balancer (ALB). - Microservice B talks to an Amazon ElastiCache cluster or an Amazon RDS read replica.
- A distributed Kafka/MSK or OpenSearch cluster replicates petabytes across nodes.
1
2
3
4
5
[Service A (AZ-a)] ──($0.01/GB)──► [ALB (AZ-b)] ──($0.01/GB)──► [Service B (AZ-b)]
│
($0.01/GB)
▼
[ElastiCache (AZ-c)]If your microservices handle high-throughput payloads, event streams, or caching layers, cross-AZ chatter quietly accumulates into hundreds or thousands of dollars every month purely in transit fees.
3 Architecture Rules to Eliminate Cross-AZ Costs
1. Enable AZ-Affinity on Application Load Balancers
By default, ALBs use cross-zone load balancing. When an instance in
AZ-a handles traffic, the ALB distributes target requests evenly across all registered targets in all AZs—guaranteeing that roughly 66% of your traffic crosses AZ boundaries.- The Fix: Turn off cross-zone load balancing on ALBs where your target instances are already evenly distributed across AZs:
1
2
3
4
5
6
7
8
9
resource "aws_lb" "internal_app" {
name = "internal-microservice-alb"
internal = true
load_balancer_type = "application"
subnets = [aws_subnet.private_a.id, aws_subnet.private_b.id]
# Disables cross-AZ routing when targets are balanced
enable_cross_zone_load_balancing = false
}2. Implement Topology-Aware Routing in Kubernetes (EKS / ECS)
In containerized environments (Amazon EKS), pods frequently send RPC calls to services scheduled on nodes in adjacent AZs.
- The Fix: Use Kubernetes Topology Aware Hints (
service.kubernetes.io/topology-mode: auto). This instructs kube-proxy or the AWS VPC CNI to route ingress traffic to pod replicas living on nodes within the exact same Availability Zone, only spilling over to neighboring AZs during failover events.
3. Match Caching and Database Nodes to Compute Placement
A common design flaw is deploying an Amazon ElastiCache (Redis/Memcached) cluster where read-heavy workloads in
AZ-a and AZ-b query a primary node pinned in AZ-c.- The Fix:
- For caching: Deploy node groups with read replicas in every AZ where compute runs, and configure client SDKs with AZ-aware read routing.
- For Amazon Aurora: Keep read-heavy serverless microservices reading from the local replica in their respective AZ using custom endpoint rules.
The 2-Minute Cross-AZ Audit
Want to verify if cross-AZ chatter is draining your budget?
- Open AWS Cost Explorer.
- Group by Usage Type and filter by service EC2 - Other.
- Look for charges labeled:
RegionalDataTransfer-In-BytesRegionalDataTransfer-Out-BytesInterZone-In/InterZone-Out
If these metrics show continuous spikes, your services are talking across boundaries instead of keeping transactions local.
Community Check
How does your team enforce AZ-affinity across distributed microservices or Kubernetes clusters? Have you audited your
RegionalDataTransfer charges recently? Share your setup below! 👇Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article