Shared VPC

Shared VPC lets eligible Google Cloud resources in service projects use subnets from VPC networks owned by a host project in the same organization. A host project can contain one or more shared networks. This separates network administration from workload administration without requiring a single VPC for the entire estate.

The product name is specific to Google Cloud. When teams need independent workload administration within centrally managed networks, Shared VPC provides one way to separate those responsibilities.

Not the same thing as peering

The table compares peering two VPCs with sharing one VPC across projects. A full Shared VPC deployment can contain multiple networks; the host/service project relationship does not merge them.

	Peering two networks	Shared VPC
How many networks in this example	Two, connected by peering	One shared VPC used by several projects; the host may contain other VPCs
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 host and service projects define distinct responsibilities that can be assigned to network and workload owners.

• 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 a change can affect the workloads that use the subnets, routes, or rules involved, depending on which communication paths rely on them.
• Service projects contain workloads whose eligible resources use authorized shared subnets. IAM grants can be inherited, network resources belong to the host, and quota scope depends on the service and resource. The service project is therefore one administrative and billing scope, not a complete isolation boundary.

A team can be allowed to use a subnet without receiving permission to change the network. Billing for workload resources is attributed to the project containing them, while quota consumption must be checked against the relevant limit. Separate network ownership and workload ownership do not imply every cost or quota follows the same split.

Host projects have per-project VPC quotas; shared networks also have per-network and per-instance limits, plus limits on Shared VPC relationships. Adding service projects does not enlarge a shared network’s limit. Costs likewise need a resource-level mapping: instance outbound traffic belongs to the instance’s project, VPN outbound traffic to the gateway’s project, and traffic through a VLAN attachment to that attachment’s project. Shared connectivity in the host therefore creates costs that a service-project-only report can miss.

Subnet access is subject to the surrounding resource hierarchy. A role assigned on a host project or its parent can cover more subnets than a grant on an individual subnet. Inspect the actual assignment scope and inherited permissions rather than describing a high-level grant as subnet-limited.

Why it combines with a global network

Google Cloud’s virtual network is global, while each subnet is regional. Shared VPC adds the cross-project ownership arrangement; it does not change those geographic scopes.

Regional subnets within the same VPC do not need VPC peering to communicate. If the design keeps separate VPCs for isolation, ownership, or organizational requirements, their connectivity remains a separate decision. Providers with regional networks also need an inter-network connection when workloads across those regions must communicate.

A single global VPC diagram omits a customer-configured peering between its regional subnets, not the inter-region communication itself. Routing, firewall policy, latency, and transfer charges still matter. When moving that design to regional networks, specify the connectivity those workloads require.

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 afterward.

• Change becomes coordination. A firewall or route change is made by one team on behalf of many, so requests can wait in a queue when volume is high, capacity is limited, or approval is not delegated. Self-service for the common cases reduces this, and request volume and time to complete show whether it is happening.
• 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.

Separate VPCs retain distinct network administration and policy scopes, while connections to other networks and shared services add operating work. They need not form a full peering mesh. Compare the required routes and isolation with the costs and dependencies of shared networks.

One shared network per environment can be a useful starting design when workloads can share its network controls and change impact. Evaluate separate networks for different trust, operating, or regulatory requirements, and provide a golden path for approved arrangements. The right number follows those requirements rather than a universal default.

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
• Google Cloud, VPC Network Peering
• Google Cloud, Cloud Quotas