Explore

Virtual Private Cloud (VPC)

VPC sharing and peering

Google Cloud provides the following configurations for sharing VPC networks across projects and connecting VPC networks to each other.

Shared VPC

A Shared VPC allows multiple projects in the same organization to connect to a centralized VPC network in a host project. Subnetworks in the shared VPC can be used by other service projects, enabling resource isolation while sharing networking resources.

You can share a VPC network from one project (called a host project) to other projects in your Google Cloud organization. You can grant access to entire Shared VPC networks or select subnets therein by using

specific IAM permissions⁠

. This lets you provide centralized control over a common network while maintaining organizational flexibility. Shared VPC is especially useful in large organizations.

For more information, see

Shared VPC⁠

⁠

VPC Network Peering

VPC Network Peering lets you build

software as a service (SaaS)⁠

ecosystems in Google Cloud, making services available privately across different VPC networks, whether the networks are in the same project, different projects, or projects in different organizations.

With VPC Network Peering, all communication happens by using internal IP addresses. Subject to firewall rules, VM instances in each peered network can communicate with one another without using external IP addresses.

Peered networks automatically exchange subnet routes for private IP address ranges. VPC Network Peering lets you configure whether the following types of routes are exchanged:

Subnet routes for privately re-used public IP ranges

Custom static and dynamic routes

Network administration for each peered network is unchanged: IAM policies are never exchanged by VPC Network Peering. For example, Network and Security Admins for one VPC network do not automatically get those roles for the peered network.

For more information, see

VPC Network Peering⁠

⁠

Shared VPC

Definition: A Shared VPC allows multiple projects in the same organization to connect to a centralized VPC network in a host project. Subnetworks in the shared VPC can be used by other service projects, enabling resource isolation while sharing networking resources.

Use Case:

Enterprise Collaboration: When multiple teams or departments work in different GCP projects but need shared access to centralized resources such as databases or firewalls. For example:

The IT team manages networking and security in a host project.

Application teams deploy services in service projects that use the subnets from the shared VPC.

Advantages:

Centralized control over networking.

Simplified management and security (e.g., shared firewalls, routes, IAM policies).

Cost-efficiency by avoiding duplication of resources like VPNs or interconnects.

⁠

VPC Peering

Definition: VPC Peering allows two VPC networks to connect privately, enabling direct communication between resources in both networks without going over the public internet.

Use Case:

Cross-Project or Cross-Organization Communication: When two independent teams or organizations want to share resources but maintain separate administrative domains. For example:

A partner organization wants to access a specific database in your VPC.

Two departments in different GCP projects or organizations need direct connectivity but want to retain full control over their respective networks.

Advantages:

Low latency, high bandwidth.

Simplifies direct access to resources between VPCs.

⁠

Key Differences

Key Differences

Aspect

Shared VPC

VPC Peering

Control

Centralized in the host project

Decentralized; both VPCs have full control.

Use Case

Collaboration within an organization

Communication across projects/organizations.

Resource Sharing

Subnets, routes, firewalls, IAM

Resources are accessed directly from peers.

Network Overlap

Single shared network

Networks must have non-overlapping IP ranges.

IAM Roles

Fine-grained permissions for service projects

No IAM integration; relies on networking rules.

Flexibility

Designed for internal organizational use

Suitable for external or loosely connected teams.

There are no rows in this table

⁠

Decision Framework

Use Shared VPC when:

All projects belong to the same organization.

Centralized networking and security are required.

You want fine-grained IAM control over subnets or resources.

Use VPC Peering when:

Projects are in different organizations or administrative domains.

Minimal dependencies and no centralized control are needed.

You need to connect two independent networks privately.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.