Shared VPC

Shared VPC is a Google Cloud arrangement in which one network is owned centrally and used by resources belonging to other projects. The documentation states it plainly: “an organization can use Shared VPC to keep a VPC network in a common host project,” and “authorized IAM principals from other projects in the same organization can create resources that use subnets of the Shared VPC network.” Descriptions here follow that documentation, checked in September 2026.

The product name is specific to one provider. The problem it solves is not: every organization running more than a handful of teams has to decide whether network ownership sits with the teams or with a platform group, and this is one structural answer to it.

Not the same thing as peering

Both let workloads in different places talk, so they get compared. The difference is how many networks exist afterwards.

	Peering two networks	Shared VPC
How many networks	Two, connected	One, used by several projects
Address space	Must not overlap, and each side plans its own	One plan, allocated centrally as subnets
Who changes routing and firewall rules	Each owner, for their own side	The host project’s owner, for everyone
Routing reach	Only between the two peers — a peer of a peer is not reachable by default	Every subnet of the network, since those routes exist automatically. Whether traffic is allowed is a separate question — firewall rules still decide, and incoming traffic is denied unless a rule permits it
What a team asks for	A peering connection and agreed routes	Permission to use a subnet

The last row is the operational heart of it. In a peered estate a team owns a network and negotiates connections; in a shared one a team owns workloads and is granted a place to put them. That is a governance decision expressed as a network topology, which is why it is worth making deliberately rather than inheriting from whoever built the first environment.

The host project and the service projects

The arrangement splits responsibilities along a line that maps unusually well onto how platform and product teams actually divide work.

• The host project owns the network: address allocation, subnets, routes, firewall rules, and the connections to on-premises or other networks. A platform team holds it, and its changes affect every workload using it.
• Service projects own workloads. Their resources attach to subnets of the shared network, while the project itself remains the boundary for identity, quota, and billing — since “you need a project resource to use Google Cloud” and requests are made against a project.

Its consequences surprise people in opposite directions. A team can be given a subnet without being given the ability to change the network — which is usually the point. And attribution splits along the same line as ownership: a workload’s own resources are billed to and counted against its service project, so who owns this network and whose budget is this workload have different answers by design.

The half that gets forgotten is the host side. Network-level quotas apply to the host project, so it needs its own capacity management — and the shared connectivity resources living there are billed there. The documentation is specific: “outbound traffic to VPNs is attributed to the project containing the VPN Gateway resource,” and outbound traffic through that gateway is attributed to the host project “regardless of which service project initiates the outbound data transfer,” while traffic out through a VLAN attachment goes to “the project that owns the VLAN attachment.” A platform team running the host project therefore holds a real budget line, and a chargeback model that only totals service projects understates the cost of the network everyone is using.

Access to a subnet is granted through the same permission system as everything else, so the grant is subject to the surrounding resource hierarchy — a role given at a folder reaches the projects beneath it. That is convenient and worth being careful about: subnet-level permissions granted high in the tree are broader than they look.

Why it combines with a global network

This arrangement does more work in Google Cloud than the equivalent would elsewhere, because of what a virtual network is there. “VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone,” while “subnets are regional resources.”

So one shared network can span regions, with a regional subnet in each. Connecting regions is not a peering exercise, because they were never separate networks. Where providers scope a network to a region, the same centralization needs a network per region plus something to join them, and the joining is its own design with its own failure modes.

The practical import is for anyone reading a design from one cloud while working in another. A Google Cloud diagram showing one network behind many projects is not hiding the inter-region connectivity; there is none to show. Copying that diagram into a regional model produces a design with a missing piece.

What centralizing costs

Shared infrastructure concentrates both the benefit and the risk, and the costs are worth naming before adopting it rather than discovering them afterwards.

• Change becomes coordination. A firewall or route change is made by one team on behalf of many, so a request queue forms unless the common cases are self-service. The queue, not the technology, is what teams will complain about.
• The failure domain is wider. A mistake in the shared network can affect every workload in it. That argues for the change process you would apply to any shared state — review, staged rollout, and a way back — rather than for avoiding the model.
• Address planning becomes a real function. One plan for the whole estate means someone allocates ranges, keeps them from overlapping with on-premises and future acquisitions, and says no. Doing this badly is expensive to undo, because renumbering a running workload is not a configuration change.

Against that, a separate network per project keeps teams independent and pushes the cost elsewhere: duplicated connectivity to shared services and on-premises, more places for a rule to be wrong, and a peering mesh that grows faster than the team count. Neither is free; the honest framing is which cost you would rather operate.

A reasonable default for most organizations is one shared network per environment, owned by a platform team, with self-service for the routine requests — the same make the compliant path the easy path logic as a golden path. Isolated networks then become a deliberate exception for workloads that genuinely need them: a regulated environment, a third-party-managed system, an acquisition not yet integrated.

Specific limits — how many service projects may attach, how many host projects an organization may have — change, so check the current documentation rather than planning against a number quoted in an article. How network ownership fits with hierarchy, identity, and the differences between providers is worked through in The Diagram Ports and the Design Does Not.

References: Google Cloud, VPC networks; Google Cloud, Resource hierarchy; Google Cloud, Shared VPC; Google Cloud, VPC quotas and limits.