Shared VPC
A configuration where one Project (the host) owns a VPC network, while other Projects (service projects) attach to it and deploy resources using its subnets. This centralizes network administration in the host Project while letting individual teams in service Projects still manage their own resources independently.
Frequently Asked Questions
Why would an organization use Shared VPC instead of giving every GCP project its own VPC?
Shared VPC centralizes IP address management, firewall rules, and network topology in one host project, avoiding IP overlap and inconsistent security policy across dozens of team-owned projects. Service project teams still get to deploy their own VMs, GKE clusters, and other resources — they just consume subnets from the host rather than owning the network. This is the standard pattern for large GCP orgs that need one network team but many independent product teams.
What's a common pitfall when setting up Shared VPC?
Under-provisioning subnet IP ranges in the host project — since resizing a subnet's CIDR after resources are deployed is disruptive, and service projects can't create their own subnets, a too-small range forces a painful migration later. Also, granting service project admins the `Network User` role at the project level instead of per-subnet gives them access to subnets they shouldn't touch; scope it to the specific subnet resource instead.