Peer VMware managed TGW to AWS TGW in multi-region and multi-accounts

Gilles Chekroun


Lead VMware Cloud on AWS Solutions Architect

---

UPDATED with On-prem connectivity (21 Sept 2021)

VMware Managed Transit Gateway (aka vTGW or VMware Transit Connect) has now the capability to peer with an AWS TGW in a different AWS region.

This is a new capability that will be introduced in the VMC release 1.16 but already available from 1.12 and up latest updates.

TGW peering

This capability has been available for quite some time with AWS Networking.

Today the routing between TGWs is static although AWS recommends to use different ASN in case BGP Dynamic routing will come later.

"To route traffic between the transit gateways, add a static route to the transit gateway route table that points to the transit gateway peering attachment.
We recommend using unique ASNs for the peered transit gateways to take advantage of future route propagation capabilities."

The following post will describe a vTGW to a TGW in multi-region - multi accounts setup.

Peering Link Encryption

Transit gateway peering uses the same network infrastructure as VPC peering and is therefore encrypted by definition. More information here.

Lab Setup

SDDC Grouping

Region A - Oregon

Accounts

In that side, we have the SDDC VMware Account AKA shadow account starting with 8442 and also the AWS Customer account in Oregon starting with 6140.

I will skip the SDDC grouping and VPC attachement as it's been described here

After creating SDDC_GROUP_A and attaching VPC110, the vTGW route table will look like:

Only after updating the VPC120 route tables, a VM inside the SDDC will can ping an EC2 in VPC110 via the vTGW

Region B - Ohio

Accounts

In that side we only have the AWS Customer account in Ohio starting with 0631.

Let's create a TGW and attach VPC 120 to it.

TGW

VPC120 route table

TGW Peering

At this stage we need to peer the vTGW and the Customer TGW.

There is a new TAB in the SDDC Group area on the VMC Console called "External TGW"

AWS TGW attachment

The peer link will be created by the VMC console between the vTGW (VMware account) and the Customer TGW (Customer Account)

Peering TGW route table

Transit Connect route table

VMC System Defined Groups

For simplicity and easy FW configuration, the VMC Console provides "system defined Groups" that will include DXGW, SDDC, VPC and now Customer TGW information

Connectivity 

Now a VM inside the SDDC can reach EC2 on the other region VPC120

EC2 inside VPC120 can ping SDDC VM

Allowed Flows

As a generic rule, traffic allowed over a vTGW MUST have an SDDC as one end of the flow.

For example EC2 in VPC 110 will not reach EC2 in VPC120.

Adding VPN to On-prem

After creating a Route based VPN from the Ohio TGW to on-prem, the TGW routing table is updated with on-prem Networks.

Let's focus on 192.168.200.0/24 and the VM at .50

Ping EC2 at VPC120

Add Static route to on-prem on the peering link

Updated routes in vTGW

Ping from SDDC to on-prem

Ping from on-prem to SDDC vCenter

Costs

All TGW costs and Data charges are described in a previous post here.

AWS TGW pricing details are here

I just wanted to highlight the inter-region peering costs:

• vTGW account is charged $0.02/GB for "inter-region egress" (Oregon to Ohio)
• AWS TGW account not charged as data is "ingress" for Ohio region 

and reverse:

• TGW account is charged $0.02/GB for "inter-region egress" (Ohio to Oregon)
• vTGW account is not charged as data is "ingress" for Oregon region

Inter region charges depends on Regions - please check this page.

Conclusion

VMware has now very strong networking capabilities with AWS TGW and VMware Managed TGW.

This is allowing very flexible design options.

Thanks for reading.