The Enterprise’s Guide to AWS Direct Connect and Transit Gateway

The Enterprise’s Guide to AWS Direct Connect and Transit Gateway

Demystifying Direct Connect and Transit Gateway so you can better understand your AWS networking capabilities.

How AWS Virtual Private Cloud (VPC) Peering Options Have Evolved

Ever since AWS Direct Connect launched in 2012, organisations have been embracing dedicated connections to their cloud services—they gained the ability to improve their overall data transfers, increase their network performance, and enhance their data privacy when connecting to AWS. With the introduction of an array of new service features and enhancements, the options for peering with AWS have certainly evolved. Let’s take a look at how this has developed and how you can take advantage of some of the features available.

Launching AWS Direct Connect

Back when Direct Connect launched in 2012, connecting to AWS via Layer 2 with Megaport required a VXC that connected to a Virtual Interface (VIF) on the AWS side. At Layer 3, you were required to connect the L2 component to an L3 construct which required establishing a Virtual Private Gateway (VGW). A VGW is the routing target on AWS that connected the VXC through to each VPC. Each AWS VPC and Megaport VXC required 1:1 mapping including separate Border Gateway Protocol (BGP) sessions and VXCs/VIFs to each VGW.

Introducing Direct Connect Gateway

In 2017, AWS released Direct Connect Gateway (DXGW), which gave customers the ability to establish one BGP session for up to ten distinct VPCs within a single AWS account. The service matured over time from ten VPCs from a single account in a single AWS region, then expanded to support connectivity across AWS regions and, most recently, extended across multiple regions and multiple AWS accounts. DXGW also signalled the move from a single standard AWS ASN (7224 in most regions) to a customer defined ASN in the private ASN range (64512 to 65534). VGWs and DXGWs still exist as options for customers with Private VIF peerings today.

It was still possible to peer VPCs (even across accounts/regions) within AWS, however where a DXGW was used, it was only possible to peer from the VIF to the ‘next directly connected’ VPC, and not between VPCs that were not adjacently peered.

Direct-Connect-Gateway

In this diagram, assume that VPC ‘A’ is linked directly to a VXC/VIF (via VGW or DXGW), and although VPC ‘B’ and ‘C’ are peered to VPC ‘A,’ they may not communicate directly with the VIF. This is known as Transitive Routing. Some customers would run a virtual appliance (router) in VPC A to work around this constraint (informally known as a ‘Transit VPC’), however, overall design brought with it some complexities.

Transit Gateway: Topology and Overview

Transit-Gateway-Topology

In late 2018, AWS launched Transit Gateway (TGW). A TGW allowed a ‘full mesh’ of routes to be passed between VPCs and VPN terminations that were not reliant on the VPC peering (with its transitive routing limitations), providing the ability to connect thousands (up to 5000) of VPCs and on-premises networks together, across multiple accounts to a single gateway.

Initially, a TGW was only accessible by customers to connect to associated VPCs via the AWS provided IPSEC VPN service. At launch, this was announced in the following regions: US East (Virginia), US East (Ohio), US West (Oregon), US West (Northern California), EU (Ireland), and AsiaPacific (Mumbai). It has now expanded to include the above as well as AWS GovCloud (US-West), Canada (Central), South America (São Paulo), Africa (Cape Town), EU (Stockholm), EU (London), EU (Frankfurt), EU (Paris), EU (Milan), Middle East (Bahrain), Asia Pacific (Hong Kong), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Seoul), Asia Pacific (Sydney), Asia Pacific (Beijing), Asia Pacific (Ningxia) regions. This is current as of August 2020.

Transit Gateway for Direct Connect

Transit Gateway for Direct Connect support was announced on 30th April 2019. There are two models customers can use via Direct Connect: Dedicated and Hosted Connection supporting 1, 2, 5, and 10Gbps connections to connect via Direct Connect to TGW.

Connecting with Transit Gateway via Megaport

When TGW via Direct Connect launched, network partners like Megaport connected customers to AWS via the following models: dedicated connections, hosted connections 50 to 500Mbps, and Hosted Virtual Interfaces (VIF). Megaport uses and still supports AWS via the Hosted VIF model. Hosted VIFs allow Megaport to provide customers with flexibility and scalability when connecting to AWS, which include scaling bandwidth in increments of 1Mbps to 5Gbps VXCs where, previously, partners delivering hosted connections were limited to a maximum of 500Mbps per VIF.

On 19th March 2019, AWS announced higher capacity for Direct Connect partners using the Hosted Connection model including higher bandwidth options above 500Mb, supporting higher speed options of 1, 2, 5, or 10Gbps. While Megaport still offers customers the ability to deploy Hosted VIF solutions supporting private and public VIFs, customers also have the flexibility via the same Megaport portal to implement Hosted Connections from 50Mbps to 500Mbps and at the higher tier connections of 1, 2, 5 or 10Gbps required to support Transit Gateway. Currently Megaport has over 20 on-ramp locations enabled with Hosted Connection around the globe, providing customers with more options to reach the AWS network with low latency from their data centre with geographically diverse connections.

Factors to Consider

Please note there are some factors to consider when choosing Megaport’s AWS Direct Connect Partner models Hosted VIF vs Hosted Connections.

  • Private VIFs via Hosted VIF model do not natively support Transit Gateway via Direct Connect.
  • Hosted Connections are a 1:1 subscription dedicated capacity to the customer between AWS and Megaport. This model is recommended by AWS for production and critical workloads.
  • TGW support is reliant on hosted connection providers supporting a minimum of 1Gbps service offering. Creating a Transit VIF requires a customer to provision a 1Gbps or greater Hosted Connection. Lower tier Hosted Connections 50Mbps to 500Mbps will not support creation of Transit VIFs required to support Transit Gateway.
  • Customers deploying one Hosted Connection can create one VIF per Hosted Connection. Via 50Mbps to 500Mbps, customers can create one Private or one Public VIF. Selecting a 1Gbps to 10Gbps Hosted Connection customers can create one Private, Public, or Transit VIF.

Options for Customers over Direct Connect with Sub 1Gbps Requirements

When a customer would like to promote their TGW to be accessible over a Direct Connect sub 1Gbps, it is possible (in all regions) to use a Public VIF (Hosted VIF or Hosted Connection) across a Megaport VXC service. The AWS IPSEC VPN service via Public VIF will require you to use either your own public IP space to perform the public peering, or you can use Megaport Cloud Router (MCR) to provide the public peering IPs and NAT this back across a VXC that uses RFC1918/private IP space. Traffic will be end-to-end encrypted and also subject to a maximum throughput of 1.25Gbps (AWS VPN limitation). Here is additional information from AWS on this configuration AWS Sub 1G TGW Public VIF.

Watch for updates and we continue to expand our AWS Hosted Connection locations to provide customers additional options to AWS network on-ramps, giving Megaport enterprise customers the optimal path to access their workloads in the cloud with low latency and strategic geographical proximity.

AWS Transit Gateway: what is it and how does it work?

Hosted Connection: New speed and support announcement

Contributors:

Matt Simpson, VP Cloud, Megaport
Jason Bordujenko, Head of Solutions, APAC, Megaport
Mike Rockwell, Head of Solutions, Megaport


NOTE: This is an update of a post previously published on June 12, 2019.

Matt Simpson
Vice President, Cloud Product at Megaport