VPC Peering vs Shared VPC

VPC Peering is a networking connection that allows two VPC networks (in the same or different projects, even across organizations) to communicate using internal RFC 1918 IP addresses. It is not a VPN or a gateway; it is a direct layer-3 connection that routes traffic between the two VPCs without traversing the public internet. The primary use case is connecting independently managed VPCs that need to exchange traffic—for example, a production VPC in one project and a database VPC in another.

When you create a VPC peering connection from VPC A to VPC B, Google Cloud's Andromeda software-defined networking (SDN) stack installs routing rules in both VPCs. Specifically, each VPC learns the subnets of the peered VPC as if they were directly connected subnets. This is not a BGP-based route exchange; it is an implicit route advertisement. The routes are automatically generated and have a priority of 1000 (default). Traffic between peered VPCs flows through Google's internal backbone, not over the internet. The connection is stateful at the firewall level—if VPC A initiates a connection to VPC B, return traffic is allowed automatically. However, firewall rules in both VPCs must permit the traffic; peering alone does not open any ports.

To create a VPC peering connection using gcloud:

gcloud compute networks peerings create PEERING_NAME \
    --network=VPC_A \
    --peer-project=PROJECT_B \
    --peer-network=VPC_B \
    --auto-create-routes

On the other side (VPC B):

gcloud compute networks peerings create PEERING_NAME \
    --network=VPC_B \
    --peer-project=PROJECT_A \
    --peer-network=VPC_A \
    --auto-create-routes

Verification commands:

gcloud compute networks peerings list --network=VPC_A
gcloud compute networks peerings describe PEERING_NAME --network=VPC_A

You can also check routes:

gcloud compute routes list --project=PROJECT_A

Look for routes with nextHopPeering set to the peering name.

Shared VPC (formerly called 'XPN') allows an organization to create a common VPC network in a host project and share its subnets with service projects. This is ideal for centralized network administration, where a network team manages the VPC, firewall rules, and VPN connections, while application teams deploy resources in their own service projects using the shared subnets. Shared VPC is an organizational policy feature that requires an organization node (Google Workspace or Cloud Identity).

A Shared VPC consists of one host project and one or more service projects. The host project owns the VPC, subnets, firewall rules, and routes. Service projects are attached to the host project and are granted access to specific subnets via IAM roles (e.g., compute.networkUser). When a user in a service project creates a VM, they select a subnet from the host project. The VM's VNIC is attached to that subnet, and the VM's internal IP is allocated from the subnet's CIDR. From a network perspective, all VMs in the Shared VPC (across service projects) are in the same L2 domain (if in the same subnet) or can communicate via routing (if in different subnets). Firewall rules are defined in the host project and apply to all VMs, regardless of service project.

- Host project: Must have an organization policy. You cannot create a Shared VPC without an organization node. - Service projects: Can be in the same or different organization (if allowed by policy). - Subnet sharing: You can share all subnets or selected subnets. IAM roles at the subnet level control which service projects can use which subnets. - IAM roles: - roles/compute.xpnAdmin – administer Shared VPC (host project). - roles/compute.networkUser – allows a service project to use subnets (granted at host project or subnet level). - roles/compute.securityAdmin – manage firewall rules in host project. - Maximum number of service projects per host project: 1000 (default quota). - Maximum number of subnets per VPC: 1000 (default). - Resource isolation: VMs in different service projects but same subnet can communicate directly without any additional peering. They share the same broadcast domain. - Firewall rules: Defined in host project; apply to all VMs in the Shared VPC. Service projects cannot create their own firewall rules that affect the shared VPC (unless granted appropriate IAM). - Cost: There is no additional charge for using Shared VPC. You pay for the resources (VMs, etc.) in the service projects and the network resources (VPN, etc.) in the host project.

To enable a host project:

gcloud compute shared-vpc enable HOST_PROJECT_ID

To attach a service project:

gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \
    --host-project HOST_PROJECT_ID

To grant a service project access to a subnet:

gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --add-iam-member=serviceAccount:SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/compute.networkUser

Verification:

gcloud compute shared-vpc list-associated-projects HOST_PROJECT_ID
gcloud compute networks subnets get-iam-policy SUBNET_NAME --region=REGION

VPC Peering is for connecting independent VPCs with potential organizational boundaries, while Shared VPC is for centralizing network management within an organization. The exam will ask you to choose between them based on requirements like centralized firewall management, subnet sharing, transitive peering needs, and organizational structure.

A multinational corporation with 500 projects across 10 business units wants to enforce network security centrally. They use Shared VPC: one host project per region (e.g., us-central1, europe-west1) and attach service projects for each business unit. The network team manages Cloud NAT, Cloud VPN to on-premises, and firewall rules in the host project. Each business unit deploys VMs in their service projects using shared subnets. This setup simplifies compliance because all traffic policies are uniform. However, a challenge arises when a business unit needs a custom firewall rule that conflicts with the central policy—they must request an exception. Misconfiguration: if the host project's firewall rules are too restrictive, application teams may experience connectivity issues and waste time debugging. The network team uses VPC Flow Logs to monitor traffic and adjust rules.

Company A acquires Company B. Both have existing VPCs in Google Cloud with overlapping IP ranges (10.0.0.0/16). They need to connect their environments for a limited time during migration. VPC Peering is not possible due to overlap. Instead, they use Cloud VPN with NAT to translate addresses, or they re-IP one VPC. In production, they set up a temporary VPN tunnel between the VPCs using overlapping CIDR with destination NAT (DNAT) on a third-party appliance. The exam might present this as a scenario: 'Two VPCs with overlapping IPs need to communicate. What solution?' The answer is not VPC Peering; it's Cloud VPN with NAT or re-IP.

A SaaS provider hosts customer environments in separate projects. Each customer needs isolation but must communicate with a shared backend (e.g., database). The provider uses VPC Peering: each customer project's VPC is peered with a central backend VPC. This ensures customers cannot see each other's traffic. However, they must manage 25+ peerings per VPC (limit). They request a quota increase. They also use custom route export/import to propagate routes from the backend to customers. Misconfiguration: if they forget to enable custom route export on the backend, customers cannot reach the database. The exam tests this: 'A company needs to peer 30 VPCs with a central VPC. What is the first step?' Answer: request a quota increase for peering connections.