Advantages of AWS Transit Gateway (TGW) vs. Transit VPCs
You have likely heard about the AWS Transit Gateway service announced at re:Invent 2018. If you are running a Transit VPC, perhaps using Cisco CSR, you may be wondering if there are any advantages to re-architecting to use the Transit Gateway. In this article, we examine the pros and cons of this migration.
Transit VPC Background
AWS announced the Global Transit Network architecture several years ago. When it was announced, they also provided a Reference Architecture to automate the deployment using a Cisco CSR in the Transit VPC. The typical deployment looks something like this:
[source: https://aws.amazon.com/answers/networking/aws-global-transit-network]
Each spoke VPC is attached to the Transit VPC using an IPsec tunnel terminating on a Virtual Private Gateway in each spoke. Lambda functions (‘VGW Poller’ and ‘Cisco Configurator’) automate building this connectivity once a tag is added to the Virtual Private Gateway attached to the spoke. This model is also used by other vendors like Palo Alto Networks and Juniper.
A couple of years later, Aviatrix provided a different implementation for this architecture that simplified the design and provided a Controller to automate and monitor the deployment.
With this implementation, the Transit VPC and Spoke VPCs have appliances in them and an IPSec tunnel connecting them together. The centralized Aviatrix Controller simplifies the administration and management of the Transit VPC considerably and reduces the complexity of the overall design.
Migrating to AWS Transit Gateway
Migrating away from the Transit VPC to the Transit Gateway takes some preparation and a bit of downtime to accomplish. Let’s take a look at why it might be worth the extra effort and when you might want to consider staying with the Transit VPC.
Advantages to Migrating to the AWS Transit Gateway
1. Transit Gateway offers a Simpler Design
The traditional Transit VPC architecture involves a lot of components: Cisco CSRs deployed in a Transit VPC, VGWs attached to each spoke VPC, an IPsec tunnel per spoke (2 for HA), 2 Lambda functions, an S3 bucket, and BGP sessions for each spoke to transit connection.
If you are using the Aviatrix Transit VPC implementation, there are less components and less overhead; however, there are still more components than the Transit Gateway service (namely the EC2 instances in the spoke VPCs).
2. Transit Gateway is a Fully Managed AWS Service
In the traditional Transit VPC implementation (using Cisco, Palo Alto Networks, or Juniper), it is your responsibility to maintain and monitor each of the components.
Transit Gateway, on the other hand, is a managed service. HA is builtin and monitoring can be done using standard CloudWatch metrics.
If you are using the Aviatrix Controller, there is considerably less administration burden. The Controller handles all the monitoring and maintenance of the Transit VPC. HA and monitoring are included.
3. Increased Throughput
The Transit Gateway offers up to 50 Gbps of bandwidth between each VPC attachment and the Transit Gateway. With traditional Transit VPC implementations, you are limited to 1.25 Gbps.
Aviatrix offers higher throughput (up to 20 Gbps) between the spokes and transit with the additional advantage of it being encrypted.
4. Built-in, Flexible Segmentation
Segmentation can be done with separate route tables (see Q2) in the Transit Gateway.
With traditional Transit VPC implementations, you must modify the Lambda function and create VRFs to achieve this or create separate Transit VPCs.
Aviatrix supports fully isolated or fully meshed models.
Advantages to Staying with Transit VPC
1. Migration is Additional Work
Migrating to the AWS Transit Gateway is straightforward; but, it does involve planning and time to complete. There is minimal impact to the network. However, there is downtime while attaching the spoke to the Transit Gateway and disconnecting from the Transit VPC router. You can read a summary of the steps involved here on Aviatrix’s documentation site.
2. Disruption to Existing Workflow
Your current CI/CD pipeline (or other scripts used for automation) will need to be updated to reflect the change. These steps are simple but will need to be tested and validated prior to making the change.
3. New Service Requires Training Users and Administrators
This is a new service. As with any service from AWS, users and administrators will need time to read the documentation and understand how it works.
4. AWS Transit Gateway is a Black Box
There are logs and additional metrics that can help with troubleshooting. However, there is a “black box” in the Transit Gateway that might make some troubleshooting/debugging more difficult. This is true for the Cisco CSR to some degree. But, it’s even more true with the AWS Transit Gateway. If there is a problem, you can’t SSH into the Transit Gateway and perform the usual troubleshooting steps.
Aviatrix provides tools in the Controller to allow troubleshooting with traditional tools like ping, traceroute, and packet capture.
5. Full Encryption
If your business requires encryption everywhere, you may want to consider keeping the Transit VPC architecture.
Summary
There are pros and cons to weigh when considering migrating from a Transit VPC to the new Transit Gateway service from AWS.
If you are currently using a traditional Transit VPC implementation (using Cisco, Palo Alto Networks, Juniper, etc.), the decision is likely easier – it mostly comes down to whether or not you have the additional time to plan and execute and then train your team on the new service. If you are currently using Aviatrix Transit VPC, it may not be as simple of a decision. However, with the announcement of the Aviatrix Transit Gateway Orchestrator you can have the best of both worlds. Take a look at this product and let Aviatrix help you migration either implementation to the AWS Transit Gateway with Aviatrix.