What are my options for a Transit VPC?

If you have many VPCs that need connectivity, a hub-and-spoke topology can simplify your network with a reduced number of connections to manage. At the extreme, a meshed network would have n-squared individual connections, with n being the number of VPCs. At the other extreme, a hub-and-spoke would reduce the number of connections to n-1. Also a hub-and-spoke topology can greatly improve overall cloud agility; networking in a new spoke is a lot faster than adding another node in a mesh network. Sounds good, right?

But AWS doesn’t natively support the transit peering needed to implement a hub-and-spoke network (a Transit VPC) and instead AWS recommends Partner vendors to provide a VPN-based solution*. There is an ecosystem of vendors who offer Transit VPCs on the AWS Marketplace, so how do you compare and decide? We’re here to help.

Your options can be categorized into:

1. Manual configuration of Partner virtual routers
2. Automated scripts with a Partner virtual router in the hub with an AWS VGW in the spokes
3. Centrally managed and automated Partner virtual routers

Option 1: Manual configuration of Partner virtual routers in the hub with either an AWS VGW or Partner virtual router in the spokes

This involves installing a virtual router and logging into its command line to configure an IPsec VPN from the hub to each spoke. The spoke VPCs can either utilize an AWS VGW as a termination point or another virtual router. Many traditional networking and firewall vendors support IPsec VPN. An AWS VGW can be easier to configure but will require management of each VPC’s security groups to segment traffic.

As this is the manual option, this tends to be the most difficult and time-consuming of all the options to set up and manage a Transit VPC. On the other hand, if you have the patience and at least two people with deep networking skills, it lets you build whatever you want. Troubleshooting can be highly challenging if you don’t know Border Gateway Protocol (BGP).

Option 2: Automated scripts with a Partner virtual router in the hub with an AWS VGW in the spokes

This option uses a combination of a CloudFormation scripts to deploy a transit VPC and a Lambda poller which automatically add spoke VPCs to the transit network using simple resource tags. Cisco, Aviatrix and other networking and security vendors offer this type of solution. Other than Aviatrix, all other solutions utilize BGP to exchange routing information. In that case, troubleshooting can be challenging if you’re not steeped in traditional networking fundamentals. Once the transit VPC is in place, to extend beyond the AWS Cloud, on-premises connections need to be manually configured. Aviatrix 3.1 however has a wizard to automatically configure an existing on-premises Direct Connect VGW. On the security side, all of these automated scripts provide out of the box any-to-any connectivity, so they are open by default. Aviatrix can easily be configured to segment the traffic via the centralized controller, see the docs here.

Option 3: Centrally managed and automated Partner virtual routers

Aviatrix is the only AWS Marketplace solution today which provides you with a centrally-managed Transit VPC. After installing the Controller from the AWS Marketplace, you can easily set up, configure, and manage a transit VPC via the GUI. As the controller is REST API-based, you can use Infrastructure as Code practices to build and maintain your transit VPC with the Terraform Provider on our GitHub account. We also have PHP code and CloudFormation available.

The Aviatrix solution is easy for non-network engineers to manage a transit VPC. It uses software defined routing instead of BGP in all connections except the single on-premises connection. For security, Aviatrix segments the network traffic by default using policy-based stateful firewalling. Aviatrix 3.1 also includes a wizard to automatically configure an existing on-premises Direct Connect VGW.

Other Transit VPC Considerations

Shared Services VPCs

The Transit VPC is a first major step of your evolving cloud network. Shared Services VPC Hubs can be added to the Transit VPC to create a network which employs direct spoke-to-spoke links using peering (without BGP) for all cloud-to-cloud traffic.

Security in the Transit Network

The hub-and-spoke network can represent a choke point at the hub. On the upside, it can be used to inspect all traffic. On the downside, the hub can be a performance bottleneck. To get the best of both worlds’ Aviatrix recommends using a transit hub for on-prem traffic, which would be inspected on-prem and a separate shared security VPC hub for spoke to spoke & spoke to internet traffic.

Most of the above have been focused on technology, operations, and skillsets. You may also consider that at the 2017 Re:Invent conference AWS named Aviatrix and Palo Alto Networks as the first Partners to achieve the Networking Competency for Connectivity.

*Why AWS doesn’t support transit, a quick explanation:

AWS VPC routing will not allow routing traffic whose source or destination does not have an interface in the VPC. This is a current VPC routing limitation.

This is the reason why transitive peering using the native AWS peering will not work; the hub will receive traffic whose source or destination will not be from/to an interface in the hub VPC.

If you use a VPN Instance in the hub VPC and setup VPNs (instead of native peering) to the spokes, then the source or destination will have an interface in the hub VPC, which are the tunnel Interfaces for the VPNs in the hub.