AWS DX – DXGW with AWS Transit Gateway, Multi-Regions (more than 3) - Hybrid Connectivity

AWS DX – DXGW with AWS Transit Gateway, Multi-Regions (more than 3)

This model is constructed of:

  • Multi AWS Regions (more than 3).

  • Dual on-premises data centers.

  • Dual AWS Direct Connect Connections across to independent DX locations per Region.

  • AWS DXGW with AWS Transit Gateway.

  • High scale of VPCs per Region.

  • Full mesh of peering between AWS Transit Gateways.

Figure 10 – AWS DX – DXGW with AWS Transit Gateway, Multi-Regions (more than 3)

Connectivity model attributes:

  • Lowest operational overhead.

  • AWS DX public VIF is used to access AWS public resources such as S3 directly over the AWS DX connections.

  • Provide the ability to connect to VPCs and/or DX connection(s) in other Regions in the future.

  • With AWS Transit Gateway connected to VPCs, Full mesh connectivity or partial mesh connectivity can be achieved between the VPCs.

  • Inter-Region VPC communication is facilitated by AWS Transit Gateway peering.

  • Offers flexible design options to integrate third-party security and SDWAN virtual appliances with AWS Transit Gateway. See: Centralized network security for VPC-to-VPC and on-premises to VPC traffic.

Scale considerations:

  • The number of routes to and from AWS Transit Gateway is limited to the maximum supported number of routes over a Transit VIF (inbound and outbound numbers vary). Refer to the AWS Direct Connect quotas for more information about the scale limits. (Routes summarization recommended).

  • Scale up to thousands of VPCs per AWS Transit Gateway over a single BGP session per DXGW (assuming the provided performance by the provisioned AWS DX connection(s) is sufficient).

  • Up to 3x AWS Transit Gateways can be connected per DXGW.

  • If more than 3 Regions need to be connected using AWS Transit Gateway, then additional DXGWs are required.

  • Single Transit VIF per AWS DX.

  • Additional AWS DX connection(s) can be added as desired.

Other considerations:

  • Incurs additional AWS Transit Gateway processing cost for data transfer the on-premises site and AWS.

  • Security groups of a remote VPC cannot be referenced over AWS Transit Gateway (need VPC peering).

  • VPC peering can be use instead of AWS Transit Gateway to facilitate the communication between the VPCs, however, this will add operational complexity to build and manage large number VPC point-to-point peering at scale.

The following decision tree covers the scalability and communication model considerations:

Figure 11 – Scalability and communication model decision tree


If the selected connection type is VPN, typically at the performance consideration, the decision should be made whether the VPN termination point, is AWS VGW or AWS Transit Gateway AWS S2S VPN connection. If not made yet, then you can consider the required communication model between the VPC along with the number of required VPC to be connected to the VPN connection(s) to help you to make the decision.