In the realm of Google Cloud, the Shared VPC network architecture has been a staple for managing and segregating workloads across distinct VPC Networks. However, there’s an alternative approach that provides centralized management without compromising on isolation – enter the Hub & Spoke model.
Understanding the Hub VPC
At the heart of the Hub & Spoke architecture lies the Hub VPC, serving as the central nexus connected to various Spoke VPCs through peering and VPNs. This pivotal VPC houses essential network resources such as firewalls, VPN gateways, and Cloud DNS, all of which are accessible to the Spoke VPCs. It offers a streamlined way to connect with your on-premises infrastructure or bridge to other cloud providers via a singular VPC – the Hub.
Exploring the Spoke VPC
Each Spoke VPC, tethered to the central Hub VPC, operates as a separate entity that can also host its own set of network resources, including firewall rules, cloud NATs, or Cloud DNS services. Spoke VPCs can either be part of a Shared VPC or function as service projects with their own dedicated VPCs, facilitating a neat partition of workloads.
Connecting the Dots: Hub and Spoke Links
Within this structured architecture, the Hub VPC consolidates external connections, whether to on-premises networks or to other clouds, making it the focal point for setting up site-to-site VPNs or for configuring cloud DNS forwarding. The Spoke VPCs, on the other hand, specialize in segregating workloads for enhanced management and isolation.
Peering in the Hub and Spoke Model
A key differentiator in this setup is the use of VPC peering for connecting Hubs and Spokes, ensuring complete isolation while avoiding additional costs and latency, and offering full bandwidth without complex configurations. However, this method does not support transitive routing and imposes certain quotas and limits within the peering group.
Envisioning a Scenario
Imagine having a high-availability (HA) VPN setup connecting your on-premises network to the Hub, alongside two additional VPCs, each with their own set of VPN tunnels. This scenario encapsulates the essence of the Hub and Spoke model in Google Cloud.
Implementing the Hub and Spoke System
Setting up this architecture requires preliminary steps, starting with configuring your project settings:
You’ll need specific roles such as Hub and Spoke Admin and Compute Network Viewer, along with access to the Network Connectivity Center API.
Initiating the Hub
Begin by creating a network connectivity hub within your Hub project:
Configuring Spokes
Remember, you’ve already set up an HA VPN between the Hub and other projects. When creating spokes, you can enable data transfer with the –site-to-site-data-transfer flag:
Overviewing VPN Spokes
Post-creation, you can overview the existing spokes within your specified regions:
This setup allows for testing connectivity from on-premises to any VM within the spoke VPCs, or even between the spokes themselves, showcasing the flexibility and efficiency of the Hub and Spoke model in Google Cloud.
Interested in elevating your cloud infrastructure with the Hub & Spoke model or seeking expert advice on Google Cloud solutions? Connect with the Oredata team to explore how our tailored cloud and DevOps services can empower your business to reach new heights.
Author: Azir Güleroğlu, Staff Cloud&Devops Engineer at Oredata