Explanation
Why the waste happens and who it affects.
While these patterns may be functionally correct, they can lead to unnecessary data transfer charges when the traffic could be contained within a single AZ. Over time, this can become a silent cost driver, especially for chatty microservices, replicated storage layers, or high-throughput pipelines. Re-architecting for AZ-locality - when possible-can reduce these charges without affecting availability in environments where high resilience isn't required.
Billing model
The pricing dimensions that drive this cost.
Data transferred between AWS resources is billed based on the source and destination of the traffic. While data transferred within the same Availability Zone is typically free, data transferred between Availability Zones within the same region incurs per-GB charges in both directions, even if the traffic stays within a single VPC. This pricing model applies across many AWS services, including EC2, traffic between EC2 and RDS in different AZs, and Network Load Balancers with cross-zone load balancing enabled. There are exceptions: data transferred between AZs for RDS Multi-AZ replication is free, and Application Load Balancer cross-zone traffic is not charged. Although inter-region traffic is charged at higher rates, cross-AZ transfer within a region is a common source of silent, avoidable cost, especially in architectures that weren't designed with AZ-locality in mind.
How to detect
6 checks to find it in your estate.
- Identify resources that receive or send high volumes of traffic to other Availability Zones within the same region
- Review VPC flow logs, CloudWatch metrics, or billing data to assess regional data transfer patterns
- Determine whether the resource acts as a centralized destination for data aggregation, storage, or processing
- Evaluate whether AZ locality can be preserved (e.g., by colocating compute and storage in the same AZ)
- Confirm that high availability requirements wouldn't be compromised by reducing cross-AZ replication or communication
- Engage with application or infrastructure teams to assess whether architectural changes could reduce AZ-to-AZ traffic without impacting service goals
How to fix
How to remove the waste.
Where feasible, update the architecture to localize traffic within a single Availability Zone. This may include placing dependent resources (e.g., compute, cache, storage) in the same AZ, using zonal services, or avoiding unnecessary replication across zones. In cases where high availability is required, assess whether the added cost of cross-AZ traffic is justified, or whether more efficient patterns - such as reducing the volume or frequency of cross-AZ communication-can help contain costs without compromising resilience.
Documentation
Vendor references for pricing and configuration.