Overview and What You Will Learn
In this lab, you will designate one project as a Shared VPC host, attach a second project as a service project, and create a VM in the service project using the host's subnet - directly experiencing how network ownership and resource ownership can be split across two separate projects.
Why This Matters in Production
A platform team wants centralized control over IP address planning, firewall rules, and network security across the whole company, but each product team still needs the autonomy to deploy their own VMs and services without waiting on the platform team for every single resource. Shared VPC solves exactly this organizational tension - one project owns the network, many others use it.
Core Principles
Shared VPC lets one project (the "host" project) own the VPC network, while other projects (the "service" projects) attach to it and create resources using its subnets - centralizing network administration while letting individual teams still manage their own project's resources independently.
+------------------------------------------+| Host Project || Owns the VPC, subnets, firewall rules, || and routing |+------------------------------------------+ | | v v+------------------+ +------------------+| Service Project A | | Service Project B || Deploys VMs using | | Deploys VMs using || the host's subnets | | the host's subnets |+------------------+ +------------------+Crucially, IAM permissions in the service projects control who can deploy resources there, while IAM permissions in the host project separately control who can actually modify the network itself - these are two genuinely independent permission boundaries.
Detailed Step-by-Step Practical Lab
- Create two projects - one to act as the host, one as a service project:
gcloud projects create network-host-2026 --name="Network Host"gcloud projects create team-checkout-2026 --name="Checkout Team"- Enable the Compute Engine API on both, and enable one as a Shared VPC host:
gcloud services enable compute.googleapis.com --project=network-host-2026gcloud services enable compute.googleapis.com --project=team-checkout-2026 gcloud compute shared-vpc enable network-host-2026- Create a VPC and subnet in the host project:
gcloud compute networks create vpc-shared \ --project=network-host-2026 \ --subnet-mode=custom gcloud compute networks subnets create subnet-shared-asia-south1 \ --project=network-host-2026 \ --network=vpc-shared \ --region=asia-south1 \ --range=10.0.1.0/24- Attach the service project to the host:
gcloud compute shared-vpc associated-projects add \ team-checkout-2026 \ --host-project=network-host-2026- Grant the service project's team the ability to actually use (not modify) the shared subnet:
gcloud projects add-iam-policy-binding network-host-2026 \ --member="group:checkout-team@example.com" \ --role="roles/compute.networkUser" \ --condition="expression=resource.name.endsWith('subnet-shared-asia-south1'),title=checkout-subnet-only"- Create a VM in the service project, using the host project's shared subnet:
gcloud compute instances create vm-checkout-service \ --project=team-checkout-2026 \ --zone=asia-south1-a \ --machine-type=e2-medium \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=projects/network-host-2026/global/networks/vpc-shared \ --subnet=projects/network-host-2026/regions/asia-south1/subnetworks/subnet-shared-asia-south1- Confirm the VM was created successfully in the service project, using the host's networking:
gcloud compute instances describe vm-checkout-service \ --project=team-checkout-2026 \ --zone=asia-south1-a \ --format="value(networkInterfaces[0].network)"- Clean up:
gcloud compute instances delete vm-checkout-service --project=team-checkout-2026 --zone=asia-south1-a --quietgcloud compute shared-vpc associated-projects remove team-checkout-2026 --host-project=network-host-2026gcloud compute networks subnets delete subnet-shared-asia-south1 --project=network-host-2026 --region=asia-south1 --quietgcloud compute networks delete vpc-shared --project=network-host-2026 --quietgcloud projects delete network-host-2026 --quietgcloud projects delete team-checkout-2026 --quietProduction Best Practices & Common Pitfalls
Common MistakeGranting the
roles/compute.networkUserrole broadly across the entire host project rather than scoped to a specific subnet. This lets a service project's team deploy resources into any subnet in the shared network, not just the one intended for their team, undermining the network segmentation Shared VPC was meant to provide.
TipUse IAM Conditions (as shown in step 5) to scope the Network User role to a specific subnet by name, rather than granting blanket access to every subnet in the host project. This keeps each team's actual network access limited to exactly the subnet meant for them.
- Only the host project's administrators can modify the VPC, subnets, or firewall rules. Service project teams get to deploy resources into the shared network, not redesign the network itself - this separation of concerns is the entire point of the feature.
- A project can only be a service project for one host project's Shared VPC at a time. Plan the host/service project structure deliberately upfront, since changing which host a service project is attached to is a disruptive operation, not a casual reconfiguration.
Quick Reference & Troubleshooting Commands
| Command | Description |
|---|---|
gcloud compute shared-vpc enable |
Designate a project as a Shared VPC host |
gcloud compute shared-vpc associated-projects add |
Attach a service project to a host |
gcloud projects add-iam-policy-binding --role="roles/compute.networkUser" |
Grant subnet usage rights to a service project's team |
gcloud compute shared-vpc associated-projects remove |
Detach a service project from a host |