See also Shared VPCs - for Production and Non Production and A Reusable Hub Spoke Model in GCP.

Why NOT use a Shared VPC as a HUB VPC (in a Hub Spoke Model) ?

When a host project is enabled, you have two options for sharing networks:

  • You can share all host project subnets. If you select this option, then any new subnets created in the host project, including subnets in new networks, will also be shared. This can lead to accidental sharing of subnets not intended for sharing.
  • You can specify individual subnets to share. If you share subnets individually, then only those subnets are shared unless you manually change the list. While offering  more control than the option above, this too can easily assign (share out) the wrong networking element with service projects.

In brief, Shared VPCs were NOT meant to serve as a centralized HUB for sharing elements (networking resources) across environments.

They were designed for sharing certain elements WITHIN the same environment - e.g. - a NAT Gateway that needs to be used by ALL service project would be shared out (i.e. the host subnet containing it would be shared out).

What about building out a Hub and Spoke VPC model?

Hub and Spoke Model - with a centralized HUB still applies to GCP. One can still build a Hub VPC and Peer any other VPCs with it. See this post for a Reusable Hub Spoke Model on GCP

Need an experienced Data Protection Expert?  Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.



Need an experienced Cloud Networking or a Cloud Data Protection Expert?  Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.