Shared VPC Network

Google Cloud Shared VPC – Multi-Project Networking

~ Last updated on : ~ jayendrapatil ~ 1 Comment

Google Cloud Shared VPC

  • Shared VPC allows an organization to connect resources from multiple projects to a common VPC network to communicate with each other securely and efficiently using internal IPs from that network.
  • requires designating a project as a host project and attach one or more other service projects to it.
  • allows organization administrators to delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources like subnets, routes, and firewalls.
  • Shared VPC is also referred to as “XPN” in the API and command-line interface.
  • allows you to
    • implement a security best practice of least privilege for network administration, auditing, and access control.
    • apply and enforce consistent access control policies at the network level for multiple service projects in the organization while delegating administrative responsibilities
    • use service projects to separate budgeting or internal cost centers.

Shared VPC Concepts

GCP Shared VPC - Multiple host projects

  • Shared VPC connects projects within the same organization. Participating host and service projects cannot belong to different organizations.
  • Linked projects can be in the same or different folders, but if they are in different folders the admin must have Shared VPC Admin rights to both folders.
  • Each project in Shared VPC is either a host project or a service project
    • A host project contains one or more Shared VPC networks. A Shared VPC Admin must first enable a project as a host project. After that, a Shared VPC Admin can attach one or more service projects to it.
    • A service project is any project that has been attached to a host project by a Shared VPC Admin. This attachment allows it to participate in Shared VPC.
  • A project cannot be both a host and a service project simultaneously. Thus, a service project cannot be a host project to further service projects.
  • Multiple host projects can be created; however, each service project can only be attached to a single host project.
  • A project that does not participate in Shared VPC is called a standalone project.
  • VPC networks in the host project are called Shared VPC networks. Service projects resources can use subnets in the Shared VPC network.
  • Shared VPC networks can be either auto or custom mode, but legacy networks are not supported.
  • Shared VPC supports exporting subnets of any stack type (IPv4, IPv6, and dual-stack).
  • Host and service projects are connected by attachments at the project level.
  • Subnets of the Shared VPC networks in the host project are accessible by Service Project Admins.
  • When sharing networks, you can either share all host project subnets (including future ones) or specify individual subnets to share selectively.
  • Organization policies and IAM permissions work together to provide different levels of access control.
  • Organization policies enable setting controls at the organization, folder, or project level.

Organization Policy Constraints

  • Organization Policy constraints provide additional governance over Shared VPC configurations:
    • constraints/compute.restrictSharedVpcHostProjects – Limits the set of host projects to which a non-host project can be attached. Applies when a Shared VPC Admin attaches a service project; doesn’t affect existing attachments.
    • constraints/compute.restrictSharedVpcSubnetworks – Specifies which Shared VPC subnets a service project can access at the project, folder, or organization level. Applies to new VMs and load balancers only; existing resources are unaffected.
  • These constraints help enforce centralized governance while allowing delegated administration.

IAM Roles

Administrator (IAM role) Purpose
Organization Admin
resourcemanager.organizationAdmin		 Organization Admins nominate Shared VPC Admins by granting them appropriate project creation and deletion roles, and the Shared VPC Admin role for the organization. These admins can define organization-level policies, but specific folder and project actions require additional folder and project roles.
Shared VPC Admin
compute.xpnAdmin + resourcemanager.projectIamAdmin		 Shared VPC Admins have the Compute Shared VPC Admin and Project IAM Admin roles for the organization or one or more folders. They perform various tasks necessary to set up Shared VPC, such as enabling host projects, attaching service projects to host projects, and delegating access to some or all of the subnets in Shared VPC networks to Service Project Admins. A Shared VPC Admin for a given host project is typically its project owner as well.
A Shared VPC Admin can link projects in two different folders only if the admin has the role for both folders.
Note: Managing Shared VPC with the Shared VPC Admin role at the folder level is available in General Availability (GA since March 2023).
Service Project Admin
compute.networkUser		 A Shared VPC Admin defines a Service Project Admin by granting an IAM member the Network User role to either the whole host project or select subnets of its Shared VPC networks. Service Project Admins also maintain ownership and control over resources defined in the service projects, so they should have the Instance Admin role in the corresponding service projects. They may have additional IAM roles to the service projects, such as project owner.

  • Project-level permissions: Access to all subnets in the host project (including future subnets).
  • Subnet-level permissions: Access restricted to specific subnets only.
Network Admin
compute.networkAdmin		 Network Admins have full control over all network resources except for firewall rules and SSL certificates.
Security Admin
compute.securityAdmin		 Security Admins manage firewall rules and SSL certificates.

Eligible Resources

  • Most Google Cloud products and features can be used in Shared VPC service projects.
  • Use of a Shared VPC network is not mandatory — service projects can still use their own VPC networks.
  • Existing resources do not automatically use shared network resources when a project is attached as a service project; new resources must be created to use Shared VPC subnets.
  • Key eligible resources include:
    • Compute Engine – VM instances, instance groups, instance templates
    • Google Kubernetes Engine (GKE) – Autopilot and Standard clusters (VPC-native required)
    • Cloud Run – Via Direct VPC egress or Serverless VPC Access connectors
    • Cloud Functions – Via Serverless VPC Access connectors
    • App Engine Flexible – Via Serverless VPC Access connectors
    • Cloud SQL – Via Private Services Access
    • Dataflow – Jobs can specify Shared VPC networks
    • Dataproc – Clusters can use Shared VPC subnets
    • Cloud Composer – Environments can use Shared VPC
    • Internal Load Balancers – All types supported

Serverless Services with Shared VPC

  • Serverless VPC Access – Allows Cloud Run, Cloud Functions, and App Engine to connect to Shared VPC networks via connectors. GA for Shared VPC since March 2021.
  • Direct VPC Egress (Recommended) – Available in GA since April 2024, Cloud Run services and jobs can send traffic directly to a Shared VPC network without needing Serverless VPC Access connectors.
    • Easier to set up, faster, handles more traffic, and has lower costs than connectors.
    • Supports sending traffic from a service project to the host project’s Shared VPC network.
    • Google recommends migrating from Serverless VPC Access connectors to Direct VPC egress for improved performance.

Multiple Network Interfaces with Shared VPC

  • VM instances can connect interfaces other than nic0 to a Shared VPC network (GA since March 2021, including support for instance templates and managed instance groups).
  • Dynamic NICs (GA since October 2025) – Allows adding or removing network interfaces without restarting or recreating VM instances. Supports up to 16 total interfaces.
  • Each network interface must point to a different VPC network.

Shared VPC with Firewall Policies

  • Hierarchical Firewall Policies (GA since February 2021) – Allow creating firewall rules at the organization or folder level that apply across all projects and VPC networks, including Shared VPC networks.
  • Global Network Firewall Policies (GA since August 2022) – Can be applied to Shared VPC networks for centralized firewall rule management.
  • Regional Network Firewall Policies (GA since August 2022) – Provide region-specific firewall rules for Shared VPC networks.
  • These policy types enable centralized security management across all service projects using the Shared VPC network.

Private Service Connect with Shared VPC

  • Private Service Connect (PSC) enables private connectivity to services without exposing traffic to the public internet.
  • PSC endpoints can be created in Shared VPC networks and accessed by service projects.
  • PSC endpoints in a Shared VPC network no longer need to be in the same project as the VMs sending requests (fixed July 2021).
  • Propagated Connections (GA since February 2025) – Services accessible through PSC endpoints in one VPC spoke can be accessed by other VPC spokes connected to the same Network Connectivity Center hub.
  • Service Connectivity Automation (GA since October 2023) – Allows service producers to automate PSC connectivity for managed services on behalf of consumers across different projects.

Cloud Interconnect with Shared VPC

  • Shared VPC can help share the VLAN attachment in a project with other VPC networks.
  • Shared VPC is preferable if you need to create many projects and would like to prevent individual project owners from managing their connectivity back to the on-premises network.
  • Host project contains a common Shared VPC network that VMs in service projects can use. Because VMs in service projects use this network, Service Project Admins don’t need to create other VLAN attachments or Cloud Routers in the service projects.
  • VLAN attachments and Cloud Routers for an Interconnect connection must be created only in the Shared VPC host project.
  • The combination of a VLAN attachment and its associated Cloud Router is unique to a given Shared VPC network.
  • Service Project Admins can create VMs in subnets that exist in a host project’s Shared VPC network based on the permissions that they have to the host project.
  • VMs that use the Shared VPC network can use the custom dynamic routes for VLAN attachments available to that network.
  • VPC Flow Logs can sample traffic sent through VLAN attachments (GA since January 2024).

Hybrid Subnets with Shared VPC

  • Hybrid Subnets (GA since April 2026) allow a VPC network to share a CIDR block with a connected on-premises network.
  • Enables migration of workloads to Google Cloud without changing IP addresses.
  • Workloads that have migrated can communicate with those remaining on-premises using internal IP addresses.
  • Particularly useful in Shared VPC environments where multiple service projects need seamless hybrid connectivity during migrations.
  • After migration is complete, hybrid subnet routing can be disabled to restore normal routing behavior.

Billing

  • Billing for resources in service projects using a Shared VPC network is attributed to the service project where the resource is located.
  • Outbound traffic from an instance is attributed to the project containing the instance.
  • Costs associated with a load balancer are charged to the project containing the load balancer components.
  • Outbound traffic to VPNs is attributed to the project containing the VPN Gateway (typically the host project).
  • Traffic from a Shared VPC service project through a VLAN attachment is attributed to the project owning the VLAN attachment.

Quotas and Limits

  • Shared VPC host projects are subject to standard per-project VPC quotas.
  • Shared VPC networks are subject to per-network and per-instance limits for VPC networks.
  • Relationships between host and service projects are governed by limits specific to Shared VPC (e.g., maximum number of service projects per host project).

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company is building a large-scale web application. Each team is responsible for its own service component of the application
    and wants to manage its own individual projects. You want each service to communicate with the others over the RFC1918 address
    space. What should you do?

    1. Deploy each service into a single project within the same VPC.
    2. Configure Shared VPC, and add each project as a service of the Shared VPC project.
    3. Configure each service to communicate with the others over HTTPS protocol.
    4. Configure a global load balancer for each project, and communicate between each service using the global load balancer IP
      addresses.
  2. Where should you create the Cloud Router instance in a Shared VPC to allow connection from service projects across a new Dedicated Interconnect to your data center?
    1. VPC network in all projects
    2. VPC network in the IT Project
    3. VPC network in the Host Project
    4. VPC network in the Sales, Marketing, and IT Projects
  3. Your organization wants to allow different teams to manage their own GKE clusters while using a centrally managed network. The network team needs to control IP allocation and firewall rules. Which approach should you use?
    1. Create separate VPC networks for each team and use VPC Peering.
    2. Use Shared VPC with a host project managed by the network team and service projects for each team’s GKE clusters.
    3. Deploy all clusters in a single project with separate namespaces.
    4. Use Cloud VPN to connect each team’s project to a central network.
  4. A Shared VPC Admin wants to restrict which subnets a service project can use for deploying VMs. Which organization policy constraint should be applied?
    1. constraints/compute.restrictSharedVpcHostProjects
    2. constraints/compute.restrictSharedVpcSubnetworks
    3. constraints/compute.restrictVpcPeering
    4. constraints/compute.restrictXpnProjectLienRemoval
  5. Your Cloud Run services in a service project need to communicate with resources in a Shared VPC network. What is the recommended approach in 2024+?
    1. Create a VPN tunnel between the projects.
    2. Use Serverless VPC Access connectors in the host project.
    3. Configure Direct VPC egress to the Shared VPC network.
    4. Deploy Cloud Run in the host project directly.
  6. Which of the following statements about Shared VPC are correct? (Choose 2)
    1. A service project can be attached to multiple host projects simultaneously.
    2. A project cannot be both a host project and a service project at the same time.
    3. Shared VPC can connect projects across different organizations.
    4. Shared VPC supports exporting subnets of any stack type including IPv6 and dual-stack.

Reference