Hub Spoke GCP

Also read,  A Shared VPC versus HUB VPC in GCP

and IAM and VPC Service Controls - a 2 minute security solution on GCP

Combine a HUB (Custom) VPC with a Shared VPC (one for each environment).

What is in the HUB?

  • The hub is a custom VPC and peered to the spokes, which are Shared VPCs.
  • The Hub VPC is connected with on-premise through a static VPN connection or a cloud Interconnect.
  • The hub VPC is isolated from the public Internet (using VPC Firewall rules).
  • Network services can be centrally administered within the hub. These services include connectivity to the spokes as well as to on-premises data centers.

What is in each Spoke?

  • Each Spoke is a VPC (custom or default - doesn't matter). Spokes are automatically isolated as VPC peering is non-transitive.
  • Within each spoke, isolation between workloads is created using VPC Firewall rules.

How does a Spoke and the Hub Interact?

  • Spokes are connected to the hub with VPC peering (extremely low latency).
  • For creating a path between a spoke and the on-premises environment, create custom routes. These routes need to be exchanged (between the hub and each spoke).

 

hub spoke GCP
hub spoke GCP

What does the folder structure look like for such a network design?

Folder structures can be driven by organizational departmental hierarchies or by network topology.

In my experience, network design (and environment segregation) are the drivers behind folder  structures.

Summary

The Shared Host VPC is often used as the Hub and Service Projects as Spokes. This isn't ideal - especially if the spokes are ENVIRONMENTS (production and non production). This will couple environments through the hub and an accidental IAM permission on the HUB (Shared VPC Admin) would enable a NON PRODUCTION admin to get to PRODUCTION resources.

A better solution is to use the traditional Hub Spoke design along with Shared Host VPCs for each of the spokes, as described in this post.