Virtual private clouds (VPCs) are becoming the foundation for using Amazon Web Services (AWS) and other public clouds. Each VPC represents a virtual network that’s much like a data center network, except that VPCs can be created in seconds. Because VPCs are so easy to create, they’re proliferating in many organizations.

As your VPC numbers grow, however, so do your challenges in connecting, securing, and managing them all. Once you exceed more than 10 VPCs with on-premises site and cloud connectivity requirements, the traditional point-to-point virtual router network becomes a pain to manage.

If you’re connecting multiple spoke VPCs to on-premises data center resources, one of the AWS-recommended approaches is a global transit network. The advantage of a transit network is that you need to build only a single connection with your on-prem resources; the subsequent spoke VPCs can connect to on-prem automatically without going through another change-control process.

The Need For a Next-Generation Transit Hub VPC

One requirement for a transit network is building connectivity from spoke VPCs to your on-premises data center. For example, say you want to perform a lookup in Active Directory (AD) or enable a cloud workload to access a database deployed on premises. Currently, if you have multiple VPCs that need connectivity, you have two main architectural choices: a hub-and-spoke topology or a meshed network.

At one extreme, you can build a meshed network with n-squared individual connections, with ‘n’ being the number of VPCs. At the other extreme, a hub-and-spoke topology reduces the number of connections to n-1. The advantages of a hub-and-spoke approach include:

  • Simplifying your network by reducing the number connections to build and manage.
  • Greatly improving overall cloud agility because networking in a new spoke is much faster than adding another node on a meshed network.

AWS can’t help you build your hub-and-spoke transit hub because it doesn’t provide transitive routing natively in its public cloud platform. Instead, AWS recommends that enterprises turn to AWS Network Competency partners for next-generation transit VPC solutions.

Increasingly, cloud engineers and DevOps teams are involved in provisioning, troubleshooting, and scaling AWS networking themselves. Moving at cloud speeds, they are comfortable with treating infrastructure as code. And they want to apply a similar concept to cloud and transit networking.

An ideal next-generation transit hub redefines AWS transit networking by delivering the network as code, rather than as a virtualized instance of a data center router. As a result, cloud teams get the networking capabilities they need for AWS minus the manual configuration; including the complexity of border gateway protocol (BGP), command-line interfaces (CLIs), and other arcane networking protocols; and the provisioning delays introduced with traditional router offerings, which were designed for the data center rather than the public cloud.

Key Features of a Next-Gen Transit Hub

Here are some considerations and key features to seek when evaluating next-generation transit hub solutions:

  • Software-defined, with centralized management. A next-gen transit hub should enable anyone, including non-network engineers, to automate networking. Look for a point-and-click management console with Terraform and CloudFormation support that automates the network coding and processes that currently only highly skilled network engineers can figure out.
  • Security by default. Your next-gen transit hub solution should implement VPC segmentation by default, with VPC-to-VPC and VPC-to-data center connectivity occurring only when specified by policy. Additionally, ensure security integration with the transit architecture through encrypted links, an integrated stateful firewall for policy enforcement, and fully qualified domain name (FQDN) filtering.
  • AWS cloud native. Make sure the solution is based on REST APIs for integration with other modern third-party tools.
  • Simplified troubleshooting. Onboard diagnostic tools make troubleshooting much easier, allowing you to identify EC2 connectivity problems faster to minimize business downtime.
Options for Establishing a Transit VPC

As offered by AWS Networking Competency Partners, a next-generation transit hub, or transit VPC, is provided as a virtual private network (VPN)-based solution. You have three main options for a transit VPC:

Option 1: Manual configuration of an AWS Partner virtual router in the hub, with either an AWS virtual gateway (VGW) or AWS Partner virtual router in the spokes.

This approach involves installing a virtual router and logging into its command line to configure an IPsec VPN — which is supported by many traditional networking and firewall vendors — from the hub to each spoke.

As a termination point, the spoke VPCs can use either an AWS VGW or another virtual router. An AWS VGW can be easier to configure, but it requires management of each VPC’s security groups to segment traffic.

Because it’s a manual process, this option tends to be the most difficult and time-consuming for setting up and managing a transit VPC. Additionally, troubleshooting can be highly challenging if you don’t know BGP. On the other hand, if you have the patience and at least a couple of people with deep networking skills, this options lets you build whatever you want.

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

This option uses a combination of CloudFormation scripts to deploy a transit VPC and a Lambda poller that automatically adds spoke VPCs to the transit networking using simple resource tags.

A number of networking and security vendors offer this type of solution — but almost all of them use BGP to exchange routing information. As with the first option, troubleshooting can be challenging if you’re not steeped in traditional networking fundamentals. An alternative is to use a next-gen transit hub approach that doesn’t require BGP everywhere.

Once the transit VPC is in place, extending beyond the AWS Cloud requires manual configuration of on-premises connections — unless you choose a cloud-native networking solution that includes a wizard to automatically configure an existing on-premises direct connect VGW.

The out-of-the-box default on the vast majority of vendors’ offerings is any-to-any connectivity via automated scripts. This open-by-default connectivity presents potential security issues. The alternative is to opt for a solution that allows you to configure network traffic segmentation, so you can control what connects to what.

Option 3: Centrally managed and automated AWS Partner virtual routers.

The ideal next-gen transit hub solution provides a centrally managed transit VPC with a GUI that makes it easy to set up, configure, and manage a transit VPC. If the central controller is based on a REST API, you can use infrastructure-as-code practices to build and maintain your transit VPC with Terraform, PHP code, and CloudFormation.

This option enables non-network engineers to manage a transit VPC using software-defined routing instead of BGP, in all connections except the single on-premises connection.

Putting VPC-to-Data Center Connectivity Into Cloud Teams’ Hands

Ideally, you want your networking functionality to become part of the cloud and DevOps stack, orchestrated in the same way as other cloud and DevOps tools — with change control, Terraform automation, revision control, documentation, and testing all built into the process.

In the right next-generation transit hub, time-consuming activities such as network provisioning, encryption, routing configuration, maintenance updates, and troubleshooting are no longer complex, error-prone, or dependent on teams with deep networking skills. As a result, your cloud teams can build connectivity according to their team’s schedule, rather than being subject to the networking team’s whims.