Cross-region data transfer with Transit Gateway: Simplify your network

Managing connectivity between AWS regions without Transit Gateway means direct peering connections: one connection per pair of VPCs, multiplying in complexity as the number of VPCs grows. Ten VPCs across two regions can require up to 45 direct peering connections to achieve full mesh connectivity. Transit Gateway replaces that with a hub-and-spoke model: each VPC connects once to the regional Transit Gateway, and inter-region connectivity happens via a single peering attachment between gateways.

This guide covers the design, cost implications, and operational best practices for cross-region data transfer using Transit Gateway.

How Transit Gateway inter-region peering works

Each AWS region gets its own Transit Gateway. Inter-region peering creates a direct routing path between two regional gateways, carried over AWS's private global backbone rather than the public internet. Traffic between eu-west-2 (London) and eu-west-1 (Ireland) via Transit Gateway peering stays on AWS infrastructure: lower latency than public internet routing and encrypted at the physical layer.

Transit Gateway operates at Layer 3, routing packets by destination IP. When you configure inter-region peering:

  1. Create a peering attachment from the source Transit Gateway to the destination Transit Gateway
  2. The destination account owner accepts the peering request
  3. Add static routes in both Transit Gateway route tables: traffic destined for the remote region's CIDR range points to the peering attachment
  4. VPCs attached to each Transit Gateway can now route traffic to the remote region via their respective Transit Gateways

The peering attachment itself has no bandwidth limit, but individual VPC attachments to the Transit Gateway are capped at 50 Gbps. Each Connect attachment (for on-premise or third-party connectivity) supports up to 20 Gbps per attachment.

Cost structure and where to optimise

Transit Gateway cross-region data transfer costs have two components:

Peering attachment hourly charge: A fixed hourly fee for each active peering attachment between regions. This runs continuously regardless of data volume.

Data processing charge per GB: AWS charges approximately £0.02 to £0.17 per GB for inter-region data transfer, depending on the region pair. London to Ireland is at the lower end; Europe to US is higher.

These costs accumulate at volume. Best practices for cost reduction:

Keep traffic within the same region where possible. The cheapest cross-region transfer is the one that does not happen. Audit which services genuinely need inter-region communication and which were placed in different regions because of historical decisions. Services that frequently exchange data should be co-located.

Use compression before transfer. Compressing data before it crosses the peering attachment reduces the GB volume that incurs per-GB charges. For API responses and database exports moving between regions, gzip compression typically reduces volume by 60-80%.

Route large transfers via Direct Connect where applicable. For very high-volume, predictable data flows between on-premise and AWS across regions, Direct Connect metered billing can be cheaper than Transit Gateway inter-region transfer charges at scale.

Monitor transfer volumes with CloudWatch Transit Gateway metrics. The BytesIn and BytesOut metrics per attachment show exactly how much data is crossing each peering connection. Unexpected spikes indicate a misconfigured workload generating unintended cross-region traffic.

ECMP routing for load distribution

Transit Gateway supports Equal Cost Multipath (ECMP) routing for attachments that support it. ECMP distributes traffic across multiple equal-cost paths to the same destination, improving throughput and resilience.

For inter-region peering, you can create multiple peering attachments between the same two Transit Gateways and configure ECMP routing to distribute traffic across them. This increases effective bandwidth between regions and provides path redundancy: if one peering attachment fails, traffic routes across the remaining attachments.

Configure ECMP by ensuring multiple peering attachments appear as equal-cost routes in the Transit Gateway route table. Transit Gateway automatically distributes flows across ECMP paths using a 5-tuple hash.

For VPN attachments to Transit Gateway, ECMP over multiple VPN connections to the same transit gateway can aggregate bandwidth. Each VPN tunnel provides up to 1.25 Gbps; ECMP across multiple tunnels aggregates this.

Route management and route table design

Transit Gateway route tables are where traffic routing decisions are defined. A well-designed route table structure prevents routing loops and keeps traffic flowing correctly between regions.

The recommended approach for multi-region Transit Gateway:

  • One route table per region (or per environment if environments span regions)
  • Route tables contain: routes to local VPC attachments, routes to remote regional CIDRs via the peering attachment
  • Avoid advertising overlapping CIDRs between regions: overlapping address space causes routing ambiguity
  • Use distinct, non-overlapping CIDR ranges for each VPC in each region when designing the IP addressing scheme

For troubleshooting routing issues, the Transit Gateway Network Manager Route Analyzer validates that a route exists between a source and destination in the route table. Use it before testing live traffic to confirm the routing configuration is correct.

Monitoring with Transit Gateway Flow Logs

Transit Gateway Flow Logs capture metadata for all traffic flowing through the gateway: source IP, destination IP, source port, destination port, protocol, bytes, packets, and the action (ACCEPT or REJECT). Enable them on every active Transit Gateway attachment for cross-region traffic visibility.

Store flow logs in Amazon S3 with intelligent tiering: active analysis uses standard storage, older logs move to cheaper archive tiers on a lifecycle policy. Query flow logs with Athena for ad-hoc investigation without ingesting everything into a queryable store.

For ongoing operational monitoring, send Transit Gateway metrics to CloudWatch and alert on:

  • PacketDropCountBlackhole: traffic dropped because no route exists (indicates a routing misconfiguration)
  • BytesIn/BytesOut spikes on peering attachments (cost and capacity signals)
  • Attachment state changes (peering attachment going down requires immediate investigation)

Where Critical Cloud comes in

Cross-region Transit Gateway architecture is a foundational networking decision that is expensive to redesign once workloads are running across it. Getting the route table design, cost monitoring, and ECMP configuration right from the start prevents the class of problems that appear at scale. We design and operate AWS networking for regulated and technology-led businesses, with Transit Gateway metrics surfaced in the same operational view as application and infrastructure performance. As the world's first Powered by Datadog accredited partner, we correlate network flow signals with application behaviour to catch unexpected cross-region traffic before it becomes a billing surprise. See how Critical Support works.