Shared VPC (Virtual Private Cloud)
Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network. This enables resources to communicate with each other securely and efficiently using internal IP addresses from that network.
The Apartment Building Analogy
Think of a Shared VPC as a large Apartment Building:
- The Host Project: This is the building owner who manages the core infrastructure like plumbing (subnets), electricity (firewall rules), and the main lobby (VPN/Interconnect).
- The Service Projects: These are the individual tenants. They rent an apartment (a subnet) to live in. They bring their own furniture (VMs/GKE clusters), but they use the building’s shared plumbing and wiring.
- Isolation: Tenants can’t see into each other’s apartments, but they all benefit from the central management of the building’s utilities.
Detail Elaboration: Architecture & Governance
In Google Cloud, Shared VPC distinguishes between two types of projects:
- Host Project: Contains one or more Shared VPC networks. A project must be designated as a host project by a Shared VPC Admin.
- Service Project: Any project attached to a Host Project. Resources in these projects (like Compute Engine instances) use the subnets defined in the Host Project.
Practical Example: A central “Networking Team” manages the Host Project. They create subnets for “Production” and “Development.” The “App Team A” has a Service Project and is granted permission to deploy VMs only into the “Development” subnet.
Core Concepts & Best Practices
- Reliability: Centralized management of NAT gateways and Interconnects ensures consistent uptime across all business units.
- Scalability: Avoids the complexity of managing dozens of separate VPCs and peering connections as an organization grows.
- Security: Implements Least Privilege. Network admins control the network, while developers control only their applications.
- Cost Optimization: Centralizing Cloud NAT and Cloud Interconnect reduces the overhead of redundant gateway costs.
Comparison: Shared VPC vs. VPC Peering
| Feature | Shared VPC | VPC Peering |
|---|---|---|
| Administration | Centralized (One network admin team) | Decentralized (Each VPC has its own admin) |
| Hierarchy | Strict Host/Service relationship | Peer-to-peer relationship |
| Quotas | Uses Host Project network quotas | Each VPC has its own quotas |
| Use Case | Large organizations with central IT | Connecting separate orgs or independent teams |
Decision Matrix
If the requirement is…
- …to centralize security policy and network management: Use Shared VPC.
- …to connect two VPCs in different organizations: Use VPC Peering.
- …to allow Service Projects to use internal IPs from a central pool: Use Shared VPC.
- …to keep administrative boundaries completely separate: Use VPC Peering.
Exam Tips: ACE Golden Nuggets
- IAM Role: To let a user in a Service Project use a subnet, they need the
compute.networkUserrole at the subnet level or project level in the Host Project. - The Limit: A project can be a Host Project OR a Service Project, but it cannot be a Service Project to multiple Host Projects.
- Organization Requirement: Shared VPC requires that your projects belong to a Google Cloud Organization.
- Distractor: VPC Peering is transitive (A peers with B, B peers with C, but A cannot talk to C). Shared VPC avoids this because everyone is on the same network.
Primarily used by Compute Engine, GKE (Standard & Autopilot), and Cloud Run (via VPC Access Connector).
Forgetting to enable the Compute Engine API in both Host and Service projects before linking them.
Centralize your Cloud NAT in the Host Project to provide internet access to all Service Projects.