6.1 VPC Design, Subnets, Shared VPC & VPC Peering

VPC Design, Subnets, Shared VPC & VPC Peering

Core Principle: In Google Cloud, the Virtual Private Cloud (VPC) is not a physical router or regional container—it is a global, software-defined network (SDN) built on Google's Andromeda network virtualization stack. A single VPC network spans every Google Cloud region worldwide without requiring inter-region VPN tunnels or complex routing gateways. Architecting an enterprise Google Cloud network requires mastering global VPC primitives, multi-project connectivity models, and secure private access mechanisms.

---

Virtual Private Cloud (VPC) Fundamentals & Global Scope

Unlike traditional on-premises networks and other major cloud providers where virtual networks are bound to a single geographic datacenter or region, a Google Cloud VPC is inherently global.

+-----------------------------------------------------------------------------------------+
|                                 GLOBAL VPC NETWORK                                      |
|                                                                                         |
|  +-----------------------------+                           +-------------------------+  |
|  | Region: us-central1         |    Google Andromeda SDN   | Region: europe-west1    |  |
|  | Subnet: 10.10.0.0/20        | <=======================> | Subnet: 10.20.0.0/20    |  |
|  | VM: 10.10.0.4 (Zone a)      |   Encrypted Global Fiber  | VM: 10.20.0.8 (Zone b)  |  |
|  +-----------------------------+                           +-------------------------+  |
+-----------------------------------------------------------------------------------------+

Key Characteristics of Global VPCs

1. Global Control Plane & Routing: The VPC routing table is global. A virtual machine in us-central1 can communicate directly with a virtual machine in europe-west1 or asia-east1 using internal RFC 1918 IP addresses. Packets traverse Google's private global fiber backbone with high throughput and low latency, never touching the public internet.
2. Regional Subnets: While the VPC itself is global, subnets are regional resources. Each subnet defines a contiguous IP address range (CIDR block) within a specific Google Cloud region.
3. Zonal Compute Placement: Compute resources (Compute Engine virtual machines, Google Kubernetes Engine nodes) are zonal resources instantiated within a specific zone (e.g., us-central1-a) and allocated an IP address from that region's subnet CIDR range.

---

Auto Mode vs. Custom Mode VPC Networks

Google Cloud provides two creation modes for VPC networks: Auto Mode and Custom Mode.

+-----------------------------------------------------------------------------------------+
|                              VPC SUBNET CONVERSION PATH                                 |
|                                                                                         |
|   [ Auto Mode VPC ]  ======( gcloud compute networks switch-mode )=====>  [ Custom Mode ]|
|   * Note: Conversion is ONE-WAY. A Custom Mode VPC can NEVER be reverted to Auto Mode.  |
+-----------------------------------------------------------------------------------------+

[!CAUTION] Auto Mode Overlap Hazard: Auto Mode VPCs allocate subnets from the contiguous 10.128.0.0/9 address space. If two different projects use Auto Mode VPCs, their subnets will share identical CIDR blocks (e.g., 10.128.0.0/20 for us-central1), making VPC Network Peering and Cloud VPN connections impossible due to routing collisions. Always build enterprise networks in Custom Mode.

---

Primary and Secondary IP Ranges (Alias IPs)

In standard compute deployments, each virtual machine interface (vNIC) is allocated a single primary private IP address from the subnet's primary CIDR range. However, modern containerized platforms such as Google Kubernetes Engine (GKE) require multiple distinct IP addresses per node to assign directly to container Pods and Services.

+-----------------------------------------------------------------------------------------+
|                         SUBNET IP RANGE ARCHITECTURE (GKE)                              |
|                                                                                         |
|  Subnet CIDR Range:                                                                     |
|  - Primary Range:   10.100.0.0/20  (Allocated to GKE Node VM vNICs)                     |
|  - Secondary Range 1: 10.101.0.0/16  (Allocated to GKE Pods via Alias IPs)               |
|  - Secondary Range 2: 10.102.0.0/20  (Allocated to GKE ClusterIP Services)              |
+-----------------------------------------------------------------------------------------+

Alias IP Ranges & Container-Native Routing

• Primary Subnet Range: Sized to accommodate node instances, internal load balancers, and managed infrastructure VMs.
• Secondary Subnet Ranges: Designated address pools attached to the subnet. In VPC-native GKE clusters, Kubernetes assigns Pod IP addresses directly from secondary IP ranges using Alias IP functionality.
• Benefits of VPC-Native Alias IPs:
  1. Direct Routing: Pod IPs are first-class citizens in the Google Cloud SDN routing table; traffic between Pods on different nodes does not require packet overlay encapsulation (e.g., VXLAN/Flannel) or node-level iptables NAT.
  2. Security & Observability: VPC Flow Logs and Cloud Armor can inspect and filter traffic down to individual Pod IP endpoints.
  3. IP Expansion: Subnet primary and secondary ranges can be expanded non-disruptively to accommodate cluster growth without recreating the subnet (provided contiguous address space is available).

---

Shared VPC Architecture (Centralized Network Administration)

In multi-project enterprise organizations, managing independent VPCs in every project leads to security fragmentation, administrative sprawl, and massive routing complexity. Shared VPC is the primary Google Cloud pattern for enterprise network centralization.

+-----------------------------------------------------------------------------------------+
|                               SHARED VPC HOST PROJECT                                   |
|                                                                                         |
|  VPC Network: production-vpc (Global)                                                   |
|  +-------------------------------------+   +-----------------------------------------+  |
|  | Subnet A: 10.10.0.0/20 (us-central1)|   | Subnet B: 10.20.0.0/20 (europe-west1)   |  |
|  +-------------------------------------+   +-----------------------------------------+  |
|  | Centralized Cloud NAT, Cloud Interconnect, HA VPN, Cloud DNS, Firewall Rules       |  |
+------------------------------------+----------------------------------------------------+
                                     | Shared Subnet Access (IAM Delegation)
                 +-------------------+-------------------+
                 |                                       |
                 v                                       v
+---------------------------------+     +---------------------------------+
|        SERVICE PROJECT 1        |     |        SERVICE PROJECT 2        |
|        (Payments Team)          |     |        (Analytics Team)         |
|                                 |     |                                 |
|  - GKE Clusters in Subnet A     |     |  - Compute Engine in Subnet B   |
|  - Cloud SQL Private Instances  |     |  - Dataproc Clusters in Subnet B|
|  - Billed to Payments Project   |     |  - Billed to Analytics Project  |
+---------------------------------+     +---------------------------------+

Structural Components & Roles

1. Host Project: A centralized Google Cloud project designated as the owner of the Shared VPC network, subnets, firewall rules, Cloud NAT gateways, and hybrid connectivity attachments (Cloud Interconnect / Cloud VPN).
2. Service Projects: Application-specific projects attached to the Host Project. Workloads in service projects (Compute Engine VMs, GKE clusters, Cloud Run via serverless VPC access) attach their virtual interfaces directly to the shared subnets in the Host Project.
3. Administrative Separation of Duties (IAM):
   • Shared VPC Admin (roles/compute.xpnAdmin): Granted only at the Organization or Folder level. Authorizes network security engineers to designate host projects and attach service projects.
   • Service Project Admin (roles/compute.networkUser): Granted at the Host Project level or on specific subnets. Allows developers in service projects to instantiate compute resources attached to authorized subnets without granting them permission to modify firewall rules, routes, or network topology.

Subnet-Level IAM Principle of Least Privilege

An architect can restrict Service Project 1 (e.g., Payment Processing) to use only Subnet A in us-central1, while Service Project 2 (e.g., Marketing Analytics) is restricted to Subnet B in europe-west1. This prevents application teams from provisioning workloads into unauthorized regions or overlapping network segments.

---

VPC Network Peering (Decentralized Multi-VPC Connectivity)

When independent business units, autonomous subsidiaries, or third-party SaaS partners require private network interconnectivity without sharing administrative control, VPC Network Peering provides high-speed, decentralized connectivity.

+---------------------------+                         +---------------------------+
|       ORGANIZATION A      |                         |       ORGANIZATION B      |
|   Project: corp-fintech   |                         |   Project: partner-saas   |
|   VPC: internal-vpc       |   VPC Network Peering   |   VPC: saas-prod-vpc      |
|   CIDR: 10.100.0.0/16     | <=====================> |   CIDR: 10.200.0.0/16     |
|   (VM: 10.100.1.5)        |   (0 ms Gateway Latency)|   (VM: 10.200.50.2)       |
+---------------------------+                         +---------------------------+

Peering Rules, Constraints & The Non-Transitive Law

• Bidirectional Agreement: Peering is not established until both network administrators create a peering connection pointing to the other VPC. If VPC-A initiates peering to VPC-B, no traffic flows until VPC-B explicitly creates a reciprocal peering connection to VPC-A.
• Non-Overlapping CIDRs: Peering will fail immediately if any subnet CIDR block in VPC-A overlaps with any subnet CIDR block in VPC-B (including primary and secondary ranges).
• Zero Gateway Latency: Peering introduces zero packet latency and zero throughput bottlenecks because routing is executed directly within the Andromeda SDN kernel—no intermediary proxy or VPN gateway VM is traversed.

+-----------------------------------------------------------------------------------------+
|                            THE NON-TRANSITIVE PEERING RULE                              |
|                                                                                         |
|   [ VPC-A: 10.1.0.0/16 ] <====== Peered ======> [ VPC-B: 10.2.0.0/16 ]                  |
|                                                        ^                                |
|                                                        | Peered                         |
|                                                        v                                |
|                                                 [ VPC-C: 10.3.0.0/16 ]                  |
|                                                                                         |
|   * Result: VPC-A can talk to VPC-B. VPC-B can talk to VPC-C.                           |
|   * TRANSIT IS BLOCKED: VPC-A CANNOT communicate with VPC-C through VPC-B!             |
+-----------------------------------------------------------------------------------------+

Custom Route Exchange Over Peering

By default, VPC Peering exchanges only subnet routes (RFC 1918 internal subnets). To share on-premises routes (learned via Cloud Interconnect/HA VPN) or custom static routes across a peering connection, both sides must explicitly configure:

• --import-custom-routes: Instructs the local VPC to accept custom routes advertised by the peer.
• --export-custom-routes: Instructs the local VPC to send its custom static and dynamic routes to the peer.

---

Private Service Consumption: PGA vs. PSC

Securing access to managed Google APIs and internal SaaS services without exposing workloads to the public internet is a cornerstone of enterprise security architecture.

+-----------------------------------------------------------------------------------------+
|                    PRIVATE GOOGLE ACCESS vs. PRIVATE SERVICE CONNECT                    |
+-----------------------------------------------------------------------------------------+
|  1. PRIVATE GOOGLE ACCESS (PGA)                                                         |
|     - Subnet-level flag (enablePrivateGoogleAccess: true).                              |
|     - Allows VMs without external public IPs to access *.googleapis.com.               |
|     - Routes to Google VIPs (199.36.153.8/30 restricted or 199.36.153.4/30 private).    |
|     - Enforces VPC Service Controls (VPC-SC) perimeters.                                |
+-----------------------------------------------------------------------------------------+
|  2. PRIVATE SERVICE CONNECT (PSC)                                                       |
|     - Consumer-Producer architectural pattern using internal IP Endpoints.              |
|     - Consumer provisions an internal Forwarding Rule (e.g., 10.10.5.50).                |
|     - Producer publishes a Service Attachment behind an Internal Load Balancer.        |
|     - Supports overlapping IP spaces between organizations via automatic NAT.          |
|     - Eliminates VPC Peering route limits and non-transitive routing constraints.       |
+-----------------------------------------------------------------------------------------+

Architectural Comparison Matrix

---

Concrete Architectural Scenario: Multi-Tier Financial Banking Platform

Scenario Profile

• Organization: Global Financial Institution migrating core retail banking and wealth management systems.
• Requirements:
  1. Centralized network security and egress inspection managed strictly by the Cloud Network Operations team.
  2. Isolation between Retail Banking (Team A) and Wealth Management (Team B) workloads.
  3. Workloads must access Google Cloud Storage and BigQuery without traversing the public internet, satisfying PCI-DSS and VPC Service Controls.
  4. An external payment fraud analytics SaaS hosted in a separate GCP organization must be accessed privately, but the SaaS provider uses the same 10.10.0.0/16 IP range.

Solution Architecture Blueprint

1. Shared VPC Deployment: Create a dedicated net-host-prod project. Establish a custom mode VPC with subnet-retail-us (10.50.0.0/20) and subnet-wealth-us (10.60.0.0/20).
2. Granular IAM Binding: Assign roles/compute.networkUser on subnet-retail-us exclusively to the Retail Banking Service Project, and on subnet-wealth-us exclusively to the Wealth Management Service Project.
3. Private Google Access: Enable Private Google Access on all subnets. Configure internal DNS zones mapping *.googleapis.com to restricted.googleapis.com (199.36.153.8/30) to enforce VPC Service Controls data exfiltration perimeters.
4. Private Service Connect for SaaS: Deploy a PSC Endpoint in subnet-retail-us allocated with IP 10.50.0.99 mapped to the SaaS provider's Service Attachment. This completely bypasses the 10.10.0.0/16 CIDR collision and provides private, encrypted Layer 4 connectivity.

---

[!IMPORTANT] Exam Watch: On the Google Cloud Architect exam, whenever two VPC networks have overlapping CIDR ranges and must exchange service traffic, VPC Network Peering is impossible. The correct architectural solution is Private Service Connect (PSC). If a question asks how to allow developers in a service project to create VMs while preventing them from modifying network topology or seeing other teams' subnets, grant roles/compute.networkUser scoped to individual subnets in the Host Project.