Shared VPC and VPC Network Peering

GCP Basics · VPC Networking – Subnets, Firewall, Cloud NAT, Shared VPC and Cloud DNS · Lesson 4 of 6

Shared VPC lets a central host project own the network while service projects deploy into its subnets; VPC Network Peering connects separate VPCs privately but is not transitive.

Two ways to connect workloads that live in different projects.

flowchart TB
  H["Host project dl-network-hub<br/>VPC vpc-shared"] --> SP1["Service project dl-shop-prod"]
  H --> SP2["Service project dl-data-prod"]
  H -- "peering" --> P["VPC vpc-partner<br/>other organization"]
  P -. "not transitive" .-> Q["VPC peered to partner"]
  %% step H: The network team owns vpc-shared, its subnets, firewall rules, routes and NAT in the host project.
  %% step SP1: The shop team creates VMs and GKE clusters in its own project but on subnets of the host VPC.
  %% step SP2: Each service project keeps its own IAM, billing and quotas.
  %% step P: VPC Network Peering joins two separate VPCs so they exchange subnet routes over internal IPs.
  %% step Q: Peering is not transitive: networks peered to the partner are not reachable from vpc-shared.

Shared VPC

Piece	Role
Host project	Owns the VPC network(s)
Service projects	Attached to the host; their resources use the shared subnets
Shared VPC Admin (`roles/compute.xpnAdmin`)	Granted at org/folder; enables the host and attaches projects
Network User (`roles/compute.networkUser`)	Granted to service-project admins on the host project or specific subnets, so they can place resources there

Benefits: one team controls IP plans, firewalls and hybrid connectivity; app teams keep autonomy over their own projects and costs. A service project can attach to only one host project.

gcloud compute shared-vpc enable dl-network-hub
gcloud compute shared-vpc associated-projects add dl-shop-prod --host-project=dl-network-hub

VPC Network Peering

Connects two VPCs, in the same or different projects and organizations.
Both sides must create the peering; it becomes ACTIVE when both exist.
Subnet routes are exchanged automatically; custom routes only if you export/import them.
Subnet ranges must not overlap.
Not transitive: A↔B and B↔C does not give A↔C.
Each side keeps its own firewall rules and IAM.
Traffic stays on Google’s network with no extra latency or gateways.

gcloud compute networks peerings create hub-to-partner --network=vpc-shared   --peer-project=partner-prod --peer-network=vpc-partner

Which one?

Need	Use
Central network team, many app projects in one organization	Shared VPC
Connect separate networks or another organization	Peering
Many VPCs, transitive hub, on-premises	Network Connectivity Center or Shared VPC + VPN
Expose one service privately to consumers	Private Service Connect (lesson 5)

Command	Meaning
`gcloud compute shared-vpc list-associated-resources dl-network-hub`	Attached service projects
`gcloud compute networks peerings list --network=vpc-shared`	Peerings and state

Traps: Network User on the whole host project lets teams use every subnet; peering fails with overlapping ranges; managed services reached through peering (for example Cloud SQL private IP) are not reachable from a second peered VPC.