A transit VPC is a gateway architecture used to connect geographically dispersed VPCs or VNets to each other and remote networks. Transit VPCs simplify network architecture, reduce operational overhead, and minimize network traffic between the cloud service provider (CSP) and corporate data center by locating services close to the VPCs.
The Need for Transit VPC
Organizations are rapidly migrating enterprise applications and data to Google Cloud, Amazon Web Services (AWS®), Microsoft Azure® and other CSPs. Few enterprises choose to eliminate their existing data centers, instead forming hybrid clouds consisting of on-premises and CSP resources. This hybrid approach gives network managers the flexibility to dynamically balance cost, security and capacity requirements.
One issue in hybrid cloud design is deciding on a method for interconnecting VPCs. Small deployments often use a full-mesh architecture in which each VPC connects to all others as peers. As the number of VPCs grows, the number of peering connections between VPCs increases exponentially. For example, five VPCs require just 10 interconnections, but doubling the number of VPCs to 10 more than quadruples the number of connections to 45. For large enterprises with hundreds or even thousands of VPCs, the full-mesh approach is impractical.
Another potential problem is the bottleneck that occurs when organizations rely exclusively on services, especially firewalls, located in the data center. Securing VPCs in a service provider’s cloud requires significant backhaul traffic between the CSP and the data center, a configuration that is inefficient and difficult to scale. Network architects need a way to move firewall services closer to the VPCs while retaining the ability to manage the entire security fabric from a central location.
How a Transit VPC Works
A transit VPC uses a hub-and-spoke architecture in which each spoke VPC is attached to the hub transit VPC via an IPsec tunnel. For redundancy, the transit VPC contains twin virtual firewalls cross-connected to each VPC (see figure 1). The virtual firewalls inspect traffic based on local policies (e.g., only users in the IT domain can initiate FTP transfers or start remote terminal sessions). Network administrators can manage policies for the virtual firewalls from a centralized management system, avoiding the need for multiple consoles.
This gateway approach routes traffic between VPCs using transit gateway routing tables, eliminating the need for peer interconnections. The use of a transit VPC can also reduce or remove the fees many CSPs charge for VPC peering connections that cross regional boundaries.
Figure 1: Transit VPC architecture
Scaling the Transit VPC
Transit VPCs avoid the scaling problems associated with full-mesh architecture, in which the number of interconnections grows exponentially as VPCs are added. In a transit VPC architecture, each VPC requires just two connections, so the number of connections increases linearly. Virtual firewalls have a finite number of possible connections, but additional firewalls can be added as needed (see figure 2).
Figure 2: Transit VPC supporting twice the number of VPCs and virtual firewalls
Use Cases
The transit VPC architecture supports a range of important use cases, including:
Benefits
The advantages of a transit VPC architecture include:
Please visit our website for more information about transit VPC architecture.