Mastering the GCP Networking Trifecta: Peering, Shared VPC, and Private Access

In the world of Google Cloud, networking isn’t just about connecting Virtual Machines; it’s about defining the boundaries of trust, administrative control, and security. As organizations scale from a single project to hundreds, the “how” of connectivity becomes the most critical architectural decision a Cloud Architect makes.

We often start with a single VPC, but business requirements quickly demand multi-project environments. Do you connect them as equals (VPC Peering)? Do you centralize control (Shared VPC)? Or do you need your private workloads to reach Google’s powerful APIs without ever touching the public internet (Private Google Access)? Understanding these three pillars is essential for building a robust, enterprise-grade cloud foundation.

This guide breaks down these specialized networking components, providing the clarity needed to navigate complex architectural requirements and ace your GCP professional certification or technical interview.

Study Guide: Specialized Networking Deep-Dive

The Relatable Analogy

Imagine a modern corporate campus:

VPC Peering: Like two neighboring companies building a private bridge between their office buildings. They remain separate entities, but employees can walk across the bridge without going out onto the public street.
Shared VPC: Like a large skyscraper (Host Project) where different departments (Service Projects) rent floors. They all use the building’s central plumbing, electricity, and security (the Network), but each department manages its own internal office layout.
Private Google Access: Like having a “VIP Backdoor” in your private office that leads directly into a high-end supply store (Google APIs). You don’t have to step out onto the sidewalk (Internet) to get what you need.

Detailed Explanation

1. VPC Network Peering

VPC Peering allows internal IP address connectivity across two VPC networks, whether they are in the same project, different projects, or even different organizations. It uses Google’s internal backbone, ensuring low latency and high security.

Non-Transitivity: If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot talk to VPC C through B.
No Overlapping IPs: You cannot peer two VPCs if they have overlapping CIDR ranges.
Decentralized: Each VPC maintains its own routing and firewall rules.

2. Shared VPC

Shared VPC allows an organization to connect resources from multiple projects to a common VPC network. It distinguishes between a Host Project (contains the network) and Service Projects (contain the VMs/Resources).

Centralized Control: Network Admins manage the network in the Host project; Developers manage resources in Service projects.
IAM Roles: Uses the compute.networkUser role to grant service projects permission to use subnets.
Efficiency: Simplifies hybrid connectivity (VPN/Interconnect) as it only needs to be set up once in the Host project.

3. Private Google Access (PGA)

PGA allows VM instances that only have internal IP addresses (no public IP) to reach the external IP addresses of Google APIs and services (like Cloud Storage, BigQuery, or Vision API).

Requirement: Must be enabled at the Subnet level.
Routing: Traffic stays within the Google network.
Security: Reduces the attack surface by removing the need for external IPs on sensitive workloads.

Comparison Table: GCP vs AWS

Feature	Google Cloud (GCP)	AWS Equivalent	Key Difference
Peer-to-Peer	VPC Network Peering	VPC Peering	Both are non-transitive by default.
Centralized Networking	Shared VPC	VPC Sharing (via RAM)	GCP Shared VPC is a more rigid Host/Service hierarchy.
Private API Access	Private Google Access	VPC Endpoints (Gateway/Interface)	PGA is a simple subnet toggle; AWS uses specific endpoints.

Real-World Scenarios

Scenario A: A large enterprise wants their Security Team to manage all firewalls and VPNs, while the App Team manages the VMs.
Solution: Shared VPC. The Security Team owns the Host Project, and the App Team owns the Service Project.

Scenario B: Two independent startups merge and need to share a database. They want to keep their GCP projects separate for billing.
Solution: VPC Peering. It connects the two existing networks with minimal architectural change.

Interview Questions & Answers

1. Is VPC Peering transitive? No. If VPC A peers with B and B with C, A and C cannot communicate. You would need a separate peering between A and C or a Hub-and-Spoke model using a Network Virtual Appliance or Cloud Router.

2. What role is required for a user to use a subnet in a Shared VPC? The compute.networkUser role, granted at either the project level or the individual subnet level.

3. Can you peer two VPCs with overlapping IP ranges? No. Peering will fail if there is any overlap in the primary or secondary CIDR ranges.

4. How do you enable Private Google Access? It is enabled on a per-subnet basis via a simple checkbox/toggle in the subnet configuration.

5. What is the limit of Host Projects a Service Project can be attached to? A Service Project can only be attached to one Host Project at a time.

6. Does VPC Peering incur costs? There is no charge for setting up peering, but standard egress data transfer rates apply for traffic moving between zones.

7. Can Shared VPC work across different Organizations? No. Shared VPC is restricted to projects within the same Google Cloud Organization.

8. Can VPC Peering work across different Organizations? Yes, as long as you have the appropriate IAM permissions in both organizations.

9. What happens if a VM has a Public IP and Private Google Access is enabled? The VM will use its Public IP to reach Google APIs by default. PGA is specifically designed for VMs without public IPs.

10. In Shared VPC, who manages the firewall rules? Firewall rules are defined in the Host Project and apply to all resources in the Service Projects using that network.

💡 Golden Nuggets: Interview Tips

Architectural Trade-off: Use Shared VPC for centralized governance (Enterprise). Use VPC Peering for autonomy and decentralized management (SaaS/Mergers).
The “Transitivity” Trap: If an interviewer asks how to connect 50 VPCs, don’t say Peering (it’s a mesh nightmare). Suggest Network Connectivity Center or a Hub-and-Spoke design.
PGA vs PSC: Don’t confuse Private Google Access (accessing Google’s own services) with Private Service Connect (accessing 3rd party services or your own internal services via endpoints).
Quotas: VPC Peering has limits on the number of peering connections per VPC (usually 25). Keep this in mind for massive scale.

Visual Architecture: Specialized Networking

Ecosystem

Connectivity Matrix

Integrates with Cloud Interconnect and Cloud VPN. In a Shared VPC, hybrid links in the Host project are automatically available to Service projects.

Scaling

Network Limits

Peering: Max 25 connections per VPC.
Shared VPC: Up to 100 service projects per host.
Throughput: Full VM egress bandwidth is maintained.

Cost

Traffic Billing

Traffic within the same zone is free. Egress between zones via Peering or Shared VPC follows standard Inter-zone data transfer pricing.

Decision Tree: Which one to use?

Requirement	Recommended Choice
Centralized Network/Security Team	Shared VPC
Connecting two independent Orgs	VPC Peering
Internal VM needs to upload to GCS	Private Google Access
Overlapping IP Ranges	Cloud VPN or Private Service Connect (Peering won’t work)

Production Use Case: A financial services company uses a Shared VPC to host their core banking app in a Service Project, ensuring the Security Team in the Host Project controls all ingress/egress. They use Private Google Access to allow the app to store sensitive audit logs in BigQuery without exposing the app to the internet.