Connecting SDWAN fabric to AWS is now more scalable and secure

I had the opportunity to attend AWS re:Invent this month where my focus was specifically on networking and content delivery track. These 30 minute short sessions from AWS networking experts that ranged from customer case studies to technical best practices. These are similar to breakout sessions at Cisco Live that can augment your existing knowledge on some complex technical topics.

One of the announcement from AWS on the networking track this year is the Transit Gateway Connect (TGW Connect) service which further secures and scales the connectivity from the SDWAN fabric (branches and data center) to the AWS cloud. Before this service, customers had to build IPSEC tunnels between the virtual appliances (e.g.,vEdge) within the AWS Transit VPC to the Transit Gateway and then to connect with the VPCs. The two main drawbacks with IPSEC methods were the bandwidth limitation (1.25Gb per IPSEC tunnel) and security (leveraging the public IP’s on either side of the tunnel). The new Transit Gateway Connect features overcomes this limitations by allowing to establish BGP over GRE tunnels between the Transit Gateway and the virtual appliances (e.g.,vEdge) placed within the Transit VPC through private IP addresses. On top of this, the combined throughput per Transit Gateway Connect attachment is upto 20Gbps. The below diagram compares both the connectivity models.

AWS has certified more than a dozen of SDWAN vendors virtual appliances that can work with the new Transit Gateway Connect service and they include 128 Technology, Alkira, Arista Networks, Aruba, Aryaka, Aviatrix, Cisco, Citrix, Fortinet, Palo Alto Networks, Silver Peak, Sophos, and Versa Networks. More details can be found on this blog from SDX central.

What is an ‘Gateway Attachment’ BTW ?

Its important to understand the difference between a Transit Gateway and a Transit Gateway attachment. Within the AWS realm, an attachment is an entity with resources. This can be a VPC attachment where EC2 (Compte) resources are hosted or a VPN attachment where on-prem compute resources are hosted. Then a Transit Gateway takes care of routing traffic between these attachments. Transit Gateway functionality is similar to a transit AS in the BGP realm, its job is to exchange routing traffic between different attachments (VPC, VPN, DX or Connect). Transit Gateway Connect attachment is this new type attachment which made it to the announcement. If you refer to the above diagram, the existing solution has an VPN attachment and the new solution has the Transit Gateway Connect attachment.

How is higher throughput achieved by TGW Connect Attachment?

Although AWS do not publish how the higher throughputs are achieved with the new Transit Gateway Connect attachment, I suspect that there is some sort of private MPLS backbone network which is being leveraged in-between. Leveraging GRE with private addressing with BGP on the top could further confirm the existence of this private network.

For more details on BGP over GRE setup and the configuration you can refer to the AWS documentation here.

This AWS blog also provides additional perspective on the solution.

Refer to Cisco announcement here

Leave a Reply

Scroll to top
%d bloggers like this: