A Shared Virtual Private Cloud (Shared VPC) centralizes network management by allowing a designated host project to share its network with attached service projects. Setting up this architecture requires enabling the host project, associating service projects, and delegating specific administrative permissions across the organization.
A host project is a Google Cloud project that owns and shares one or more Virtual Private Cloud (VPC) networks across multiple projects. A Shared VPC Admin activates this functionality by running the gcloud compute shared-vpc enable command against the target host project. Once enabled, the host project serves as the central control plane for all subnets, routes, Cloud VPN gateways, and firewall rules. Network security teams maintain exclusive ownership of these infrastructure components within the host project boundary.
A service project is a standard Google Cloud project attached to a host project to consume its shared network infrastructure. A Shared VPC Admin attaches a service project using the gcloud compute shared-vpc associated-projects add command. After this attachment is established, workloads in the service project can connect to host project subnets without creating their own independent networks. The service project maintains administrative isolation for applications while relying on the host project for network connectivity.
Identity and Access Management (IAM) separates host network administration from application management inside service projects. The Shared VPC Admin manages host enablement, project attachments, and network configurations across the environment. In contrast, Service Project Admins manage local compute resources such as virtual machines and internal load balancers. Administrators can grant the Compute Network User role at the project level to share all subnets or assign it at the individual subnet level to enforce least-privilege access.
Workloads deployed inside service projects allocate their primary internal IP addresses directly from the shared host subnets. A virtual machine (VM) instance in a service project must be provisioned in a zone that resides within the exact region of its assigned host subnet. For example, a VM utilizing a subnet located in us-west1 must be placed in a zone such as us-west1-a. Existing standalone VM instances cannot be retroactively moved into a Shared VPC; they must be deleted and recreated to bind to the shared subnets.
Granular subnet sharing allows organizations to restrict service projects to specific host subnets rather than exposing an entire VPC network. This access model enforces least-privilege security boundaries between different application teams using the same underlying network.
The relationship between host and service projects creates a strict boundary between network infrastructure ownership and workload execution. The host project administrator determines which subnets are accessible to specific service projects. Service Project Admins consume those authorized IP spaces to launch resources without gaining permissions to alter the host network topology. This structural separation protects core routing and firewall policies from accidental modifications by application teams.
Subnet-level permission delegation grants a service project access to explicit subnets while blocking visibility into the rest of the host network. This model uses the compute.networks.use and compute.subnetworks.use permissions, which are packaged inside the Compute Network User (roles/compute.networkUser) role. Administrators assign this role to specific user accounts, groups, or service accounts on targeted subnets in the host project. By avoiding broad project-wide network role assignments, security teams isolate different environments like production and staging.
Cross-project access requires the Compute Network User role to be assigned on the host project or its subnets, not on the service project. Because the underlying network resources exist inside the host project, permissions must be verified against the host project's resource hierarchy. When a principal in a service project launches a compute instance, the system checks the host project's IAM policy to validate subnet access. Granting permissions on the service project alone will fail to authorize network attachment.
Private Service Connect endpoints provisioned in service projects require coordinated permissions across project boundaries. The Service Project Admin must reserve an internal IP address inside the service project that references a subnet located in the host project. This internal IP address must match the region of the target service producer's service attachment. The principal performing the deployment must hold the Compute Network User role on the host subnet and compute provisioning permissions on the service project.
Cross-project resource provisioning allows complex workloads like container clusters and load balancers to run in service projects while consuming host network IP ranges and security rules. This setup requires specialized service accounts, secondary IP configurations, and host firewall rules.
Google Kubernetes Engine (GKE) clusters running in service projects consume primary subnet ranges for nodes and secondary IP ranges for Pods and Services from the host project. Clusters in a Shared VPC require VPC-native traffic routing, which is enabled by default in Autopilot clusters and must be specified during creation for Standard clusters. The host subnet must provide two dedicated secondary IPv4 ranges that do not overlap with each other, existing subnets, or the reserved 172.17.0.0/16 range. Private GKE clusters additionally require a non-overlapping /28 IPv4 prefix dedicated to the control plane, and existing clusters cannot be migrated into a Shared VPC after creation.
Cross-project GKE provisioning depends on granting specific IAM roles to service project service accounts at the host project level. A Shared VPC Admin must grant the Compute Network User role to both the service project's Google APIs service account and the service project's GKE service account. Additionally, the service project's GKE service account must receive the Kubernetes Engine Host Service Agent User (roles/container.hostServiceAgentUser) role at the host project level. If these roles are missing or the host project's GKE API is disabled, cluster creation fails during network metadata validation.
Static IP address objects allow service project workloads to maintain consistent internal or external entry points across reboots. When creating an internal static IP address in a service project, the address object resides in the service project, but its value is allocated from the host project's subnet. Using the Google Cloud CLI (gcloud CLI), administrators specify the host subnet by passing its full resource uniform resource locator (URL). The principal creating the reservation must hold the compute.subnetworks.use permission on the host subnet.
Centralized firewall rules created in the host project control all ingress and egress traffic for cross-project workloads. For Cloud Load Balancing, host firewall rules must allow ingress traffic from the health check IP ranges 35.191.0.0/16 and 130.211.0.0/22 on destination ports 80 and 443. Legacy Network Load Balancing environments require additional allowances for 209.85.152.0/22 and 209.85.204.0/22. To permit administrative access without public IP addresses, host firewalls must allow ingress from 35.235.240.0/20 on TCP ports 22 and 3389 for Identity-Aware Proxy (IAP) TCP forwarding, and subnets should enable Private Google Access to reach Google APIs privately.
StudyCerts
StudyCertsroles/compute.networkUser) role must be granted on the host project or specific host subnets to authorize service project principals and service accounts to use the network.roles/container.hostServiceAgentUser) role at the host project level.35.191.0.0/16 and 130.211.0.0/22 for Google Cloud load balancer health checks, and from 35.235.240.0/20 for Identity-Aware Proxy (IAP) TCP forwarding.The Compute Network User role must be granted on the host project or on individual subnets within the host project. Because network resources belong to the host project, assigning permissions within the service project does not authorize a user to consume host subnets.
A private GKE cluster requires VPC-native traffic routing, a host subnet with primary and secondary IP ranges for nodes, Pods, and Services, and an unallocated /28 IPv4 range for the master control plane. The secondary ranges cannot overlap with existing subnets or the reserved 172.17.0.0/16 range.
No, existing compute instances and GKE clusters cannot be attached to a Shared VPC network after creation. Workloads must be configured to use the Shared VPC network at creation time, requiring existing resources to be recreated.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills