Is AWS Transit Gateway Right for You?

Here's what you need to know before migrating to the new connection paradigm.

When AWS announced Transit Gateway last November at re:Invent, it caused quite a stir. And rightfully so. While it provides much-needed routing and connectivity functionality, Transit Gateway is a big departure from Transit VPC architecture.

Many customers we speak with are interested in replacing their Transit VPC architecture with the new Transit Gateway, but many aren't sure where to start with the architectural change that the move requires.

The backstory of Transit Gateway

First, it's good to know just how Transit Gateway came about. It was born because AWS had no native network construct to connect multiple VPCs and On-Premises sites and control traffic between them.

Peering is wonderful, but it just doesn't scale well. We would do the math for you, but just take our word for it. Consider this diagram of an architecture with only five VPCs before implementing something like Transit VPC or Transit Gateway.

VPC architecture design

While Transit VPC addresses the complexity of managing multiple site-to-site VPN connections back to the OnPrem and controls the traffic between the VPCs, it has bandwidth limitations, relies on third-party devices, IPSec, VPNs, BGP, Lambda functions, S3 buckets, etc.

Transit VPC architecture design

It's not the most efficient way to route and control traffic in AWS, but it's what AWS with Partners came up with to get the job done.

Recognizing the scaling and complexity issues of Transit VPC, AWS gave us Transit Gateway.

Transit Gateway really does address the complexity, limitations and restrictions of Transit VPC. But, how do you know if Transit Gateway is right for you?

Here, we'll explore what exactly Transit Gateway is; the pros and cons of moving away from Transit VPC; and the steps involved in a Transit Gateway migration.

Reasons to migrate to AWS Transit Gateway

AWS Transit Gateway is a simple AWS Native Networking construct which gives the cloud architect complete control of traffic. Not only does it enable efficient connectivity and routing within AWS (VPC to VPC) but also to on-site data centers and remote locations, making it a key construct when we consider hybrid cloud connectivity.

What's also nice is that because Transit Gateway is a native AWS solution, monitoring, high-availability and maintenance are already built in. Plus, Transit Gateway increases security with the ability to efficiently route traffic through security zones and isolate and control traffic through multiple route tables.

AWS Transit Gateway architecture

Another big driver for Transit Gateway is scale.

Additional VPCs and connections can be added very quickly to the Transit Gateway and can be easily automated.

Up to 5,000 VPCs can be added to the Transit Gateway giving a single point of connectivity for all VPCs and remote connections from data centers and branch offices. This means you get a central point of control for all your traffic.

VPCs "attach" to the Transit Gateway at 50Gbps and can be associated with one of many route tables depending how you want to control traffic. Single VPNs can be attached to the Transit Gateway at 1.25Gbps and can be combined using ECMP to provide combined bandwidth that has been tested up to 50Gbps.

When the Transit Gateway is setup with default settings all VPCs are associated to the default route table. Everything can route traffic to everything. However, by utilizing different route tables (currently limited to 20 per Transit Gateway) and associating VPCs to them we can create separate routing domains, which allow us interesting design patterns such as outbound and edge security controls and segmentation.

Reasons to stay with a Transit VPC design

If you are happy with your existing Transit VPC architecture and it's meeting your requirements, you may not want to change it.

Migrating to the AWS Transit Gateway requires thought, research and planning.

Transit Gateway is a regional construct and while inter-region connectivity is on the road map, you might want to hold off with migration if your VPCs are located in multiple different regions and need connectivity via the Transit Gateway.

If you migrate from Transit VPC to Transit Gateway, you'll have to plan how to move your existing VPC connections from the Transit VPC to the Transit Gateway.

This will take some time to think through. Much of this can be automated, but migration can cause downtime. Successful migration or implementation will require you to change your existing automation to work with Transit Gateway.

The risk of downtime during migration is directly proportional to the amount of planning. Better planning and automation result in less — and possibly no — down time.

Really, it boils down to the fact that change can be difficult. This change includes actually doing the work to move to a new architecture, but it also includes learning new skills: Transit Gateway is a new way of doing things. You should consider that training, documentation and operational procedures will be a bit different.

Migrating from Transit VPC to Transit Gateway

Migration from the Transit VPC to Transit Gateway is a pretty straight-forward process, however it does require some preparation. Here, we go over the procedures and steps for migration.

Step 1: Document Transit VPC setup

Transit VPC initial stage setup

Three VPCs connect back to the VPN appliances in the Transit VPC. On-prem is also connected via the VPN to these appliances. You'll want to document existing configurations such as VPN appliances, routing settings, etc.

I'd recommend that you plan for segmentation via Routing Domains in Transit Gateway, but it's not required if connectivity needs to be migrated as is.

Lastly, before moving on, you'll want to document the required configuration changes for the VPCs Route Tables.

Step 2: Set up Transit Gateway

Transit Gateway can be launched in parallel to the Transit VPC and establish VPN tunnels and BGP sessions to the VPN Appliances in the Transit VPC, as shown below.

Transit Gateway setup with Transit VPC

Transit Gateway integrates with Resource Access Manager, which means that VPCs from different accounts can be connected to it.

This might be a good time to review the accounts strategy and determine which account is going to manage networking configuration.

Step 3: Move spoke VPCs to Transit Gateway

From here, you'll want to attach the spoke VPCs to the Transit Gateway. What's nice about this step is it can be done without downtime.

One subnet per availability zone needs to be specified for the attachment. Then, during the maintenance window, VPC route tables will have to be updated to route the traffic to Transit Gateway attachment instead of VGW.

Spoke VPCs to Transit Gateway

STEP 4: Move on-prem connections to Transit Gateway

To complete the migration, you'll want to move on-prem connectivity to Transit Gateway.

Just so you know, Transit Gateway supports ECMP VPN, which means you can provision more than one tunnel between On-Prem and AWS for greater bandwidth.

Do note that native Direct Connect is not supported with the Transit Gateway at the time of this article, but it can be used to establish the VPN tunnels using the public VIFs.

On-prem connections migration

Conclusion

The Transit Gateway solves complexities of implementing hybrid connectivity between on-prem and multiple VPCs. Cloud architects gain more control of their networks, and organizations can scale at the pace of traffic demands.

For more on AWS Transit Gateway and other topics related to cloud networking, request a Cloud Networking Workshop.