Some architectures unintentionally route large volumes of traffic between resources that reside in different Availability Zones—such as database queries, service calls, replication, or logging. 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.
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, RDS, and Load Balancers. 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.
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.
