Peering Transit Gateways Across Regions

Does not cover creating the hub, attaching VPCs, segmentation, egress, hybrid connectivity, or multicast. Those are separate references.

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise. Peering spans two Regions; run requester-side commands in the requester Region and accepter-side commands in the accepter Region.

Table of Contents

• Overview
• Workflow
• The accept step
• Peering uses static routes only
• Encryption in transit
• Overlapping CIDR check
• Region-pair-dependent bandwidth
• Routing asymmetry with VPN
• Security considerations
• Troubleshooting
• Procedure
• Additional Resources

Workflow

To peer transit gateways across Regions end to end, follow the procedure exactly. See the Procedure section below. It covers creating the peering attachment from the requester transit gateway, accepting it on the accepter side, adding static routes in each transit gateway route table, and surfacing the console link to verify.

The accept step

A peering attachment stays pending until the owner of the accepter transit gateway accepts it. Creating the attachment does not establish the peer; it is not usable until it reaches the available state.

Constraints:

• You MUST treat the accept step as part of the workflow, not an external follow-up
• You MUST tell the customer the attachment is not usable until it reaches available

Peering uses static routes only

Peering does not support dynamic routing, so routes do not propagate across the peer the way they do for VPC attachments. Each transit gateway route table needs a static route pointing at the peering attachment.

Constraints:

• You MUST add a static route in each transit gateway route table pointing at the peering attachment for the remote Region’s ranges
• You MUST NOT wait for propagation across a peering attachment, since it never happens

Encryption in transit

Inter-Region transit gateway peering traffic travels over the AWS backbone and is automatically encrypted by AWS; the customer does not configure or manage this encryption.

Constraints:

• You SHOULD confirm to the customer that inter-Region peering traffic is automatically encrypted by AWS on the backbone, so they can weigh peering against a Site-to-Site VPN for inter-Region connectivity

Overlapping CIDR check

A transit gateway cannot route between overlapping ranges, so peering Regions whose VPC CIDR blocks overlap does not work. Overlap is harder to fix after workloads are deployed.

Constraints:

• You MUST check for CIDR overlap across both Regions before creating the peering attachment
• You MUST stop and tell the customer when an overlap exists, since the fix is re-addressing, not a routing change

Region-pair-dependent bandwidth

Peering bandwidth depends on the Region pair and is not guaranteed to match VPC attachment bandwidth. Customers who design for sustained inter-Region throughput assuming symmetric, VPC-equivalent bandwidth hit throttling.

Constraints:

• You SHOULD set this expectation when the customer designs for sustained inter-Region throughput
• You SHOULD have capacity planning account for the per-Region-pair limit, not assume VPC-attachment-equivalent bandwidth

Routing asymmetry with VPN

A customer who runs both inter-Region peering and a Site-to-Site VPN into the same Regions can get an asymmetric path, where traffic leaves over peering and returns over the VPN (or the reverse), unless route preferences are explicit. Because peering uses static routes, the customer also has to keep those static routes in sync by hand with the remote Region’s CIDRs as VPCs are added there.

Constraints:

• You MUST make the path preference explicit when both peering and VPN reach the same Regions, so traffic does not split paths
• You MUST flag the manual static-route maintenance as the remote side grows, since static peering routes do not track new CIDRs

Security considerations

Inter-Region peering joins two Regional hubs into one routing fabric, so a static route into the wrong table or an asymmetric path with a parallel VPN exposes or splits traffic across Regions. The controls are embedded in the procedure; this section consolidates them.

Constraints:

• You MUST add static routes only into the route tables that should reach the remote Region, since peering does not propagate and a route in the wrong table opens an unintended cross-Region path
• You MUST make the path preference explicit when both peering and a Site-to-Site VPN reach the same Regions, so traffic does not split paths, and MUST keep the static peering routes in sync as the remote side grows
• Inter-Region peering traffic is automatically encrypted by AWS on the backbone; the customer does not configure or manage this encryption
• You MUST enable VPC Flow Logs on the attached VPC subnets and Transit Gateway Flow Logs on the hub with encryption at rest on the destination, and you SHOULD enable AWS CloudTrail (encrypted) to detect unauthorized changes to attachments, route tables, associations, and propagations
• You MUST, when a KMS key encrypts a flow log or CloudTrail destination, scope the KMS key policy with condition keys (aws:SourceArn, aws:SourceAccount, kms:ViaService) so only the specific log group, bucket, or trail in the expected account and service can use the key
• You SHOULD apply least-privilege IAM for transit gateway administration, avoiding service wildcards and FullAccess policies

Troubleshooting

The peering attachment stays pending

The accepter has not accepted it. Accept it on the accepter side; wait for available.

No traffic flows after peering

Static routes pointing at the peering attachment are missing. Add them in each route table.

Connectivity does not work between peered Regions

The VPC CIDRs overlap. Check both Regions; re-address.

Throughput is throttled below expectations

Peering bandwidth is region-pair-dependent. Plan capacity for the per-pair limit.

Sessions drop when peering and VPN both reach a Region

The path is asymmetric. Make route preference explicit and keep peering static routes in sync.

Procedure

Overview

This procedure creates the peering attachment, accepts it, adds the static routes in each route table on both sides for bidirectional traffic flow, and surfaces the console link to verify.

Parameters

• requester_region (required): The Region of the requester transit gateway.
• requester_tgw_id (required): The requester transit gateway.
• accepter_region (required): The Region of the accepter transit gateway.
• accepter_tgw_id (required): The accepter transit gateway.
• accepter_account_id (required): The account that owns the accepter transit gateway.

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST check CIDR overlap across both Regions before creating the attachment

Steps

1. Verify dependencies

Constraints:

• You MUST confirm credentials with aws sts get-caller-identity, and you MUST use short-lived, ephemeral credentials scoped to least privilege for transit gateway administration, never long-lived access keys or broad service wildcard or FullAccess policies
• You MUST list the VPC CIDRs in both Regions and confirm no overlap
• You MUST enable VPC Flow Logs on the attached VPC subnets and Transit Gateway Flow Logs on the hub for traffic visibility, audit, and incident response across every attached network. These logs carry sensitive traffic data, so you MUST enable encryption at rest on the destination (a KMS key on the CloudWatch log group, or SSE-KMS on the S3 bucket)
• You SHOULD enable AWS CloudTrail to record transit gateway attachment, route table, association, and propagation changes for audit and unauthorized-change detection, and you MUST enable encryption at rest on the CloudTrail destination (a KMS key)
• You MUST, when a KMS key encrypts a flow log destination (CloudWatch log group or S3 bucket) or the CloudTrail destination, scope the KMS key policy with condition keys (aws:SourceArn, aws:SourceAccount, and kms:ViaService) so only the specific log group, bucket, or trail in the expected account and service can use the key, preventing cross-account or cross-service misuse
• You SHOULD create CloudWatch alarms for transit gateway attachment creation and deletion, route table changes, and failed or blocked attachment states, so that unexpected or unauthorized changes and failure conditions are surfaced for investigation rather than discovered after impact

2. Create the peering attachment

Constraints:

• You MUST create the peering attachment from the requester transit gateway:

  Copy

  aws ec2 create-transit-gateway-peering-attachment \
    --transit-gateway-id {requester_tgw_id} \
    --peer-transit-gateway-id {accepter_tgw_id} \
    --peer-account-id {accepter_account_id} \
    --peer-region {accepter_region} --region {requester_region}

• You MUST capture the TransitGatewayAttachmentId as {peering_attachment_id}

• You MUST poll until the attachment reaches pendingAcceptance:

  Copy

  aws ec2 describe-transit-gateway-peering-attachments \
    --transit-gateway-attachment-ids {peering_attachment_id} --region {requester_region}

3. Accept the peering attachment

Constraints:

• You MUST accept it on the accepter side:

  Copy

  aws ec2 accept-transit-gateway-peering-attachment \
    --transit-gateway-attachment-id {peering_attachment_id} --region {accepter_region}

• You MUST poll until the attachment reaches available:

  Copy

  aws ec2 describe-transit-gateway-peering-attachments \
    --transit-gateway-attachment-ids {peering_attachment_id} --region {requester_region}

4. Add static routes on the requester side

Constraints:

• You MUST discover the requester-side route table from the peering attachment’s existing association, which is unambiguous even when the requester transit gateway has multiple route tables in a segmented design. Do not take the first route table blindly:

  Copy

  aws ec2 describe-transit-gateway-attachments \
    --transit-gateway-attachment-ids {peering_attachment_id} \
    --query 'TransitGatewayAttachments[0].Association.TransitGatewayRouteTableId' \
    --output text --region {requester_region}

• You MUST add a static route in the requester transit gateway route table pointing at the peering attachment for the accepter Region’s ranges:

  Copy

  aws ec2 create-transit-gateway-route \
    --transit-gateway-route-table-id {requester_route_table_id} \
    --destination-cidr-block {accepter_cidr} \
    --transit-gateway-attachment-id {peering_attachment_id} --region {requester_region}

5. Add static routes on the accepter side

Constraints:

• You MUST discover the accepter-side route table from the peering attachment’s existing association, which is unambiguous even when the accepter transit gateway has multiple route tables in a segmented design. Do not take the first route table blindly:

  Copy

  aws ec2 describe-transit-gateway-attachments \
    --transit-gateway-attachment-ids {peering_attachment_id} \
    --query 'TransitGatewayAttachments[0].Association.TransitGatewayRouteTableId' \
    --output text --region {accepter_region}

• You MUST add a static route in the accepter transit gateway route table pointing at the peering attachment for the requester Region’s ranges:

  Copy

  aws ec2 create-transit-gateway-route \
    --transit-gateway-route-table-id {accepter_route_table_id} \
    --destination-cidr-block {requester_cidr} \
    --transit-gateway-attachment-id {peering_attachment_id} --region {accepter_region}

• You MUST add routes on both sides for bidirectional traffic flow.

6. Confirm and surface the console link

Constraints:

• You MUST confirm the peering attachment is available:

  Copy

  aws ec2 describe-transit-gateway-peering-attachments \
    --transit-gateway-attachment-ids {peering_attachment_id} --region {requester_region}

• You MUST present the transit gateway console link for each Region, filling {requester_tgw_id}/{accepter_tgw_id} and {requester_region}/{accepter_region}, and tell the customer to open it and confirm the peering attachment and routes:

  Copy

  https://{requester_region}.console.aws.amazon.com/vpc/home?region={requester_region}#TransitGatewayAttachments:
  https://{accepter_region}.console.aws.amazon.com/vpc/home?region={accepter_region}#TransitGatewayAttachments:

Example

Example input

Example output

Troubleshooting

Attachment stuck in pending

Not accepted. Accept on the accepter side (Step 3).

No traffic after peering

Static routes missing. Add them in each route table on both sides (Steps 4 and 5).

Connectivity fails between Regions

CIDRs overlap. Re-check and re-address (Step 1).

Additional Resources

• Create a peering attachment in AWS Transit Gateway (AWS Transit Gateway Guide) (opens in a new tab)
• How AWS Transit Gateway works: Example: Peered transit gateways (AWS Transit Gateway Guide) (opens in a new tab)
• Transit gateway peering attachments in AWS Transit Gateway (AWS Transit Gateway Guide) (opens in a new tab)
• Using the AWS CDK and AWS Transit Gateway Inter-Region peering to build a global network (AWS Networking and Content Delivery Blog) (opens in a new tab)

• PreviousReference Migrating From VPC Peering
• NextReference Routing Multicast Traffic