Shared VPC and VPC Peering

Introduction

Enterprise GCP deployments almost never live in a single project. Compliance, billing, blast-radius isolation, and team autonomy all push organizations toward dozens or hundreds of projects, each of which still needs to talk to shared platform services like Cloud SQL, internal APIs, and centralized egress. Google Cloud answers this with two distinct multi-project networking primitives: Shared VPC (also called XPN, Cross-Project Networking) and VPC Network Peering. They look superficially similar — both let workloads in different projects reach each other over RFC 1918 addresses without traversing the public internet — but they solve fundamentally different problems.

Shared VPC is a governance model: one central network/security team owns the VPC, subnets, firewall rules, and routes in a host project, while application teams deploy VMs, GKE nodes, and load balancers from their own service projects into those subnets. VPC Peering, in contrast, is a point-to-point connectivity primitive between two equal VPC networks with no shared administration. For the Professional Cloud Network Engineer (PCNE) exam, you must be able to choose between them based on the scenario's governance, autonomy, transitivity, and IAM requirements, and you must know the hard constraints — non-transitive routing, no overlapping CIDRs, the 25-peering quota per VPC, and the inability of peering to honor IAM-based access control.

Shared VPC Architecture: Host, Service, and Org-Attached Projects

Shared VPC introduces three distinct project roles that you must keep straight on the exam. The host project is the project that physically owns the VPC network, its subnets, firewall rules, and routes. You designate a project as a host with gcloud compute shared-vpc enable PROJECT_ID, which sets the project resource's xpnProject attribute to true. A host can serve many service projects, but a host cannot itself also be a service project of another host — the relationship is strictly two-tier, not chained.

Service Project Attachment

A service project is any project explicitly attached to a host via gcloud compute shared-vpc associated-projects add SERVICE_PROJECT --host-project HOST_PROJECT. Once attached, eligible resources (Compute Engine VMs, GKE clusters, internal/external load balancers, Cloud Run direct VPC egress, Dataproc clusters, App Engine flexible, Cloud Functions Gen 2) created in the service project can specify a subnet that lives in the host project's VPC. The VM's billing, IAM, and project-level quotas remain in the service project, but its NIC physically attaches to a subnet owned by the host.

Org-Attached vs Folder-Attached Hosts

Shared VPC was historically a project-scoped construct, but the Organization Policy compute.restrictSharedVpcSubnetworks and the newer org-level Shared VPC attachment allow a single host to expose subnets to projects across an entire org or folder without listing each service project. Attaching at the org level reduces administrative overhead in large enterprises but raises the blast radius if the host project's network admin makes a mistake — every project in the org can suddenly access the shared subnets.

Two-Tier Restriction

A host cannot be a service project of another host. Practically, this means you cannot build a hierarchy like team-host → division-host → corporate-host. If you need cross-host connectivity, you must use VPC Peering between two host VPCs, HA VPN, or Network Connectivity Center. The exam loves to test this — any scenario that proposes chaining Shared VPCs is wrong.

Shared VPC IAM: Network User vs Service Project Admin

Shared VPC is the only GCP networking primitive whose access is gated almost entirely by IAM rather than firewall rules. Three roles dominate exam questions, and confusing them is the most common Shared VPC trap.

compute.xpnAdmin (Shared VPC Admin)

Granted at the organization or folder level, roles/compute.xpnAdmin lets the holder enable a project as a host, attach/detach service projects, and grant compute.networkUser on subnets. This role is intended for the central network/platform team. It does not by itself let the admin create VMs or modify firewall rules — those need additional roles.

compute.networkUser (Network User)

Granted on a subnet (or on the entire host project), roles/compute.networkUser lets a principal in a service project create resources that attach to that subnet. The principle of least privilege says you grant this at the subnet level — for example, team-prod-sa@svc-proj gets networkUser only on subnet-prod-us-east1, never on the whole host project. Granting it on the project gives access to every subnet in every region of the host's VPCs.

compute.networkAdmin and compute.securityAdmin

These are the host-side roles for managing the network itself: networkAdmin creates/modifies subnets, routes, peerings, and Cloud Routers; securityAdmin manages firewall rules and SSL certs. Service project admins never get these — they only consume subnets via networkUser.

Service Account Considerations

When a service project's VM is created in a host subnet, the VM uses the service project's default Compute Engine service account (or a user-supplied SA). That SA must have roles/compute.networkUser on the subnet, and the host project's GKE/Compute service agents (e.g., service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com) must have the appropriate host-side roles. Missing the host service agent grants is one of the most common Shared VPC setup failures.

When to Use Shared VPC vs VPC Peering

The choice between Shared VPC and Peering is one of the most frequently tested architectural decisions in PCNE. Reduce it to four axes:

Governance Axis

• Shared VPC = centralized governance. One team owns IPs, routes, firewall rules. Service projects can only consume.
• Peering = federated governance. Each VPC is owned by its own team. Both sides manage their own firewalls, routes, and subnets independently.

Transitivity Axis

• Shared VPC = naturally transitive within the host VPC. All service projects can reach each other because they share routes.
• Peering = strictly non-transitive. A↔B and B↔C does not imply A↔C.

IAM-Controlled Access Axis

• Shared VPC = IAM gates who can attach to which subnet. You can lock prod subnets to one team and dev subnets to another with subnet-level networkUser grants.
• Peering = no IAM filtering. Once two VPCs are peered, all subnets become routable. You can only restrict at the firewall/route layer.

Scale and Quota Axis

• Shared VPC = up to ~1,000 service projects per host, single VPC's quotas apply.
• Peering = limit of 25 active peerings per VPC by default (soft, raisable to ~50). Beyond that you must consolidate via NCC or Shared VPC.

VPC Network Peering Fundamentals

VPC Peering connects two VPC networks so that VMs in either VPC can reach each other using internal IPs as if they were on the same network. The connection is bidirectional — once established, both sides exchange subnet routes — but it must be created on both sides for the peering to become ACTIVE. If only one side runs gcloud compute networks peerings create, the peering shows INACTIVE until the counterpart side does the same.

Symmetric Configuration

Both peerings must agree on names of the peer network, project, and the import/export route flags. A mismatch (e.g., one side --export-custom-routes and the other side --no-import-custom-routes) leaves the peering active but causes custom routes to silently not propagate, which is a classic debugging trap.

Same Org, Different Org, Same Project

You can peer VPCs that live in the same project, different projects under the same organization, or different organizations entirely. Cross-org peering does not require an org-level relationship — only that both sides know the other's project ID and VPC name. This makes peering popular for partner/B2B integrations.

No Public Internet Path

Peering traffic stays on Google's private backbone and never traverses the public internet. There is no egress charge for traffic within the same region across a peering, and inter-region peered traffic is billed at standard inter-region network rates. This is a major cost advantage over building VPN tunnels between VPCs.

Bidirectional Route Exchange

Peering automatically exchanges subnet routes (the routes Google auto-creates when you make a subnet) in both directions. Static routes and dynamic (BGP) routes from Cloud Router are exchanged only when you enable --export-custom-routes on the exporter side and --import-custom-routes on the importer side.

Non-Transitive Peering and the Hub-and-Spoke Problem

The single most exam-tested property of VPC Peering is non-transitivity. If VPC A peers with VPC B, and VPC B peers with VPC C, then A cannot reach C through B. Google's data plane simply does not forward packets between two peerings on the same VPC. This is enforced at the network virtualization layer, not by firewall rules — there is no firewall toggle to enable transitivity.

Why Non-Transitive

Transitive routing would let any peered VPC accidentally leak routes across a long chain, creating security and quota nightmares. Google's design forces you to make transitive intent explicit by deploying a transitive routing layer.

How to Achieve Transitive Routing

• Network Connectivity Center (NCC) with VPC spokes — the modern, native answer; a single NCC hub can connect many VPCs and provides full transitive mesh among spokes.
• HA VPN tunnels between VPCs — VPN gateways forward traffic regardless of peering rules, but at the cost of bandwidth caps (~3 Gbps per tunnel) and BGP complexity.
• A central proxy/router VM in the middle VPC — works for low-throughput workloads but adds an SPOF and operational burden.

Hub-and-Spoke vs Full Mesh

A common pattern is a central "transit" VPC peered with many spoke VPCs. Without NCC, spokes can each reach the hub but cannot reach each other. Switching the hub to an NCC VPC-spoke hub immediately makes the topology transitive without re-peering.

CIDR Overlap, Subnet Conflicts, and Address Planning

VPC Peering and Shared VPC both enforce a strict rule: no overlapping IP ranges between connected networks. This rule applies to primary subnet ranges, secondary ranges used by GKE, and static routes' destinations.

The Overlap Check

When you create a peering, GCP scans every subnet in both VPCs and rejects the operation if any range overlaps. The error message is subnets in network NETWORK_A overlap with subnets in network NETWORK_B. The check is purely range-based — even if a /24 in VPC A is unused, the peering fails if VPC B has the same /24.

Secondary Ranges Count

GKE clusters use secondary ranges for Pods (pod-range) and Services (service-range) on the subnet. These ranges are also checked for overlap. A common mistake is allocating the same 10.4.0.0/14 Pod range in two clusters that later need to communicate — the second peering fails.

Static Route Destinations

Custom static routes whose destination overlaps with the peer VPC's subnet routes are blocked from being imported even with --import-custom-routes. The peering carries the route entry but marks it as conflicting and the data plane drops it.

Address Planning Best Practice

For any organization that will eventually use Shared VPC or Peering, carve up RFC 1918 space hierarchically: reserve a /16 per environment, a /20 per region, a /24 per subnet. Document the plan in an IPAM tool before the first VPC is created. Retrofitting non-overlapping CIDRs is enormously painful — it requires either renumbering VMs or building a NAT-based proxy layer.

Privately Used Public IPs

Cloud VPN and Peering both support privately used public IPs — RFC 1918 is conventional but not required. You can route public ranges privately if you don't need them for internet egress. This is rare but appears occasionally in exam scenarios about routing to acquired companies whose on-prem uses public IPs.

Dynamic vs Static Peering Routes (Import/Export Custom Routes)

By default, VPC Peering exchanges only subnet routes (also called auto-created routes). Anything else — static routes you created with gcloud compute routes create, or dynamic BGP routes learned from Cloud Router via Cloud VPN/Interconnect — is not exchanged unless you explicitly enable custom route exchange.

--export-custom-routes

On the exporting VPC's peering, set --export-custom-routes. This tells GCP to include both static custom routes and dynamic routes (learned from BGP via Cloud Router) in the route advertisement to the peer. There is no separate flag for static vs dynamic — the export flag covers both.

--import-custom-routes

On the importing VPC's peering, set --import-custom-routes. The peering will accept advertised custom routes and install them in the importer's VPC route table.

--export-subnet-routes-with-public-ip and --import-subnet-routes-with-public-ip

Some subnets use privately used public IPs (publicly routable address space deployed privately). By default these subnet routes are not exchanged across peering. The *-with-public-ip flags opt them in. Required when peering with VPCs that announce non-RFC-1918 ranges internally.

Asymmetric Configuration Trap

If side A enables --export-custom-routes but side B does not enable --import-custom-routes, the routes are advertised but ignored. The peering still shows ACTIVE — there is no error. Always set the corresponding flag on both sides when you intend custom routes to flow.

Cloud Router Aggregation

When BGP routes from on-prem flow through Cloud Router into a hub VPC, and the hub is peered to spoke VPCs, the spokes only see those on-prem routes if --export-custom-routes is set on the hub peering. This is the wiring for "Cloud VPN/Interconnect lands in hub VPC, spokes consume on-prem connectivity via peering" — a very common architecture pattern.

Cross-Organization Peering and Multi-Org Topologies

VPC Peering does not require any organizational relationship between the two sides. Any project owner with compute.networks.addPeering permission can peer to any other VPC if they know its project ID and network name. This is what makes peering attractive for M&A integrations, partner connectivity, and multi-tenant SaaS architectures.

Cross-Org Setup

The two sides exchange project IDs and VPC names out-of-band (Slack, email, ticket). Each side runs gcloud compute networks peerings create PEERING_NAME --network=LOCAL_VPC --peer-project=PEER_PROJECT --peer-network=PEER_VPC. As long as the names match and CIDRs don't overlap, the peering becomes ACTIVE.

Org Policy Gating

The org-level policy constraints/compute.restrictVpcPeering lets a central security team allowlist or denylist peering target projects. Setting this to an IN list restricts engineers from peering to arbitrary external orgs without security review.

IAM Audit Trail

Every peering create/delete is logged in Cloud Audit Logs under compute.googleapis.com/networks.addPeering. Use Log Sink + BigQuery or SIEM integration to detect rogue cross-org peerings.

Service Networking Peering for Managed Services

When you use Private Service Access (Cloud SQL private IP, Memorystore, etc.), GCP creates a service-networking-managed peering between your VPC and Google's services VPC. That peering counts against your 25-peering quota and exports its routes via the standard custom-route flag. The peer network name follows the pattern servicenetworking-googleapis-com.

Peering Quotas, Limits, and Scaling Constraints

Peering has several hard and soft limits that show up in exam scenarios about large topologies.

Active Peerings per VPC

Default soft quota is 25 active peerings per VPC, raisable to 50 via Cloud support. Each peering consumes one slot regardless of direction or whether it's intra-org or cross-org. Beyond 50, you must consolidate via NCC or Shared VPC.

Routes per VPC

A peered VPC inherits its peer's subnet routes. The combined route count is bounded by the VPC's dynamic routing quota (~250 routes per VPC by default, raisable). A hub VPC with 25 peers each exporting 10 subnets sees 250 inbound routes — right at the default ceiling. Plan route aggregation or quota increases before hitting the wall.

Subnets per VPC

A single VPC can have up to 7,000 subnets by default. Combined with the 25-peering limit, this drives most large orgs toward Shared VPC rather than peering as the consolidation pattern.

Internal Load Balancer Reachability

Across peering, internal TCP/UDP load balancers (ILBs) are reachable from peer VPCs by default. Internal HTTP(S) load balancers are reachable too via the global access flag. Internal Network Load Balancers (regional, passthrough) require the --global-access flag for cross-region or cross-peering access. This is a subtle but commonly tested detail.

Cloud DNS Visibility

Private DNS zones do not automatically propagate across peering. You must either share the private zone with the peer VPC explicitly (Cross-Project DNS Binding via gcloud dns managed-zones create --visibility=private --networks=...) or use Cloud DNS peering zones.

Network Connectivity Center for Transitive Routing

NCC is the modern, supported way to achieve transitive routing across multiple VPCs without building a mesh of peerings.

Hub-and-Spoke Model

You create an NCC hub (a regional resource in a hub project) and attach VPC networks as VPC spokes. All spokes connected to the hub automatically gain transitive reachability to each other — no manual peering required between spokes.

Site-to-Cloud Spokes

NCC also supports hybrid spokes — HA VPN tunnels and Cloud Interconnect VLAN attachments — letting you mix VPCs and on-prem sites in the same hub. This is how Google positions NCC against AWS Transit Gateway and Azure Virtual WAN.

Route Policy and Filtering

NCC supports BGP-style route policies on a spoke, letting you accept or reject specific prefixes. You cannot do this with raw VPC Peering — peering exports everything or nothing based on the custom-route flag.

NCC vs Shared VPC vs Peering Decision

• Choose Shared VPC when one team should govern all networking and many service projects need to share IP space.
• Choose VPC Peering for one-off, low-cardinality connections (≤25 partners) with no transitivity needed.
• Choose NCC for transitive, scalable multi-VPC topologies, especially with hybrid spokes.

白話文解釋（Plain English Explanation）

Shared VPC: The Industrial Park with a Single Landlord

Think of Shared VPC like an industrial park where one landlord (the host project) owns all the land, paves all the roads, runs the power grid, and writes the lease agreements (firewall rules). Tenants (service projects) move into specific lots (subnets) and run their factories there. The tenants pay their own electricity bills (egress charges), hire their own workers (run their own VMs and quotas), but they cannot move the roads or change the lease terms — that is the landlord's job. The IAM grant networkUser is the lease that lets a tenant occupy a specific lot. If you wanted to give a new tenant access to a different lot, the landlord would grant them networkUser on that subnet, never on the whole park.

VPC Peering: Two Neighbors Knocking a Doorway Through the Wall

VPC Peering is like two neighboring houses sharing a wall and deciding to knock a doorway through it. Now their kids can run between living rooms without going outside (the public internet). But each parent still owns their house, sets their own rules (firewall rules), and pays their own bills. Critically, if a third neighbor has a doorway with house B, the kids in house A still can't reach house C — they would have to either knock their own doorway with C or have all three houses meet in a shared courtyard (NCC). The "no overlapping CIDRs" rule is like saying both houses must have different street addresses; if they shared the same address, the mailman wouldn't know where to deliver letters.

Custom Route Exchange: Sharing Your Address Book

The --export-custom-routes and --import-custom-routes flags work like sharing your address book with a friend. By default, when you peer two networks, you only share your immediate neighbors' addresses (subnet routes). If your friend wants to know all the addresses you learned from your phone company (BGP routes from Cloud Router) or from your private notebook (static routes), you have to actively flip the "share my whole address book" switch on your side, and your friend has to flip the "I accept your whole address book" switch on their side. If only one side flips the switch, nothing happens — both sides must agree. This is why misconfigured peerings often look "ACTIVE" but silently drop custom routes.

FAQs

Can a Shared VPC host project be peered with another VPC?

Yes. A Shared VPC host's VPC behaves like any other VPC from the peering perspective. You can peer it with another VPC (Shared or not) to extend connectivity, subject to the 25-peering quota. This is a common pattern: corporate Shared VPC peers with a third-party SaaS partner's VPC.

Does VPC Peering increase latency or cost?

No measurable latency increase. Peering uses the same Jupiter fabric as intra-VPC traffic. Cost-wise, intra-region peered traffic is free, and inter-region peered traffic is billed at standard inter-region egress rates — strictly cheaper than running a VPN tunnel between the two VPCs.

Can I revoke compute.networkUser on a subnet to evict a service project's VMs?

Revoking networkUser immediately prevents new resources from being created on that subnet, but does not delete existing VMs. To force-evict, you must delete the VMs explicitly. This is a frequent operational surprise.

How does GKE use Shared VPC?

GKE clusters in a service project can be deployed into a host project's subnet by specifying --network=projects/HOST/global/networks/VPC --subnetwork=projects/HOST/regions/REGION/subnetworks/SUBNET. The cluster's Pod and Service secondary ranges must already be defined on that subnet, and the GKE service agent must have compute.networkUser on the subnet and on the secondary ranges.

What happens to traffic between two subnets when the peering is deleted?

All routes learned from the peer are immediately withdrawn from the VPC route table, and in-flight TCP connections are dropped. There is no graceful drain. Plan a maintenance window before deleting peerings used by production workloads.

Can I peer IPv6 subnets?

Yes — VPC Peering supports IPv6 subnet routes if both VPCs are dual-stack enabled. The IPv6 ranges follow the same non-overlap rule (within each VPC's allocated ULA or external GUA blocks) and the same custom-route flags.

Why doesn't my Cloud SQL private IP work after I peer two VPCs?

Cloud SQL Private Service Access uses its own service-networking peering. The peering between your VPCs does not transitively share the Cloud SQL service-networking peering — that would require transitive routing. Workarounds: (a) replicate the Cloud SQL instance per VPC, (b) put both VPCs as NCC spokes, or (c) use the Cloud SQL public IP with Authorized Networks.