GCP VPC Peering Explained: Private Connectivity Between Two Networks

What is VPC peering in GCP?

VPC peering is a GCP networking feature that creates a direct, private connection between two VPC networks. Once peered, resources in each VPC can reach resources in the other using internal IP addresses — the same way they would communicate within a single network.

The connection runs over Google’s internal backbone. Traffic between peered VPCs does not leave Google’s infrastructure, which means lower latency and no exposure to the public internet. There are no bandwidth charges for traffic between peered VPCs in the same region.

VPCs can be in the same GCP project or in completely separate projects, even across different organisations. Both sides must actively create a peering object pointing at the other. If only one side creates theirs, the peering stays INACTIVE — it only becomes ACTIVE once both sides have created their respective connections.

One characteristic that trips people up: VPC peering is non-transitive. Two peered VPCs do not automatically trust each other’s other peering connections. This becomes important once you start designing multi-VPC architectures.

How VPC peering works

When you create a peering connection, you are creating a relationship object in your VPC that says “I want to peer with this network in that project.” The other project must create a matching object pointing back at yours.

INACTIVE state: one side has created the peering object, but the other side has not yet responded. Routes are not exchanged and no traffic flows.

ACTIVE state: both sides have created their respective connections. Subnet routes are exchanged automatically and traffic can flow between the two networks.

Each VPC still enforces its own firewall rules independently. Peering only handles routing — it does not merge firewall policies or share network tags across the peering boundary.

Non-transitive routing: the A–B–C problem

Non-transitive means peering does not chain through intermediate networks. Suppose you have three VPCs:

• VPC A is peered with VPC B
• VPC B is peered with VPC C

Resources in A can reach resources in B. Resources in B can reach resources in C. But resources in A cannot reach resources in C — there is no route from A to C, even though B is connected to both.

In real environments this matters when you try to use a central “hub” VPC as a transit point. Traffic will not flow through it. Every pair of VPCs that needs to communicate requires its own direct peering connection. For three VPCs needing full connectivity, that is three pairs: A–B, B–C, and A–C. For five VPCs it becomes ten connections. The number grows quickly, and each consumes one of your 25 available peering slots.

When to use VPC peering

VPC peering is the right tool when two clearly defined networks need private communication and each needs to stay independently managed. Common situations include:

• Separate projects with shared services. An application in project-a needs to reach a shared database or caching service in project-b. Peering means those connections use internal IPs with no internet exposure.
• Different teams with their own VPCs. Each team manages their own network and firewall rules but needs to communicate with another team’s services. Peering connects them without forcing them into a shared network.
• Application and database in separate projects. Keeping application VMs and databases in separate projects with a peering connection between them is a common isolation pattern. Services reach each other over private IPs with no public exposure.
• Google-managed services. Cloud SQL, Memorystore, and similar managed services run in Google-owned VPCs. When you enable a private IP for one of these services, GCP establishes a peering connection from the managed VPC to yours — which is why those services appear reachable at internal IPs from your VMs. This uses Private Service Access, which is built on VPC peering.
• Cross-organisation connectivity. Unlike Shared VPC, peering works across different GCP organisations. If two separate companies need private connectivity between their GCP workloads, VPC peering is one of the few options that does not require a shared organisation node.

When not to use VPC peering

Peering is not always the right choice. Consider an alternative in these situations:

• Large organisations with many teams. If teams are in the same organisation and a central networking team should control IP ranges, subnets, and access policies, Shared VPC is the better fit. Shared VPC provides one flat network for all service projects, removes the 25-connection limit, and simplifies IP planning across the organisation.
• Connecting to on-premises or other clouds. Peering is strictly GCP-to-GCP. For hybrid connectivity to on-premises infrastructure, you need Cloud VPN or Cloud Interconnect. The hybrid connectivity overview covers when to use each option.
• Mesh architectures with many VPCs. Once you need more than a handful of VPCs all talking to each other, peering connections multiply fast and the 25-connection cap becomes a hard constraint. Network Connectivity Center (NCC) provides a hub-and-spoke model with transitive routing, which avoids the combinatorial explosion of peering pairs.
• Architectures that depend on transitive routing. If your design routes traffic through a central firewall or proxy VPC before it reaches its destination, peering alone will not support that. NCC or a network virtual appliance with custom routing is needed.

Requirements before creating a VPC peering connection

Before setting up peering, verify that both VPCs meet these requirements:

• Non-overlapping subnet CIDRs. All subnet ranges across both VPCs must be unique. This includes ranges in any VPCs already peered with either side. Overlapping CIDRs cause GCP to reject the peering request, and re-addressing subnets after VMs are deployed is painful.
• Both networks must create their own connection. Peering requires a connection object in each VPC pointing at the other. One-sided peering stays INACTIVE. Neither side can complete the peering for the other.
• Correct permissions on each side. The person creating the peering in each project needs compute.networks.addPeering, included in roles/compute.networkAdmin. You do not need access to both projects — each side is set up independently.
• No organisation node required. Unlike Shared VPC, peering works across different organisations. There is no shared resource hierarchy needed.
• 25-connection limit per VPC. Plan your topology before peering. If you expect to exceed this, consider Shared VPC or Network Connectivity Center from the start.

How to create a VPC peering connection

Both VPCs must each create a peering connection pointing at the other. Run the first command in project-a, then the second in project-b. The peering stays INACTIVE until both sides are complete.

# In project-a: peer network-a to network-b in project-b
gcloud compute networks peerings create peer-a-to-b \
  --network=network-a \
  --peer-project=project-b \
  --peer-network=network-b \
  --auto-create-routes \
  --project=project-a

# In project-b: peer network-b back to network-a in project-a
gcloud compute networks peerings create peer-b-to-a \
  --network=network-b \
  --peer-project=project-a \
  --peer-network=network-a \
  --auto-create-routes \
  --project=project-b

# Verify peering state from project-a
gcloud compute networks peerings list \
  --network=network-a \
  --project=project-a

The —auto-create-routes flag tells GCP to automatically exchange subnet routes between the two VPCs. Once both sides have created their respective peering, the state column in the list output should show ACTIVE. You should also see the peer’s subnet routes appear in each network’s routing table.

Route exchange in peered VPCs

With —auto-create-routes in place, each VPC automatically exports its subnet routes to the peer when the peering becomes ACTIVE. VMs in network-a can route to any subnet in network-b and vice versa — no manual route entries required for subnet-to-subnet communication.

Custom static routes are not exported by default. If you have a custom route pointing to a next-hop (such as a firewall appliance VM) and you want the peer to use that route too, you need to explicitly enable custom route export and import. See Routes in GCP for how custom routes and next-hops work.

# Export custom routes from network-a to the peer
gcloud compute networks peerings update peer-a-to-b \
  --network=network-a \
  --export-custom-routes \
  --project=project-a

# Import custom routes from the peer into network-b
gcloud compute networks peerings update peer-b-to-a \
  --network=network-b \
  --import-custom-routes \
  --project=project-b

Custom route export is mainly used when one VPC hosts a network virtual appliance — a firewall VM or proxy — and you want traffic from the peer to flow through it before reaching its destination. Without explicit export and import enabled, the peer will not see those custom routes and will not use the appliance.

Firewall rules across peered VPCs

VPC peering exchanges routes, but firewall rules stay completely independent. Each VPC enforces its own rules on inbound and outbound traffic. Traffic from a peered VPC is identified by its source IP, which falls within the peer’s subnet CIDR range.

A common mistake is establishing peering, seeing routes appear, and assuming traffic will now flow. It will not — GCP’s default behaviour is to block ingress unless you explicitly allow it. If VMs in network-b need to reach a PostgreSQL database in network-a on port 5432, you need an ingress rule in network-a that permits traffic from network-b’s subnet range on that port.

# Allow ingress from a peered VPC subnet to a PostgreSQL instance in network-a
gcloud compute firewall-rules create allow-peered-postgres \
  --network=network-a \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-ranges=10.20.0.0/16 \
  --description="Allow network-b (peered VPC) to reach PostgreSQL"

Network tags do not carry across peering boundaries — they are scoped to the VPC that owns them. Use subnet CIDR ranges as source filters when writing firewall rules for peered traffic.

VPC peering vs Shared VPC

These two features are often confused because both enable multiple GCP projects to share private network connectivity. They work quite differently.

With Shared VPC, one project is designated the host and owns the VPC. Other service projects attach to it and use subnets from that shared network. There is one network, one IP space, one set of subnets — managed centrally by the host project’s networking team.

With VPC peering, each VPC remains fully independent. Both sides manage their own subnets, firewall rules, and IP ranges. Peering only exchanges routes between them. Neither side controls the other’s network.

Rule of thumb: use Shared VPC when teams are within the same organisation and a central team should own the network. Use VPC peering when networks are independently owned, need their own firewall policies, or belong to different organisations.

VPC peering vs Cloud VPN

VPC peering is for private GCP-to-GCP connectivity. Both VPCs live inside Google’s network and the peering connection uses Google’s internal backbone — no encryption overhead, no tunnels, no public IPs involved.

Cloud VPN is for connecting GCP to something outside Google’s network — typically an on-premises data centre or another cloud provider. Traffic passes through an IPsec tunnel, usually over the public internet. Cloud VPN handles encryption at the expense of some additional latency and per-GB tunnel charges.

If both networks are GCP VPCs and the goal is low-latency, high-bandwidth private communication, peering is the right choice. If one side is outside GCP — or if your policy requires encrypted tunnels even between GCP regions — use Cloud VPN. For high-bandwidth dedicated private circuits to on-premises infrastructure, Cloud Interconnect provides lower latency and higher throughput than VPN at the cost of a physical circuit.