Managing networking can be challenging when an organization owns multiple projects with multiple VPCs and subnets. For example, someone will have to track if users that create subnets don’t use IP ranges that overlap (if some VPCs need to be connected in the future). In addition, someone will have to ensure that all projects have unified security settings and firewall rules. Also, if projects need access to an on-premises environment, each one will come with an additional dedicated VPN gateway or Interconnect and Cloud Router to manage.
To simplify network architectures, you can leverage a Shared VPC, where a host project shares a VPC with multiple service projects within the same organization. It is a centralized approach to multi-project networking. As a result, you get fewer networking components to manage, but you can still keep separate budgets for different projects. Service projects can continue to use their standalone VPC subnets. Still, the idea is only to use networking services such as subnets, routers, VPN gateways, and Interconnect links defined centrally in a host project. A single service project can only be attached to one host project. Usually, host projects are managed by networking and security admins, who prepare all network configurations and enforce firewall and security policies. Owners of service projects can then focus on their workloads.
The following diagram shows a host project that has a VPC and Interconnect to on-premises and regional subnets set up by a networking team with firewall rules created by a security team.
There are three service projects – production, test, and analytics – that have Compute Engine VMs with assigned subnets from the host project. With Shared VPC, users in these service projects don’t have to worry about setting up or managing the network themselves; they can simply use it:
Figure 9.10 – Shared VPC concept where VPC subnets deployed in a host project are used by Compute Engine VMs in a service project
To get a better understanding of how to set up a Shared VPC, let’s take a closer look at the necessary configuration steps:
- To provision a Shared VPC, you need to go to the Shared VPC page in the VPC network section. In addition to selecting a host project, you can choose to share all subnets in a VPC or select individual ones. Note that you need a Shared VPC Admin role (at the organizational level) to set up a host project:
Figure 9.11 – Setting up a Shared VPC where three individual subnets will be shared with service projects
- In the next step, in the same Shared VPC view, with a Shared VPC Admin role, you can add projects from your organization that will be allowed to use subnets from a Shared VPC. Next, you must delegate access to selected or all subnets of the Shared VPC to Service Project Admins by assigning them a Network User role on selected subnets. Service Project Admins are usually owners of their projects, which allows them to create resources in service projects such as Compute Engine VMs.
- Once the project becomes a service project, its VM instances, instance templates, or load balancers can have networks from a host project assigned to them. For example, the following screenshot demonstrates a VM instance creation view with the option to select a shared subnet:
Figure 9.12 – Creating a Compute Engine VM with an interface in a shared subnet
In the next section, we will investigate another approach to multi-project networking: VPC network peering.