Home/Library/Reduce Inter-Region and Inter-AZ Traffic Costs
How-to · AWS · Updated May 2026

How to Reduce AWS Inter-Region and Inter-AZ Traffic Costs

Cross-region and cross-AZ data transfer is charged per GB, often on both sides, and a chatty architecture pays it on every call. The savings come not from a setting but from where you place services and how often they talk across a boundary.

Reducing AWS inter-region and inter-AZ traffic costs means cutting the per-GB charges you pay when data crosses between AWS regions or between availability zones inside one region. Inter-region traffic is billed when data moves region to region, for replication or a cross-region call, and inter-AZ traffic is billed in each direction when components in different AZs talk to each other. Because these charges scale with how much your architecture crosses those boundaries, the levers are architectural: co-locate services that talk a lot, reduce unnecessary cross-region replication, and route traffic through paths that are not charged. None of it is a console toggle; it is design discipline informed by where your transfer cost actually lands.

This how-to sits under our complete guide to AWS cost optimization, the pillar for this cluster, and supports the Cut step of our See, Cut, Lock, Run method. It is the deep dive promised in the broader AWS data transfer and egress charges explainer, a sibling in this cluster, focused specifically on the cross-boundary lines.

See it before you cut it

Query the Cost and Usage Report by usage type to split inter-region from inter-AZ transfer into separate dollar figures. The fix differs by source, so you need to know which boundary your traffic is crossing before you change anything.

Cut inter-AZ traffic with co-location

Inter-AZ charges are the ones teams forget, because spreading across AZs is good for resilience and nobody connects that to a transfer line. The cost appears when chatty components, a service and its cache, an application and a database, sit in different AZs and pay for every cross-AZ hop in both directions. The lever is to co-locate components that communicate heavily within the same AZ where your resilience requirements allow, so the high-frequency traffic stays free of cross-AZ charges, while still spreading the workload across AZs at the layer that needs fault tolerance. The art is separating which traffic genuinely needs cross-AZ redundancy from which is just chatter that could stay local.

Cut inter-region traffic with replication discipline

Inter-region charges usually come from a small number of heavy paths: database or storage replication to another region, logging and telemetry pipelines shipping data cross-region, and services in one region calling dependencies in another. Each deserves a hard question. Does this data need to be replicated to that region at all, or is the disaster-recovery requirement met by a less frequent or more selective copy? Can cross-region log shipping be batched, compressed or filtered to send less? Can a service that calls across regions be moved or given a regional replica so the call stays in-region? Often a single replication path or telemetry stream is the bulk of the inter-region bill, and trimming it is the whole saving.

Want your cross-boundary transfer traced and cut?

Our AWS cost audit decomposes inter-region and inter-AZ transfer by path, identifies the chatty services and heavy replication worth re-architecting, and quantifies the saving first. On the performance model you pay only from realized savings. No savings, no fee.

Book an AWS cost audit →

Route around charged paths

Some cross-boundary traffic can be removed by routing rather than redesign. VPC gateway endpoints for S3 and DynamoDB keep traffic to those services off paths that would otherwise add charges. VPC peering and private connectivity choices change which transfers are billed and at what rate, so the topology matters. Where data must cross a boundary, sending less of it helps directly: compress payloads, filter before you ship, and cache cross-region responses so repeat reads do not re-cross. Each of these targets the per-GB volume on a charged path rather than the existence of the path itself, which makes them low-risk complements to the co-location and replication work.

BoundaryCommon sourceLever
Inter-AZChatty service to database or cacheCo-locate heavy talkers in one AZ
Inter-regionReplication and telemetryReduce, batch, filter, compress
Cross-region callsService calling out-of-region dependencyRegional replica, keep calls local
Service-mediatedTraffic via NAT to S3 or DynamoDBVPC gateway endpoints

AWS inter-region and inter-AZ data transfer pricing, VPC endpoint behavior and peering charges reflect AWS as of May 2026. Verify current per-GB rates by path and region on the AWS pricing pages before modeling savings, as these change and vary by region pair.

Go deeper · free field guide

The AWS Cost Optimization Field Guide includes the usage-type queries that separate inter-region from inter-AZ transfer and the co-location and replication review checklist we run on heavy-transfer architectures.

The short version

AWS inter-region and inter-AZ traffic costs fall when you co-locate chatty components within an AZ to kill cross-AZ chatter, apply replication discipline to the heavy cross-region paths, and route traffic through endpoints and topologies that avoid charged paths, sending less data wherever it must cross. Start by splitting the two boundaries into separate dollar figures in the Cost and Usage Report, then apply the matching lever. Tracing and cutting cross-boundary transfer is a routine part of an AWS cost optimization engagement, as in our SaaS on AWS case study.

The Cloud Cost Brief

Cloud pricing moves. We tell you when it matters.

New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.

Subscribe · Work email only