Several Google Cloud Projects, One Hybrid VPN? Decide First
Shared VPC, peering and a connectivity hub answer different ownership questions. Pick the network boundary before you deploy one VPN per project.
When several Google Cloud projects need hybrid access, the instinct is one VPN per project, and it is almost always the wrong shape. Project ownership and packet routing are related but different concerns, and the useful architecture keeps the administrative boundaries you need while giving the intended prefixes one deliberate path to the office or data centre. These checks settle which network model you actually want, in the order that avoids rework. Each one can end the discussion early, which is the point.
A project boundary does not automatically require its own tunnel.
Check whether the shared object is the network
Start with a question about ownership, not connectivity: can central network ownership support these workloads? If the answer is yes and the organization has an eligible configuration, a host project owns the VPC, subnets and connectivity while service projects own their application resources. One Cloud VPN connection in that shared network can then serve the intended workload prefixes, subject to routing and security policy.
Be precise about what association does. Attaching a service project does not merge its existing independent VPC into the host network, and it does not move every resource automatically. Workload attachment, permissions, address space and DNS are all part of the architecture, not consequences of the setting. Read the association as a permission change first and a routing change second, because teams usually discover the difference during cutover.
If central ownership is not acceptable to the teams involved, stop here and treat the rest as a peering or hub design. Forcing Shared VPC onto a group that needs independent network lifecycles produces a political problem with a technical name.
Check whether independent VPCs can stay independent
Peering preserves separate VPCs, which is exactly why it attracts teams that want their own address plans and their own change control. The catch is that peering is not transitive: A-to-B and B-to-C peering does not by itself create A-to-C routing through B. If three projects need to reach one hybrid destination, you need a deliberate exchange plan rather than a chain of peerings.
Sharing hybrid reachability also depends on the documented custom-route exchange and the intended Cloud Router advertisements. A peering status of active proves the peering exists, not that the prefixes each side cares about were ever exported. Check the exported ranges on both sides of the peer, in the configuration that does the exporting, and compare them against the addresses your workloads actually use. A mismatch there is the most common reason a peering looks healthy while a prefix stays unreachable.
Write the address plan before anything else. Nonoverlapping ranges, the routes toward every intended destination and the return advertisements are the three artifacts this model lives or dies on.
Check whether a hub model fits the topology
For a larger or differently segmented design, Google's Network Connectivity Center overview describes the hub and spoke models. Read it for what the current release supports rather than for what the diagram implies: which VPC and hybrid combinations, which route families and which policies each spoke type allows.
Check the address family explicitly. Planning examples in most guides, including this one, concern IPv4, and a feature that exists for one spoke type does not automatically apply unchanged to another. If your estate is dual-stack, that question belongs in the model choice, not in a later migration.
The table below is the recap of the three models and the question that decides each.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Check what routing does not grant
Route exchange is not a blanket grant of trust. DNS resolution, firewall permission and application authorization remain their own responsibilities, and each is configured by a different owner in most organizations. A design that assumes reachability implies authorization will pass its connectivity test and fail its security review.
Confirm the DNS story for each model as well, because the zone and forwarding arrangements differ between a shared network and peered networks. Private names that resolve in one project do not follow a route into another.
Record the decision and its owner
Centralize where the organization wants a shared network owner; keep separate VPCs where lifecycle or policy requires it. Then choose a supported connectivity relationship and write down which one you chose, who owns the shared network, and what each project is allowed to advertise.
Counting projects and buying one VPN for each is not a substitute for that ownership decision. It is the same decision, made later, by whoever inherits the bill and the routing table.