Shared VPC in Google Cloud Platform allows you to centralize your network infrastructure in a "host project" and share it with multiple "service projects." This means resources in different projects can communicate over the same private IP addresses, simplifying network management and improving security.
Let’s see it in action. Imagine you have a web application deployed in service-project-A that needs to connect to a database in service-project-B. Without Shared VPC, you’d typically set up complex VPC peering or external IP communication. With Shared VPC, they can simply use internal IPs as if they were in the same project.
Here’s a simplified setup:
Host Project: shared-vpc-host-project
Service Project: service-project-a
-
Enable Shared VPC on the Host Project: Navigate to the VPC network page in the Google Cloud Console, select "Shared VPC," and click "Enable Shared VPC." Choose
shared-vpc-host-projectas the host project. -
Attach Service Projects to the Host Project: In the same Shared VPC section, go to "Service projects" and click "Add Project." Select
service-project-aand click "Add." -
Share a Subnet from the Host Project: Go to "VPC networks" in
shared-vpc-host-project. Select your VPC network (e.g.,defaultor a custom one). Click the "Share subnet" button for the subnet you want to share (e.g.,us-central1-subnet-a). Chooseservice-project-aas the service project that can use this subnet. -
Create a VM in the Service Project using the Shared Subnet: When creating a VM in
service-project-a, under "Networking," select "Use network from another project." Chooseshared-vpc-host-projectfor the host project and then select the shared subnet (e.g.,us-central1-subnet-a). The VM will get an IP address from that subnet.
Now, a VM in service-project-a using us-central1-subnet-a can directly communicate with another VM in service-project-b (also configured to use us-central1-subnet-a) using its internal IP address.
The core problem Shared VPC solves is network sprawl and management overhead. In large organizations, each team or application might spin up its own VPCs, leading to inconsistent IP addressing, complex firewall rules across many networks, and difficulty in auditing. Shared VPC centralizes this control. The host project owner defines the network topology, subnets, and routes. Service projects then consume these shared resources, inheriting the network policies and connectivity.
Internally, it works by making subnets defined in the host project available for resource creation in attached service projects. When a resource is created in a service project and assigned to a shared subnet, it’s effectively connected to the host project’s VPC network. This allows for seamless private IP communication between resources residing in different projects but utilizing the same shared network infrastructure.
The exact levers you control are the subnets you choose to share and the IAM permissions you grant. You can share specific subnets, not the entire VPC. This granular control allows you to segment networks effectively. For example, you might share a subnet for front-end applications from one host project and a different subnet for backend databases from another host project, all managed centrally.
The most surprising thing is that when a VM is created in a service project using a shared subnet, its network interfaces and associated routing are still managed by the host project’s VPC. This means any network policies, firewall rules, or route changes applied at the host project level automatically propagate to resources in all attached service projects that utilize those shared networks. It’s not just about IP address allocation; it’s about inheriting the entire network fabric.
The next concept to explore is how to manage firewall rules effectively across multiple service projects using Shared VPC.