# VPC Peering and Shared VPC

> Chapter 6 of the Courseiva GOOGLE-PCNE curriculum — https://courseiva.com/learn/google-pcne/vpc-peering-and-shared-vpc

**Official objective:** 4.1 — Implement VPC peering and Shared VPC for multi-project connectivity

## Introduction

VPC peering and Shared VPC solve the problem of connecting multiple isolated cloud networks so that resources like virtual machines (VMs) can talk to each other privately, using internal IP addresses instead of going over the public internet. For the PCNE exam, knowing when to use peering versus a shared VPC — and how to configure the security rules for each — is a core skill that appears in multiple questions.

## The Shared Apartment Complex Analogy

When you move into a new city, your first instinct is to rent a private apartment in a large building. Your apartment is isolated from everyone else by locked doors and walls. If you want to share a pizza with a friend in the next flat, you can't just knock through the wall — that's against the building's rules. So you set up a peering agreement: you both install a small, private door between your flats that only you two can use. That's VPC peering: a direct, one-way or two-way private link between two isolated networks (apartments) in the same building (the cloud).

Now imagine you're part of a big family that rents multiple flats in the same building, but you all want to share one central kitchen and a laundry room. Instead of each flat buying its own washing machine, the building management creates a shared facility that everyone in your family can use. Each flat still has its own lock, but the family has a master key that lets anyone enter the shared areas without knocking on individual doors. That's Shared VPC: a single, central Virtual Private Cloud (VPC) project that acts as the 'common area' network, and other projects (flats) are given controlled access to it. The family is your organisation, the building is Google Cloud, and the master key is IAM permissions that let you use the shared VPC's subnets, firewalls, and routes without owning them.

## Core explanation

In Google Cloud, every project you create gets its own Virtual Private Cloud (VPC) network by default. A VPC is a virtual, isolated network that runs inside Google's global infrastructure. Think of it as your own private slice of the cloud, complete with its own IP address range, firewalls, and routing rules. By default, VPCs in different projects cannot communicate with each other — they are like separate, locked rooms.

VPC peering is a way to bridge two or more of these isolated networks. When you set up VPC peering between Project A and Project B, you create a direct, private connection between their VPCs. Traffic between the two networks stays entirely inside Google's backbone network — it never touches the public internet. This means lower latency, higher security, and no egress charges for data leaving Google's network. Peering is a one-to-one relationship: you must explicitly set it up for each pair of VPCs you want to connect. It does not create a transitive connection — if A peers with B, and B peers with C, A cannot automatically talk to C. You would need a separate peering between A and C. This is called the non-transitivity of VPC peering, and it's a favourite exam trap.

Shared VPC, on the other hand, is designed for organisations that want to centralise network management across many projects. In a shared VPC architecture, one project is designated as the 'host project'. That host project contains a VPC network that acts as the shared network. Other projects, called 'service projects', are attached to the host project. Resources like Compute Engine VMs (virtual machines) in the service projects can be placed into subnets that live in the host project's VPC. All those VMs share the same network, the same internal IP range, the same firewalls, and the same routes. This is useful when you have a team of developers who each need their own project (for isolation and cost tracking), but they all need to talk to a shared database or a set of backend services running in the host project. The network administrator for the host project controls all networking, while project owners in service projects only manage their own resources — they cannot change the shared network's firewalls or routes.

The key difference between the two is about who owns the network. With VPC peering, each project owns its own VPC and they negotiate a handshake to connect. With Shared VPC, one project owns the network and simply lends out parts of it to other projects. Another important distinction is that Shared VPC supports transitive routing within the host network. If service project A has a VM in subnet 1, and service project B has a VM in subnet 2 of the same shared VPC, they can talk directly because they are on the same VPC. VPC peering would require two separate peering connections.

When should you use each? Use VPC peering when you have two separate organisations or business units that need a private link but want to remain fully independent — for example, connecting your company's VPC with a partner's VPC. Use Shared VPC when you are inside the same organisation and you want centralised control over the network, with projects acting as isolated containers for resources that all need access to a common network.

A critical detail for the exam: both VPC peering and Shared VPC require IAM permissions to set up. For peering, you need 'compute.networks.updatePeering' on both networks. For Shared VPC, you need the Shared VPC Admin role (roles/compute.xpnAdmin) at the organisation level or on the host project. Also remember that you can combine both: you can have a shared VPC in a host project, and then use VPC peering to connect that shared VPC to another company's VPC.

Firewall rules behave differently. In a peering setup, each network maintains its own firewall rules. Traffic that comes through a peering connection is subject to the egress firewall rules of the source network and the ingress firewall rules of the destination network. In a shared VPC, all service projects inherit the firewall rules defined in the host project's VPC. However, service projects can also create their own firewall rules to further restrict traffic, as long as those rules are not in conflict with the host project's rules.

Another exam favourite: IP address ranges. When peering, the VPCs must have non-overlapping IP address ranges. If they overlap, you cannot set up peering. With Shared VPC, you are essentially using subnets from the same VPC, so overlapping is impossible by design. This is why Shared VPC is often simpler when you have many projects that need to communicate.

## Real-world context

Imagine you work as a cloud engineer for a medium-sized e-commerce company. The company has three distinct teams: the website team, the payments team, and the analytics team. Each team develops its own microservices and needs its own Google Cloud project for budget tracking and IAM isolation. However, the website team's VMs need to call the payments team's API, and the analytics team needs to read logs from both.

Your first choice is VPC peering. You create a VPC in each team's project and then set up three peering connections: website-to-payments, website-to-analytics, and payments-to-analytics. That works, but it's messy. Every time a new team joins (say, a shipping team), you must create peering connections to every existing team. That's three more connections. The total number of peering connections grows quadratically as teams increase. Also, because peering is non-transitive, if the payments team updates its firewall rules to block all traffic from analytics, the website team might still talk to analytics via a different path (it can't, because there is only one path, but the confusion is real).

The better approach for your company is Shared VPC. You designate a host project owned by the central cloud infrastructure team. In that host project, you create a VPC network with several subnets: one subnet for 'web', one for 'payments', one for 'analytics'. You then attach the website team's project, the payments team's project, and the analytics team's project as service projects. Now, each team can deploy their VMs into the appropriate subnet of the shared VPC. The VMs in the 'web' subnet can directly talk to VMs in the 'payments' subnet using internal IPs, as if they were on the same network — because they are. The central team manages all the firewall rules, VPC routes, and Cloud NAT (Network Address Translation) for internet access. They can, for example, create a firewall rule that allows TCP port 443 (HTTPS) from the web subnet to the payments subnet, and another rule that allows the analytics subnet to read logs from all other subnets.

Now let's say your company merges with another company that uses Google Cloud with its own VPC. To integrate the two networks without moving everything into one host project, you would use VPC peering between your shared VPC (the host project's network) and the acquired company's VPC. This gives you a private link between the two organisations. The acquired company's VMs can talk to your payment services, and your analytics team can ingest their logs — all over internal IPs, without exposing anything to the internet.

From an operational perspective, here is what an IT professional actually does:

- To create a Shared VPC, go to the VPC network page in the Google Cloud Console, select the host project, and enable Shared VPC. Then add service projects via the IAM & Admin section or using the gcloud command: 'gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID --host-project HOST_PROJECT_ID'.
- To set up VPC peering, navigate to the VPC network details, select 'VPC network peering', and create a peering connection. You'll need the second project's network name and the IAM permission 'compute.networks.updatePeering'. The other party must also accept the peering request from their side.
- For both, you must ensure IP ranges do not overlap. Use the 'gcloud compute networks describe' command to check the CIDR ranges.
- Regularly audit the peering connections using Cloud Monitoring and VPC flow logs to verify traffic is flowing as expected and no unauthorised access is happening.

## Exam focus

The PCNE exam tests VPC peering and Shared VPC in several ways. You will see scenario-based questions where you must choose the right connectivity method, configure the correct IAM roles, and identify misconfigurations. Here is exactly what you need to know.

First, understand the concept of transitive peering. The exam loves to present a scenario like: 'Three VPCs: A, B, C. A is peered with B, B is peered with C. Does A have connectivity to C?' The correct answer is no, because VPC peering is not transitive. You must set up a separate peering between A and C. A common trap is a question that implies you can route through B to reach C — Google Cloud does not support that. The only exception is if you use a Network Virtual Appliance (NVA) running in B that forwards traffic, but that is not standard VPC peering.

Second, know the IAM permissions required. For Shared VPC, you need the Shared VPC Admin role (roles/compute.xpnAdmin) at the organisation level. For VPC peering, you need 'compute.networks.updatePeering' on both participating networks. A typical exam question gives you a list of roles and asks which one allows a user to attach a service project. The correct answer is the Shared VPC Admin role.

Third, understand subnets in Shared VPC. The exam will test that service projects cannot create subnets in the host VPC. Only the host project can create or modify subnets. Service projects use existing subnets from the host project. A related trap: a question might say 'A user in a service project wants to add a new subnet for their VMs.' The correct answer is that they cannot — they must request it from the host project administrator.

Fourth, know the difference in firewall rule application. In VPC peering, each VPC's firewalls are independent. A packet crossing a peering connection is subject to both the source VPC's egress rules and the destination VPC's ingress rules. In Shared VPC, the host project's firewall rules apply to all VMs in the service projects, but service projects can create additional rules that only affect their own VMs (provided they don't conflict with host project rules).

Fifth, be aware of DNS resolution. When you set up VPC peering, DNS resolution for private zones is not automatically shared. You must explicitly set up DNS peering if you want VMs in one network to resolve private DNS names from the other network. For Shared VPC, the default DNS resolution works because the service projects use the host project's DNS settings.

Sixth, the exam tests your ability to choose between VPC peering and Shared VPC based on organisational structure. If the question involves multiple organisations or business units that do not trust each other, the answer is almost always VPC peering. If the question is about a single organisation with a central network team and many application teams, the answer is Shared VPC.

Seventh, watch for questions about overlapping IP addresses. VPC peering cannot be established if the two VPCs have overlapping CIDR ranges. You must either re-IP one of the networks, use a non-overlapping range, or redesign the network. Shared VPC avoids this problem entirely because it uses subnets from one VPC.

Eighth, know the limitations: a VPC can have up to 25 peerings by default (you can request a quota increase). A host project for Shared VPC can have up to 1000 associated service projects. These limits may appear in questions about scalability.

Finally, practise interpreting the diagram the exam may show you: a host project with three service projects, each using a different subnet, and a VPC peering connection from the host project to an on-premises network via Cloud VPN or Cloud Interconnect. You'll need to identify which subnets can reach on-premises resources and whether firewall rules permit specific traffic.

## Step by step

1. **Plan your IP address ranges** — Before setting up any connectivity, decide on CIDR blocks for each VPC. For VPC peering, the ranges must be non-overlapping. For Shared VPC, you are using subnets from one range, so overlapping is not an issue. Use RFC 1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). This step matters because accidental overlap leads to failed peering or routing conflicts.
2. **Create or select your VPCs** — In the Google Cloud Console, navigate to VPC networks and create the required VPCs (or use the default VPC). For a Shared VPC, you create one VPC in the host project. For peering, you need at least two separate VPCs, possibly in different projects. Each VPC must have at least one subnet.
3. **Configure IAM permissions** — Ensure the user or service account setting up the connection has the right permissions. For VPC peering, assign the Network Admin role (roles/compute.networkAdmin) or the specific compute.networks.updatePeering permission on both networks. For Shared VPC, assign the Shared VPC Admin role (roles/compute.xpnAdmin) at the organisation level or on the host project. Without correct permissions, the setup will fail.
4. **Establish the connection** — For VPC peering, go to one VPC, click 'Create peering', specify the other VPC's project and network, and then repeat the process from the other side to accept the peering. For Shared VPC, enable the host project for Shared VPC in the VPC network settings, then attach service projects using the 'Associated Projects' tab or gcloud command. Both sides must complete their part before connectivity works.
5. **Verify firewall rules and DNS** — After the connection is active, check that firewall rules allow the intended traffic. For VPC peering, review ingress rules on the destination and egress rules on the source. If you need private DNS resolution across peered VPCs, set up DNS peering. For Shared VPC, verify that service project VMs can reach the host project's DNS and that firewall rules inherited from the host project apply correctly.
6. **Test and monitor** — Use tools like ping, traceroute, or SSH from a VM in one network to a VM in the other network to confirm connectivity. Enable VPC flow logs to capture traffic metadata for debugging and auditing. In the exam, you may be asked to identify why traffic is not flowing — often it is because of missing firewall rules or an incomplete peering acceptance.

## Comparisons

### VPC Peering vs Shared VPC

**VPC Peering:**
- Each project owns its own VPC.
- Peering is a one-to-one connection between two VPCs.
- Non-transitive: traffic cannot route through a third VPC.

**Shared VPC:**
- One host project owns the VPC; service projects use it.
- Many service projects share the same VPC network.
- Transitive within the host VPC: resources in any subnet can communicate directly.

### VPC Peering vs Cloud VPN (IPsec)

**VPC Peering:**
- Connects two VPCs inside Google's network.
- No encryption needed — traffic stays on Google's backbone.
- Simpler setup with fewer configuration steps.

**Cloud VPN (IPsec):**
- Connects an on-premises network to a VPC (or two VPCs).
- Encrypts traffic using IPsec tunnels over the public internet.
- Requires VPN gateway devices and pre-shared keys or certificates.

### Shared VPC (Host Project) vs Service Project (in Shared VPC)

**Shared VPC (Host Project):**
- Owns and manages the VPC, subnets, firewalls, and routes.
- Requires Shared VPC Admin IAM role.
- Can create or update subnets.

**Service Project (in Shared VPC):**
- Uses subnets from the host project's VPC.
- Requires no special Shared VPC permissions (uses project owner/editor).
- Cannot create or delete subnets in the shared VPC.

### VPC Peering (Custom Subnet Sharing) vs VPC Peering (Default Subnet Sharing)

**VPC Peering (Custom Subnet Sharing):**
- You explicitly choose which subnets to export to the peer.
- More granular control over resource visibility.
- Recommended for production networks.

**VPC Peering (Default Subnet Sharing):**
- All subnets in both VPCs are automatically shared.
- Less granular — all resources become visible.
- Can lead to unintended exposure if not carefully designed.

## Diagram

_Top part shows three projects connected via VPC peering (non-transitive); bottom part shows a host project using Shared VPC to serve three service projects, with an additional VPC peering to an external company's VPC._

```mermaid
flowchart TD
    A[Project A: Web Team] -->|Peering| B[Project B: Payments Team]
    B -->|Peering| C[Project C: Analytics Team]
    A -.->|No direct peering| C
    D[Host Project: Central Network] -->|Shared VPC| E[Service Project 1]
    D --> F[Service Project 2]
    D --> G[Service Project 3]
    H[Acquired Company VPC] -->|Peering| D
```

## Common misconceptions

- **Misconception:** VPC peering automatically shares all subnets between the two peered networks. **Reality:** VPC peering only shares the subnets that you explicitly choose to export or import during the peering setup. By default, no subnets are automatically shared — you must configure custom subnet sharing or use auto-mode subnets. (New users assume that just because two networks are peered, all resources are visible. Google Cloud gives you granular control to avoid accidental exposure.)
- **Misconception:** Shared VPC means all projects share the same firewall rules, so you cannot restrict traffic between service projects. **Reality:** Service projects can create their own firewall rules that further restrict traffic to and from their own VMs, as long as those rules don't conflict with the host project's rules. However, they cannot override a host project deny rule. (People confuse 'shared network' with 'no isolation'. In reality, you can layer security on top of the shared infrastructure.)
- **Misconception:** You can set up VPC peering between two VPCs that have overlapping IP ranges as long as you use private Google Access. **Reality:** VPC peering absolutely requires non-overlapping IP ranges. If the ranges overlap, the peering creation will fail. There is no workaround except restructuring one of the networks. (Overlapping ranges break routing because Google Cloud cannot determine which network the traffic should go to. This is a fundamental networking principle that beginners often overlook.)
- **Misconception:** Once you set up Shared VPC, all VMs in service projects automatically have internet access through the host project's Cloud NAT. **Reality:** Shared VPC does not automatically create or attach a Cloud NAT. You must explicitly configure Cloud NAT in the host project and attach it to the relevant subnets for internet access. (People think 'shared' includes internet connectivity, but Shared VPC only shares the internal network configuration. Internet access is a separate service that must be deliberately configured.)
- **Misconception:** VPC peering is transitive if you use a third VPC as a hub that peers with multiple other VPCs. **Reality:** Even with a hub-and-spoke design, VPC peering is non-transitive. The hub VPC is peered to each spoke VPC, but spoke VPCs cannot communicate with each other through the hub. You would need a separate peering between each pair of spokes. (Beginners assume a central hub can route traffic between spokes, similar to a physical router. Google Cloud's VPC peering does not support that — you need an NVA or a different architecture like Shared VPC.)

## Key takeaways

- VPC peering creates a direct private connection between two VPCs but is strictly non-transitive — if A peers with B and B peers with C, A cannot reach C unless A and C are also peered.
- Shared VPC centralises network management in a host project, allowing many service projects to use the same VPC subnets, firewalls, and routes without each project owning its own network.
- VPC peering requires non-overlapping IP ranges between the two VPCs, while Shared VPC avoids this issue entirely because all resources live in subnets of one VPC.
- To set up VPC peering, you need the compute.networks.updatePeering permission on both participating networks; for Shared VPC, you need the Shared VPC Admin role (roles/compute.xpnAdmin).
- Firewall rules in a peered setup are independent per VPC — traffic crossing a peering must satisfy both the source VPC's egress rules and the destination VPC's ingress rules.
- Shared VPC is the right choice when you have many projects in the same organisation that need a common, centrally managed network; VPC peering is better for connecting separate organisations or independent business units.
- VPC peering does not automatically share DNS — you must set up DNS peering separately if you want private DNS resolution across networks.
- A host project in Shared VPC cannot grant service projects permission to create subnets in the shared VPC; only the host project can manage subnets.

## FAQ

**What is the main difference between VPC peering and Shared VPC?**

VPC peering connects two separate VPCs with a direct link, keeping each VPC independent. Shared VPC lets multiple projects use the same VPC network, with centralised management of subnets, firewalls, and routes in a host project.

**Can VPC peering work across different regions?**

Yes, VPC peering works globally across regions. Google's global network allows peered VPCs in different geographical regions to communicate using internal IPs, with no public internet exposure.

**Does VPC peering allow transitive routing?**

No, VPC peering is non-transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot reach VPC C unless they are directly peered. You need separate peering connections for each pair.

**Can I use Shared VPC with projects in different organisations?**

No, Shared VPC only works within the same Google Cloud organisation. All service projects must be members of the same organisation as the host project. For cross-organisation connectivity, use VPC peering or Cloud VPN.

**What happens to existing firewall rules when I attach a service project to a Shared VPC?**

The service project's VMs inherit the host project's firewall rules. The service project can still create its own firewall rules, but they only apply to its own resources and cannot contradict the host project's deny rules.

**Do I need to pay for data transfer between peered VPCs?**

No, data transfer between peered VPCs using internal IPs stays within Google's network and is free of charge. You only pay for the data if it egresses to the internet or crosses a Google Cloud region boundary at certain rates.

## Check your understanding

1. **What happens to network traffic if VPC A is peered with VPC B, and VPC B is peered with VPC C? Can a VM in VPC A directly communicate with a VM in VPC C?**

   Answer: No, because VPC peering is non-transitive. VPC A and VPC C must have their own direct peering connection.

2. **Which IAM role is required to attach a service project to a Shared VPC host project?**

   Answer: The Shared VPC Admin role (roles/compute.xpnAdmin) is required at the organisation level or on the host project.

3. **If two VPCs have overlapping IP ranges, can you set up VPC peering between them?**

   Answer: No, VPC peering requires non-overlapping IP ranges. Overlapping ranges cause routing conflicts and the peering creation will fail.

4. **In a Shared VPC setup, can a user in a service project create a new subnet in the host project's VPC?**

   Answer: No, only the host project's administrators can create or modify subnets. Service projects can only use existing subnets.

5. **Does VPC peering automatically allow DNS resolution of private DNS names across the two networks?**

   Answer: No, you must set up DNS peering separately if you want private DNS resolution to work across peered VPCs.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/google-pcne/vpc-peering-and-shared-vpc