This chapter covers Shared VPC, a core networking feature that enables organizations to centrally manage a Virtual Private Cloud (VPC) network across multiple Google Cloud projects. For the ACE exam, Shared VPC appears in approximately 5-10% of questions, often in scenarios involving multi-project architectures, security, and cost management. You will learn the precise mechanism, configuration steps, IAM roles, and common pitfalls to ensure you can design and troubleshoot Shared VPC deployments confidently.
Jump to a section
Imagine a large corporate office building (the host project) that owns the main entrance, lobby, elevators, and all internal hallways (the VPC network, subnets, and firewall rules). Each department (service project) gets its own office suite (GCE instance, GKE cluster, etc.) but must use the building's common infrastructure to access the outside world, receive visitors, and communicate with other departments. The building manager (Shared VPC Admin) decides which departments can use which hallways (subnets) and which keys they get (IAM roles). Departments cannot install their own doors to the outside (external IPs) unless the building manager allows it. If a department wants to add a new office (resource), they just request space in an existing hallway; they don't need to build a new hallway themselves. This model centralizes security (one set of fire doors and cameras) while allowing each department to operate independently within their assigned space. Misconfiguration occurs when a department is given access to a hallway that leads to another department's sensitive area (overly permissive subnet sharing) or when the building manager forgets to grant hallway access (missing IAM roles).
What is Shared VPC and Why Does It Exist?
Shared VPC allows an organization to create a single VPC network in a host project and share its subnets with service projects that belong to the same organization or folder. This eliminates the need to create separate VPC networks per project, which would require complex peering and firewall rules. The primary drivers for Shared VPC are: - Centralized network administration: A single network team manages IP addressing, firewall rules, and routing. - Resource isolation with connectivity: Service projects retain their own IAM boundaries but use a common network. - Cost efficiency: Shared resources like Cloud NAT, VPNs, and interconnect attachments reduce duplication. - Compliance: Consistent security policies across projects.
How Shared VPC Works Internally
Shared VPC relies on two key concepts: the host project and service projects. The host project contains the VPC network (including subnets, routes, firewall rules, and Cloud Router). Service projects are projects that are attached to the host project and can use its subnets. However, service projects do not own the network; they only have permissions to create resources (e.g., Compute Engine instances, GKE clusters) that use the shared subnets.
At the IAM level, Shared VPC uses two primary roles:
- Shared VPC Admin (roles/compute.xpnAdmin): Grants the ability to enable Shared VPC on a host project, attach service projects, and manage subnet sharing.
- Service Project Admin (roles/compute.networkUser): Grants the ability to use shared subnets (but not modify them). This role is assigned at the project, folder, or organization level.
When a user in a service project creates a Compute Engine instance, they must specify a subnet from the host project. The instance's network interface is placed directly into that subnet. From a networking perspective, the instance behaves exactly as if it were in the host project: it gets an internal IP from the shared subnet, uses the host project's routes and firewall rules, and can communicate with any other resource in the shared VPC (including instances in other service projects) using internal IPs.
Key Components, Values, and Defaults
- Host project: Must be in the same organization as the service projects. A project can be a host project only if it is not already a service project. A host project can have multiple service projects attached.
- Service project: Can be attached to exactly one host project. Once attached, it cannot be detached if it contains resources using shared subnets (unless those resources are deleted first).
- Subnet sharing: By default, when a service project is attached, it gains access to all subnets in the host project. However, you can restrict access by using subnet-level IAM bindings. For example, you can grant compute.networkUser on a specific subnet to a service project's service account or users.
- Permissions: To create a resource in a shared subnet, the user must have:
- compute.networkUser on the host project (or on the specific subnet)
- compute.instanceAdmin or equivalent on the service project
- GKE clusters: Can be created in a service project using shared subnets. The cluster's nodes and pods use the shared VPC's IP range. However, the GKE master is still managed by Google and may require additional firewall rules.
- Cloud Run, Cloud Functions: These serverless services can also use a shared VPC via Serverless VPC Access connectors, which are deployed in the host project and attached to the service project.
Configuration and Verification Commands
Enabling Shared VPC on a host project:
gcloud compute shared-vpc enable HOST_PROJECT_IDAttaching a service project:
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
--host-project HOST_PROJECT_IDGranting networkUser role on the entire host project (to a user or service account):
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member='user:email@example.com' \
--role='roles/compute.networkUser'Granting networkUser on a specific subnet:
gcloud compute networks subnets update SUBNET_NAME \
--region=REGION \
--add-iam-member='user:email@example.com' \
--role='roles/compute.networkUser'Verifying the host project:
gcloud compute shared-vpc list-host-projectsListing attached service projects:
gcloud compute shared-vpc get-host-project HOST_PROJECT_IDChecking subnet IAM bindings:
gcloud compute networks subnets get-iam-policy SUBNET_NAME --region=REGIONInteraction with Related Technologies
VPC Network Peering: Shared VPC is often compared to VPC peering. Peering connects two separate VPCs, whereas Shared VPC creates a single VPC across projects. Shared VPC is simpler for many-to-many communication because all resources are in one network. Peering is used when the networks are in different organizations or when you need to avoid the single host project limit.
Cloud NAT: Can be configured in the host project to provide outbound internet access to instances in service projects. This is more efficient than each service project having its own NAT.
Cloud VPN / Interconnect: The host project typically owns the VPN gateway or interconnect attachment. Service projects use the routes propagated from the host project.
Firewall Rules: Defined in the host project and apply to all instances in the shared VPC, regardless of which project they belong to. This centralizes security.
Organization Policies: Can be applied to restrict Shared VPC usage. For example, you can enforce that only certain projects can be host projects.
Common Pitfalls
Detaching a service project: If the service project contains resources using shared subnets, detachment will fail. You must delete those resources first.
Overlapping subnets: Service projects cannot have their own VPC with overlapping IP ranges with the shared VPC if they are attached. However, they can have their own VPCs with non-overlapping ranges.
GKE in Shared VPC: The GKE cluster's nodes use the shared subnet, but the master is managed by Google. You must create firewall rules in the host project to allow the master to communicate with nodes (ports 443 and 10250).
IAM inheritance: compute.networkUser granted at the organization or folder level applies to all current and future host projects. This can lead to unintended access if not carefully scoped.
Enable Shared VPC on host project
Run `gcloud compute shared-vpc enable HOST_PROJECT_ID` to designate a project as a host project. This command grants the Shared VPC Admin role to the user and configures the project to accept service projects. The host project must be in the same organization as the service projects. After enabling, the project cannot be deleted until all service projects are detached and resources are removed.
Attach service project to host project
Use `gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID --host-project HOST_PROJECT_ID` to attach a service project. The service project now inherits access to all subnets in the host project by default. The attachment is recorded in the host project's metadata. The service project remains a separate project with its own IAM, but its network resources can now use the shared VPC.
Grant networkUser role on host project or subnets
To allow users in the service project to create resources using shared subnets, grant them the `compute.networkUser` role. This can be done at the project level (all subnets) or subnet level. For example: `gcloud projects add-iam-policy-binding HOST_PROJECT_ID --member='user:user@example.com' --role='roles/compute.networkUser'`. Without this role, the user will see the shared subnets but cannot use them.
Create resource in service project using shared subnet
A user with the appropriate IAM roles creates a Compute Engine instance in the service project, specifying a subnet from the host project. The instance's network interface is placed in the shared subnet. The instance gets an internal IP from that subnet and uses the host project's routes and firewall rules. The instance can communicate with any other resource in the shared VPC using internal IPs.
Verify connectivity and monitoring
After creation, verify that the instance can reach other resources (e.g., ping another instance in a different service project's shared subnet). Check firewall rules in the host project to ensure necessary traffic is allowed. Use `gcloud compute instances list` to confirm the subnet is from the host project. Monitor using VPC Flow Logs enabled on the host project's subnets.
Scenario 1: Large Enterprise with Multiple Business Units
A multinational company has separate projects for each business unit (e.g., Finance, HR, Engineering). The central network team manages a single Shared VPC in a host project called net-host-prod. Each business unit's project is attached as a service project. The network team defines all firewall rules, Cloud NAT, and VPN connections. Business unit teams have compute.networkUser on specific subnets allocated to them (e.g., finance-subnet, hr-subnet). This setup allows the Finance team to deploy sensitive databases in their own project while using the central network. A common problem is when a business unit accidentally gets compute.networkUser on the wrong subnet, allowing them to launch instances in another unit's subnet. To prevent this, subnet-level IAM is enforced, and audits are run monthly using gcloud compute networks subnets get-iam-policy. Performance is excellent because all traffic stays within the same VPC, avoiding peering overhead. The main scale consideration is the number of service projects: Google Cloud supports up to 1,000 service projects per host project.
Scenario 2: Shared VPC for GKE Multi-Tenancy
A SaaS company uses GKE in a service project with a shared VPC. The host project contains the VPC and a Cloud NAT for outbound internet. The GKE cluster's nodes are in a shared subnet, and the cluster's service IP range is also from the host project. This allows the SaaS company to isolate each customer's workloads in separate namespaces while using a single network. A common misconfiguration is forgetting to create firewall rules in the host project to allow the GKE master (which is external to the VPC) to communicate with nodes. The required rules are: allow TCP 443 and 10250 from the master's IP range (which can be obtained via gcloud container clusters describe). Without these rules, the cluster will report unhealthy nodes. Another issue is IP exhaustion: if the shared subnet is too small, scaling the GKE cluster will fail. The subnet must have enough IPs for nodes, pods (if using VPC-native), and services.
Scenario 3: Mergers and Acquisitions
When a company acquires another, the acquired company's projects can be attached to the parent company's Shared VPC. This allows gradual migration of workloads without changing IP addresses. The acquired company's existing VPC can be kept until migration is complete. A challenge is overlapping IP ranges. If the acquired company's VPC overlaps with the shared VPC, you cannot simply attach the project; you must either re-IP the acquired company's resources or use VPC peering with NAT. A common mistake is attempting to attach a project that has its own VPC with overlapping subnets; Google Cloud will reject the attachment. The solution is to delete the overlapping VPC or use a non-overlapping range before attachment.
What the ACE Exam Tests on Shared VPC (Objective 2.1)
The ACE exam expects you to:
Identify when to use Shared VPC vs. VPC Peering vs. separate VPCs.
Understand the roles: compute.xpnAdmin (Shared VPC Admin) and compute.networkUser (Service Project Admin).
Know the command syntax for enabling Shared VPC, attaching service projects, and granting subnet-level IAM.
Recognize that a service project can only have one host project, and a host project can have up to 1,000 service projects.
Understand that deleting a host project requires detaching all service projects and removing all resources.
Know that GKE clusters in a service project require firewall rules in the host project for master-node communication.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong answer: "Shared VPC allows communication between projects without any IAM."
- Why chosen: Candidates confuse the network connectivity with IAM. While the network is shared, IAM still controls who can create resources.
- Correct: Even with Shared VPC, users must have compute.networkUser on the host project or subnet to use it.
2. Wrong answer: "A service project can be attached to multiple host projects." - Why chosen: Candidates think of VPC peering where a VPC can peer with many others. But Shared VPC is a one-to-one attachment. - Correct: A service project can only be attached to one host project.
3. Wrong answer: "Shared VPC requires VPC peering between host and service projects." - Why chosen: Candidates assume that separate projects always require peering. But Shared VPC is a different mechanism that does not use peering. - Correct: Shared VPC creates a single VPC across projects; no peering is involved.
4. Wrong answer: "The compute.networkUser role allows a user to modify subnets in the host project."
- Why chosen: Candidates think 'User' implies more permissions. But this role is read-only for the network itself.
- Correct: compute.networkUser only allows using subnets (creating resources), not modifying them. To modify, you need compute.networkAdmin or higher.
Numbers and Terms to Memorize
1,000: Maximum service projects per host project.
`roles/compute.xpnAdmin`: Shared VPC Admin role.
`roles/compute.networkUser`: Service Project Admin role (subnet user).
Commands: gcloud compute shared-vpc enable, gcloud compute shared-vpc associated-projects add, gcloud compute networks subnets update --add-iam-member.
Ports for GKE: 443 (HTTPS) and 10250 (kubelet) from master to nodes.
Edge Cases and Exceptions
Organization policy: If an organization policy restricts Shared VPC, you cannot enable it even with the right roles.
Service project with existing VPC: A service project can have its own VPC as long as it does not overlap with the shared VPC. But the service project's resources can only use one VPC at a time for a given network interface.
Detaching a service project: Fails if resources are using shared subnets. Must delete those resources first.
Shared VPC with Cloud Run: Requires a Serverless VPC Access connector in the host project, which itself needs a subnet. The connector's subnet must be in the same region as the Cloud Run service.
Shared VPC allows a single VPC network to be used across multiple projects within the same organization.
The host project contains the VPC; service projects are attached and can use its subnets.
A service project can only be attached to one host project; a host project can have up to 1,000 service projects.
Users must have `compute.networkUser` role on the host project or subnet to create resources using shared subnets.
`roles/compute.xpnAdmin` is required to enable Shared VPC and manage attachments.
GKE clusters in a service project require firewall rules in the host project for master-node communication (TCP 443 and 10250).
Shared VPC does not use VPC peering; it is a single network across projects.
Detaching a service project requires deleting all resources using shared subnets first.
Subnet-level IAM can restrict which subnets a service project can use.
Shared VPC cannot be used across different organizations.
These come up on the exam all the time. Here's how to tell them apart.
Shared VPC
Single VPC network across multiple projects within same organization.
Centralized network administration: one set of firewall rules, routes, and NAT.
Service projects do not own the network; they only use subnets from host project.
No limit on number of service projects (up to 1,000 per host project).
Simpler for many-to-many communication within the organization.
VPC Network Peering
Connects two separate VPC networks (can be in different organizations).
Each VPC retains its own administration; firewall rules and routes are independent.
Each VPC owns its network; peering does not grant subnet usage to other projects.
Limited to 25 peerings per VPC (soft limit, can be increased).
Best for connecting different organizations or when you need full administrative isolation.
Mistake
Shared VPC allows any user in a service project to automatically use all subnets in the host project.
Correct
Users must be explicitly granted the `compute.networkUser` role on the host project or specific subnets. Without this role, they cannot create resources using shared subnets.
Mistake
A service project can be attached to multiple host projects simultaneously.
Correct
A service project can be attached to exactly one host project. To change host projects, you must first detach from the current host project (which requires deleting all resources using shared subnets).
Mistake
Shared VPC requires VPC Network Peering between the host and service projects.
Correct
Shared VPC does not use peering. It creates a single VPC network that spans multiple projects. All resources in the shared VPC can communicate directly without peering.
Mistake
The `compute.networkUser` role allows users to modify subnets (e.g., change IP ranges) in the host project.
Correct
`compute.networkUser` only permits using subnets for resource creation. To modify subnets, you need `compute.networkAdmin` or `roles/compute.securityAdmin` on the host project.
Mistake
Shared VPC can be used across different Google Cloud organizations.
Correct
Shared VPC only works within a single organization. All host and service projects must belong to the same organization. For cross-organization connectivity, use VPC Network Peering or Cloud VPN.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, a service project can have its own VPC (non-overlapping with the shared VPC) and still be attached. However, resources in the service project can only use one VPC per network interface. You can create instances in the service project that use either the shared VPC or the project's own VPC, but not both simultaneously on the same network interface.
Use subnet-level IAM bindings. Instead of granting `compute.networkUser` on the entire host project, grant it on specific subnets using the command: `gcloud compute networks subnets update SUBNET_NAME --region=REGION --add-iam-member='user:user@example.com' --role='roles/compute.networkUser'`. This limits the user to only that subnet.
You cannot delete a host project if it has attached service projects or resources using shared subnets. You must first detach all service projects (which requires deleting their resources in shared subnets) and then delete all resources in the host project. After that, you can disable Shared VPC and delete the project.
Yes, but you need a Serverless VPC Access connector. The connector is deployed in the host project (or service project, but typically host project) and attached to a shared subnet. Then, Cloud Run services in the service project can use the connector to access resources in the shared VPC.
First, verify that the service project is attached: `gcloud compute shared-vpc get-host-project SERVICE_PROJECT_ID`. Then, check that the user has `compute.networkUser` on the host project or subnet: `gcloud projects get-iam-policy HOST_PROJECT_ID` or `gcloud compute networks subnets get-iam-policy SUBNET_NAME --region=REGION`. Also, ensure the user has `compute.instanceAdmin` on the service project.
Shared VPC creates a single VPC across multiple projects within the same organization. VPC Peering connects two separate VPCs, possibly across organizations. Shared VPC centralizes administration (firewall rules, routes, NAT) while peering keeps each VPC independent. Shared VPC is simpler for many-to-many communication, but peering is required for cross-organization connectivity.
Yes, but you must first detach the service project from the current host project. Detachment requires deleting all resources in the service project that use shared subnets. Then you can attach to a new host project. There is no direct migration path.
You've just covered Shared VPC for Multi-Project Networking — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?