Shared VPC in GCP Explained: Host Projects, Service Projects, and Use Cases

What is Shared VPC?

In GCP, every project can have its own VPC network. By default, those networks are completely separate. Shared VPC changes that by designating one project as a host project that owns the VPC, and letting other projects (called service projects) attach to it and deploy resources directly into its subnets.

The resources a service project creates, such as VMs, GKE clusters, and Cloud Run jobs, live in the service project for billing and IAM purposes. Their network interfaces, however, connect to subnets that belong to the host project. The result is that dozens of teams can deploy into one coherent IP space, with one team responsible for how that space is structured and secured.

This is not just a convenience feature. For organisations that need consistent firewall policy, controlled IP address management, and a clean boundary between who deploys applications and who manages the network, Shared VPC is the designed solution.

The problem Shared VPC solves

In a growing GCP organisation, the natural default is for every team to create their own project and their own VPC. That gives teams autonomy, but creates several problems that compound as the organisation grows:

• Overlapping CIDR ranges. Different teams independently pick subnet ranges like 10.0.0.0/16, and before long every VPC uses the same addresses. Connecting those VPCs later via VPC peering becomes impossible because peering requires non-overlapping ranges across both sides.
• Firewall sprawl. Each team writes their own firewall rules. Security baselines drift. One project allows SSH from 0.0.0.0/0; another blocks all external traffic entirely. Auditing becomes difficult, and enforcing a consistent policy requires tooling rather than architecture.
• Peering limits. VPC peering caps out at 25 connections per VPC. Once an organisation has enough teams, a full mesh of peering connections is not feasible. Peering is also non-transitive, which means a central “hub” VPC cannot pass traffic through to connected spokes.
• Routing inconsistency. On-premises connectivity via Cloud VPN or Cloud Interconnect is typically configured in one project. Giving every team’s VPC access to that connectivity requires peering or duplicating the setup, and neither scales cleanly.

Shared VPC addresses all of these at once by making the network a shared resource that the organisation controls centrally, rather than a project-level concern that each team manages independently.

How Shared VPC works

The architecture has three moving parts: the host project, the service projects, and the IAM bindings that control which service project can use which subnet.

The host project

The host project is a regular GCP project that has been enabled as a Shared VPC host. Once enabled, it owns the VPC network, all subnets, firewall rules, Cloud Routers, VPN tunnels, and Interconnect attachments. It is the single source of truth for all network configuration. The team that manages the host project is responsible for IP address planning, routing policy, and access control at the network level.

Service projects

A service project is any GCP project that has been attached to a host project. Once attached, users and service accounts in the service project can create resources (Compute Engine VMs, GKE clusters, Cloud Run services) that connect to subnets in the host project’s VPC. From a billing perspective, the resource belongs to the service project. From a networking perspective, it sits inside the host project’s network.

A project can only be attached to one host project at a time, and a project cannot be both a host project and a service project simultaneously.

Subnet-level IAM

Access to the shared VPC is granted at the subnet level, not the VPC level. The host project administrator grants service projects (or specific service accounts and user groups within them) the roles/compute.networkUser role on individual subnets. A production team might have access to prod-subnet but not dev-subnet. A staging environment can be confined to its own range. This granularity is what makes Shared VPC usable for organisations with multiple teams and environments sharing one VPC.

The principle of least privilege applies directly here: grant each service project exactly the subnets it needs, nothing more.

Resource ownership and billing

When a developer in a service project creates a VM that connects to a shared subnet, the VM itself (its identity, its IAM bindings, its Compute Engine costs) belongs to the service project. The network interface is in the host project’s VPC, but nothing about the VM’s ownership or billing changes. This boundary keeps financial accountability with the team that owns the workload.

Host project vs service project: responsibilities at a glance

The clearest way to understand the split is to ask: who owns the network, and who owns the workload? The host project owns the network. The service project owns the workload.

When to use Shared VPC

Shared VPC is not the right choice for every setup. It fits well in specific organisational contexts:

• Central platform or network team. If your organisation has a dedicated networking or platform team responsible for IP address management, firewall policy, and on-premises connectivity, Shared VPC gives that team authoritative control while letting application teams operate freely within the boundaries set for them.
• Many teams in the same organisation. When ten or twenty application teams need to deploy workloads that all need private connectivity (to each other, to shared services, or to on-premises infrastructure), Shared VPC provides a single flat network with one coherent IP space. There is no peering limit to worry about and no CIDR overlap to resolve later.
• Environment separation with shared network governance. A common pattern is to have separate service projects for production, staging, and development, each with their own subnet in the shared VPC. Teams get environment isolation at the project level (separate IAM, separate billing, separate resource quotas) while the network team controls the overall topology from the host project.
• Regulated industries and security-conscious organisations. When compliance or security policy requires that firewall rules and routing be reviewed and approved centrally before any workload goes live, Shared VPC enforces that requirement architecturally. Application teams cannot modify network policy in the host project — they do not have the permissions.
• Hybrid connectivity that needs to reach many teams. If you have a Cloud Interconnect or Cloud VPN connection to on-premises infrastructure, placing it in the host project means every service project that uses the shared VPC automatically benefits from that connectivity. No separate VPN tunnels or peering connections are needed per team.

When Shared VPC may not be the best fit

Shared VPC adds governance overhead. For simpler setups, that overhead is not worth it:

• Small teams or single projects. If your organisation has two or three projects and everyone trusts each other’s network decisions, the setup complexity of Shared VPC is not justified. A direct VPC peering connection or a single shared project is often simpler.
• Teams that need full network autonomy. Some organisations want each team to control their own firewall rules, routing, and subnet design. Shared VPC deliberately prevents this. If independent network management is more important than consistent central policy, keep each team in their own VPC and use peering for cross-project communication where needed.
• Cross-organisation connectivity. Shared VPC only works within a single GCP organisation. If two separate organisations need private connectivity (a vendor and a customer, for example), VPC peering is the correct model because it works across organisation boundaries.
• Projects outside an organisation node. Shared VPC requires a GCP organisation. If you are working in a standalone project with no Cloud Identity or Google Workspace organisation behind it, Shared VPC is simply not available.

Shared VPC versus VPC peering

Both features allow resources in different GCP projects to communicate over private IPs. They solve different problems and have meaningfully different operational models.

Choose Shared VPC when your teams are in the same organisation, a central team should control the network, and you expect to have many projects that all need consistent private connectivity. The flat IP space and unlimited service project attachment make it the better model for large-scale GCP estates.

Choose VPC peering when networks need to stay independently managed, the projects belong to different organisations, or each team needs their own firewall policy. For more detail on peering mechanics, CIDR requirements, and non-transitive routing, see the VPC peering guide.

Typical Shared VPC architecture pattern

A common production pattern looks like this: one host project that owns the VPC, with separate service projects for each environment or team. The host project’s VPC has distinct subnets for each of these service projects, sized appropriately for the expected workload.

For example, an organisation might have:

• Host project: networking-host owns the VPC, all subnets, firewall rules, Cloud Router, and the Interconnect attachment to on-premises
• Service project: app-prod runs production application VMs and GKE clusters, using prod-subnet (10.10.0.0/20)
• Service project: app-staging runs the staging environment, using staging-subnet (10.10.16.0/20)
• Service project: app-dev runs the development environment, using dev-subnet (10.10.32.0/20)
• Service project: shared-services hosts internal databases, caching, and monitoring tooling that all other projects need to reach

Each service project team has roles/compute.networkUser on their own subnets and only their own subnets. The network team controls the host project, and any changes to firewall rules or routing must go through them.

Because all of these projects share one VPC, on-premises connectivity flows automatically. A VM in app-prod can reach on-premises systems over the Interconnect connection that lives in the host project, without any additional routing configuration in the service project.

For GKE clusters, the same model applies. A cluster in app-prod can be provisioned into a shared subnet, with secondary ranges in that subnet allocated for pod and service IPs. The GKE networking model page explains how node, pod, and service IP allocation works in both standalone and Shared VPC configurations.

Setting up Shared VPC

Setup has three distinct steps: enable a project as a host project, attach service projects to it, then grant the service project’s users and service accounts permission to use specific shared subnets.

# Step 1: Enable a project as a Shared VPC host project
gcloud compute shared-vpc enable HOST_PROJECT_ID

# Step 2: Attach a service project to the host project
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
  --host-project=HOST_PROJECT_ID

# Step 3a: Grant the service project's Compute Engine service account
# the Network User role on a specific shared subnet
# Replace PROJECT_NUMBER with the service project's numeric ID
gcloud compute networks subnets add-iam-policy-binding prod-subnet \
  --region=europe-west1 \
  --project=HOST_PROJECT_ID \
  --member="serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com" \
  --role="roles/compute.networkUser"

# Step 3b: Grant human users in the service project the same subnet access
gcloud compute networks subnets add-iam-policy-binding prod-subnet \
  --region=europe-west1 \
  --project=HOST_PROJECT_ID \
  --member="group:developers@example.com" \
  --role="roles/compute.networkUser"

Steps 3a and 3b are both required. The service account grant (3a) is needed for automated operations like GKE cluster provisioning or Cloud Run deployment. The user group grant (3b) is needed for developers using the Console or gcloud directly to create resources. Skipping either one results in confusing permission errors that look like they should work.

Deploying resources into a shared subnet

Once a service project is attached and IAM bindings are in place, deploying into a shared subnet requires specifying the subnet using its full resource path, which includes the host project ID. This is how GCP distinguishes a shared subnet from any local subnets the service project might have in its own VPC.

# Create a VM in a service project connected to a shared subnet
gcloud compute instances create my-vm \
  --project=SERVICE_PROJECT_ID \
  --zone=europe-west1-b \
  --machine-type=e2-medium \
  --subnet=projects/HOST_PROJECT_ID/regions/europe-west1/subnetworks/prod-subnet \
  --no-address

# Create a GKE cluster in a service project using a shared subnet
gcloud container clusters create my-cluster \
  --project=SERVICE_PROJECT_ID \
  --zone=europe-west1-b \
  --network=projects/HOST_PROJECT_ID/global/networks/shared-vpc \
  --subnetwork=projects/HOST_PROJECT_ID/regions/europe-west1/subnetworks/prod-subnet

The pattern projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME is used whenever a resource in a service project needs to reference the host project’s network. This format appears in Terraform, the Console, and the API; it is the same in all three contexts.

For private GKE clusters in Shared VPC, where node and control plane IPs are fully private, see the private GKE clusters guide. It covers the additional subnet and secondary range configuration required.

Firewall rules in Shared VPC

All firewall rules for the shared VPC are managed in the host project. Service project teams cannot create or modify firewall rules in the host project’s VPC. They simply do not have the IAM permissions, and there is no mechanism to delegate that control at the firewall level.

If a team deploying into a service project needs a port opened (say, port 8080 for a new microservice), they raise a request to the host project team. The host project team adds the rule. This process can create friction in fast-moving teams, so building a clear and fast request process for firewall changes is a necessary part of operating Shared VPC at scale.

One useful layer above the VPC firewall is hierarchical firewall policies, which can be set at the organisation or folder level using organisation policies. These apply to all projects in the hierarchy (host and service alike) and can enforce baseline deny or allow rules that the VPC firewall cannot override. This is useful for organisation-wide security controls like blocking access to sensitive metadata endpoints.

For a deep dive into how firewall rule priority, direction, and targeting work, see Firewall Rules Explained.

Limitations and trade-offs to plan for

Shared VPC is the right model for many organisations, but it comes with operational constraints worth understanding before you commit to it:

• The host project team is the gating dependency for all network changes. Every subnet creation, CIDR change, firewall rule addition, and Cloud Router modification goes through the host project team. In fast-moving organisations, this can slow down teams that need network changes quickly. Strong tooling, clear SLAs for network change requests, and Infrastructure as Code via Terraform help, but the dependency is real.
• Network egress is billed to the host project. Costs for traffic leaving the VPC are associated with the host project, not the service projects that generated the traffic. Per-team cost attribution requires a chargeback process built on top of VPC Flow Logs or billing export data.
• A project cannot be a host project and a service project simultaneously. If the host project team also needs to deploy their own workloads into the shared VPC, those workloads live directly in the host project rather than in an attached service project. This is usually fine but worth noting in your architecture design.
• Service project limits apply. GCP imposes limits on the number of service projects per host project and on Shared VPC-related quotas generally. For most organisations these limits are high enough not to be a practical concern, but check current quota documentation before planning a very large estate.
• Detaching a service project does not delete its resources, but does cut network access. If you detach a service project, any existing resources in the shared subnet continue to run but lose network connectivity because their subnet is no longer accessible. Detaching service projects requires careful planning and migration of workloads beforehand.

For debugging connectivity issues in a Shared VPC setup (such as VMs that cannot reach expected destinations, or GKE pods that cannot communicate), the network troubleshooting guide covers how to use Connectivity Tests and VPC Flow Logs to isolate where traffic is being dropped.