AWS Inter-Region Transfer Costs: Multi-Region Architecture Pricing

Why Inter-Region Transfer Costs Catch Enterprises Off Guard

When enterprises design multi-region AWS architectures, the planning conversation focuses on latency, compliance, failover, and Recovery Time Objectives. Data transfer costs are often treated as a rounding error — until the first full month of production traffic arrives. For architectures replicating data across three or more regions, inter-region charges can represent 15 to 25 percent of total AWS spend.

The structural problem is that AWS prices inter-region transfer at the per-GB level in each direction, with no volume discount below the EDP level, and the charges compound through every network service in the data path: the EC2 instance, the NAT Gateway, the Transit Gateway attachment, and any S3 operations. A single data flow that crosses a region may trigger three or four separate per-GB charges before it reaches its destination.

Understanding this pricing architecture is the prerequisite for any meaningful cost reduction. Our guide to AWS data egress and transfer cost reduction covers the full landscape; this page focuses specifically on inter-region pricing mechanics and the optimisation levers available to multi-region architects.

The Inter-Region Pricing Matrix

AWS does not publish a single inter-region transfer price. Rates vary by the originating and destination region, with the primary variables being geographic distance and infrastructure investment in each region.

US Region Pairs

Traffic between US East (N. Virginia) and US East (Ohio) is the cheapest inter-region path at $0.01 per GB in each direction. This reflects the short geographic distance and shared infrastructure investment. All other US-to-US region pairs — US East to US West (Oregon), US East to US West (N. California), US West to US East — are priced at $0.02 per GB per direction.

US to Europe and Asia-Pacific

Transfers between US regions and European or Asia-Pacific regions are standardised at $0.02 per GB per direction for most region pairs. This includes US East to EU (Ireland), US East to EU (Frankfurt), US East to Asia Pacific (Singapore), and US East to Asia Pacific (Tokyo).

High-Cost Region Pairs

South America (São Paulo) carries a significant premium. Data transferred from US East to São Paulo or from São Paulo to any other region is priced at $0.02 to $0.04 per GB depending on the direction and the remote region. Africa (Cape Town) carries similar premiums due to the infrastructure investment required. Middle East (Bahrain, UAE) regions also carry slightly elevated rates on some traffic paths.

The Directionality Trap

A critical and frequently overlooked aspect of AWS inter-region pricing: the charge applies in both directions. If your application replicates a database from US East to EU West and also synchronises cache invalidations from EU West back to US East, you pay $0.02 per GB for each direction of that traffic. An architecture generating 50 TB per month of bidirectional inter-region replication pays for 100 TB of billable transfer, not 50 TB.

The Hidden Cost Multipliers

The published per-GB inter-region rate is only part of the story. Several network services add their own processing fees to the same data transfer, stacking charges that the per-GB published rate does not reflect.

NAT Gateway Processing Charges

If your inter-region traffic routes through a NAT Gateway — which is common for private subnet resources that require internet or cross-region connectivity — AWS charges an additional $0.045 per GB of data processed by the NAT Gateway. This charge applies on top of the inter-region transfer charge, effectively tripling the cost of traffic that passes through a NAT Gateway before crossing a region. For architectures that use NAT Gateways for all outbound connectivity from private subnets, this is frequently the largest single line item on the transfer cost bill.

Transit Gateway Data Processing

AWS Transit Gateway is the preferred architecture for connecting multiple VPCs across regions. But Transit Gateway charges both an attachment fee ($0.05 per hour per VPC attachment, approximately $36 per month per attached VPC) and a data processing fee of $0.02 per GB for all traffic routed through the gateway. Traffic routed through a Transit Gateway across regions therefore incurs three charges: the Transit Gateway attachment fee, the Transit Gateway data processing fee, and the inter-region transfer charge.

Cross-AZ vs Cross-Region Confusion

Cross-Availability Zone traffic within a single region is charged at $0.01 per GB per direction — separate from inter-region charges. Enterprises that assume all intra-region traffic is free discover that multi-AZ deployments (which are the best practice for resilience) generate significant cross-AZ transfer charges for high-throughput workloads. An application making 200 TB per month of cross-AZ calls in a single region pays $2,000 per month before any inter-region charges are applied.

S3 Replication Costs

Cross-Region Replication (CRR) for S3 buckets replicates objects from a source bucket to a destination bucket in a different region. The data transfer charge applies at the standard inter-region rate for the volume of data replicated. For large S3 datasets with active replication, this can represent tens of thousands of dollars per month in transfer charges alone — in addition to the S3 storage and request costs in the destination region.

Five Strategies to Reduce Inter-Region Transfer Costs

The goal is not to eliminate multi-region architecture — resilience and geographic proximity requirements are legitimate. The goal is to ensure that every byte crossing a region boundary is doing so for a justified business reason at the lowest possible cost.

Strategy 1: Redesign for Data Locality

The most effective cost reduction strategy is architectural: ensure that compute resources and the data they consume are co-located in the same region wherever possible. This means:

• Placing read replicas of databases in the regions where read traffic originates, rather than routing reads cross-region to a primary database.
• Deploying CDN edge caches (Amazon CloudFront) for static and semi-static content to serve users from edge locations rather than origin regions.
• Co-locating Lambda functions and the S3 buckets or DynamoDB tables they access in the same region.
• Reviewing microservice call graphs for cross-region calls that could be served by regional instances of the same service.

Data locality redesign is the single highest-impact optimisation because it eliminates transfer charges at the source rather than reducing them at the margin.

Strategy 2: Replace NAT Gateways with VPC Endpoints

For traffic destined for AWS services (S3, DynamoDB, SQS, SNS, and others that support Gateway or Interface endpoints), deploying VPC Endpoints eliminates NAT Gateway processing charges entirely. Traffic to S3 and DynamoDB via Gateway endpoints does not incur the $0.045 per GB processing charge. For workloads generating hundreds of terabytes per month of S3 traffic from private subnets, this single change can reduce monthly transfer bills by $20,000 to $100,000.

Interface endpoints (AWS PrivateLink) for other AWS services carry their own hourly and data processing charges, but these are typically lower than equivalent NAT Gateway processing costs for high-volume traffic. Evaluate on a per-service basis using your actual traffic volumes.

Strategy 3: Use VPC Peering for Point-to-Point Cross-Region Connections

For architectures with a small number of fixed VPC-to-VPC connections across regions, VPC Peering eliminates the Transit Gateway data processing charge. VPC Peering does not charge a data processing fee — only the standard inter-region transfer charge applies. For a workload sending 500 TB per month cross-region through a Transit Gateway, switching to VPC Peering eliminates $10,000 per month of Transit Gateway processing charges.

VPC Peering is not suitable for hub-and-spoke or mesh connectivity patterns with many VPCs, because VPC Peering connections are non-transitive (traffic cannot flow through a peered VPC to reach a third VPC). For complex topologies, Transit Gateway remains the correct architectural choice — but the processing cost should be factored into the design decision.

Strategy 4: Optimise Cross-Region Replication Scope

S3 Cross-Region Replication and RDS cross-region read replicas are the two most common sources of unexpected inter-region volume. Both should be audited for actual business necessity:

• S3 CRR: Use S3 Replication Time Control only for objects that require cross-region durability for compliance or disaster recovery. Use S3 Intelligent-Tiering or lifecycle policies to reduce the volume of objects eligible for replication.
• RDS Read Replicas: Evaluate whether cross-region read replicas are actively serving read traffic or were deployed for disaster recovery but receive minimal live queries. Read replicas that serve less than 20 percent of query volume rarely justify their ongoing replication transfer cost.
• DynamoDB Global Tables: DynamoDB charges replicated write capacity units across every region the table is deployed in. Tables deployed to three regions for DR purposes where only one region serves active traffic are paying triple write costs plus inter-region replication charges.

Strategy 5: Negotiate Transfer Costs Within Your EDP

Enterprise customers on an AWS Enterprise Discount Program (EDP) can negotiate custom pricing for data transfer charges within their PPA. Transfer costs are one of the line items that AWS will discount for customers committing to significant annual spend — particularly if transfer represents a disproportionate share of total AWS cost. During EDP renewal, presenting a detailed transfer cost analysis that quantifies the volume and direction of inter-region traffic gives your negotiating team the evidence needed to request transfer rate discounts.

This is distinct from the negotiation strategy for AWS egress charges broadly, but the same principles apply: AWS will not voluntarily discount transfer costs; you need to ask with data.

Mapping Inter-Region Costs to Common Architecture Patterns

Active-Active Multi-Region

Active-active architectures where both regions serve live traffic are justified by both resilience and latency requirements. The inter-region traffic in this pattern consists primarily of data synchronisation (database replication, session state, cache invalidation) rather than user-serving traffic. The optimisation focus should be on minimising synchronisation volume through event-driven architectures and asynchronous replication where consistency requirements allow.

Active-Passive (Hot Standby)

Hot standby architectures maintain a full replica in a second region that serves no live traffic. Inter-region costs in this pattern are 100 percent overhead — they exist entirely for disaster recovery. The cost-justification question is: what is the RTO/RPO that the hot standby delivers, and is that better than a warm standby (lower cost) or a cold standby (lowest cost) given your actual DR requirements?

Many enterprises operate hot standbys for systems whose actual DR requirements could be satisfied by a warm standby at 60 to 70 percent lower replication cost. This is worth revisiting periodically.

Data Processing Pipelines

ETL and analytics pipelines that pull raw data from one region for processing and load results into another region are among the highest-volume inter-region transfer consumers. The standard optimisation is to move compute to data: deploy the processing layer in the same region as the source data and ship only the smaller processed output cross-region, rather than shipping raw data to a central processing region.

EDP and PPA Negotiation Context

Data transfer charges are included in the AWS bill that counts toward EDP commitment thresholds. This means that enterprise customers with significant transfer costs are technically contributing to their EDP commitment levels — but may be paying list price for transfer while receiving discounts on compute and storage.

The correct negotiating position is to separate transfer costs from compute and storage costs in your EDP model, demonstrate the transfer volume that your architecture requires, and request a custom transfer rate as part of the PPA terms. AWS will negotiate this for customers with transfer volumes above approximately $200,000 per year, particularly where the alternative is architectural changes that would reduce AWS transfer revenue entirely.

Our guide to AWS Marketplace procurement strategy covers how EDP credits interact with Marketplace purchases — relevant context if your architecture includes Marketplace-sourced services that generate inter-region traffic.

Reserved Instances and Savings Plans: The Transfer Blind Spot

One of the most common misconceptions about AWS Reserved Instances and Savings Plans is that they reduce data transfer costs. They do not. RIs and Savings Plans apply exclusively to EC2 compute, RDS instance hours, and equivalent compute-based services. Data transfer charges are always at list price unless specifically negotiated within an EDP or PPA. Organisations that have heavily optimised their compute costs through RIs often find that transfer costs represent a growing percentage of their remaining unoptimised spend.

Monitoring and Visibility

Before optimising, you need to see where transfer costs are originating. AWS Cost Explorer provides per-service and per-region breakdowns, but inter-region transfer attribution requires tagging discipline and VPC Flow Logs analysis to identify specific traffic flows. The key questions to answer from your data are:

• Which regions are generating the most inter-region transfer volume?
• What is the service-level breakdown — EC2, S3, RDS, ElastiCache?
• What proportion passes through NAT Gateways versus VPC Endpoints versus Transit Gateway?
• Is inter-region traffic growing faster than your overall AWS spend growth?

Once you have this breakdown, the optimisation decisions become data-driven rather than speculative. Our AWS support plan negotiation guide covers how TAM engagements can be used to surface cost visibility data as part of your support relationship — relevant if your TAM is already engaged on cost optimisation.

Key Actions for Multi-Region Architects

Audit your VPC Flow Logs for inter-region traffic volume by source and destination service before assuming you know where the costs originate. Bills rarely reflect what engineers believe about traffic patterns.

Deploy VPC Gateway Endpoints for S3 and DynamoDB immediately if you have not already done so. This is a zero-risk, zero-architectural-impact change that eliminates NAT Gateway processing charges on the two highest-volume AWS services in most architectures.

Review your S3 CRR and RDS read replica configurations against actual DR requirements. Default replication configurations set up during initial deployment are rarely revisited as architecture evolves.

Include transfer costs in your EDP renewal discussions. If you are renewing an EDP in the next 12 months and your monthly transfer bill exceeds $15,000, there is room to negotiate a custom rate as part of your PPA terms.

To discuss your specific multi-region architecture and identify the most impactful transfer cost reductions available to your environment, speak with our AWS cloud cost advisory specialists.