Professional Cloud DevOps Engineer

Design and Configure Shared VPC Architectures

Shared VPC lets multiple projects in an organization use a single VPC network, so resources can talk to each other using internal IP addresses without going over the public internet. One project becomes the host project that owns the shared VPC network, and other projects called service projects attach to it and use the shared subnets. This keeps network control centralized—network admins manage subnets, routes, and firewall rules while app teams deploy their workloads in the subnets they are given access to.

When setting up Shared VPC, organizations assign IAM roles to control who can do what. The Network Admin role manages network resources, the Security Admin handles firewall rules, and the Service Project Admin connects service projects to the host project. You can grant network user permissions at the subnet level, giving each team access only to the subnets they need. This follows the security principle of least privilege—people only get the permissions required for their specific job.

VPC Network Peering and Private Service Connect work alongside Shared VPC for different scenarios. VPC Network Peering connects two VPC networks directly so traffic stays inside Google's network. This works well for hub-and-spoke setups where a central hub provides shared services to multiple spokes. Private Service Connect creates a single endpoint for accessing specific services without exposing the producer's entire network—useful for accessing Google APIs or third-party services privately.

To implement Shared VPC, you create a dedicated project for the host, enable the Compute Engine API, turn on Shared VPC in the host project, and build custom-mode VPC networks with your subnets. You then decide which subnets to share with each service project—either giving each team its own subnets or sharing the same subnets across projects. Each subnet needs Private Google Access enabled so VMs without external IPs can reach Google services, and Cloud NAT handles any outbound internet access those workloads need.

Implement and Manage VPC Network Peering

VPC Network Peering creates a direct connection between two VPC networks using private RFC 1918 IP addresses. Traffic flows entirely within Google's internal network, never touching the public internet, and VMs in peered networks can communicate at full bandwidth without the slowdowns of VPN tunnels.

A critical limitation is that VPC Network Peering does not support transitive routing. If you have a hub-and-spoke setup where Network A peers with Network B, and Network B peers with Network C, traffic cannot flow from A to C through B. Each peering connection only connects the two directly involved networks. To get traffic to flow through a central network, you need network virtual appliances or Cloud VPN.

Overlapping IP address ranges block peering connections from working. If two VPC networks have subnets with the same CIDR blocks, the peering will fail. Before setting up peering, you must plan your IP address space carefully to avoid conflicts. Additionally, you must explicitly configure which routes get imported and exported between the peered networks, and check that firewall rules on both sides allow the traffic you intend to pass.

Deploy and Utilize Private Service Connect

Private Service Connect (PSC) lets a consumer VPC access services published by a producer without exposing the producer's entire network. The producer creates a service attachment linked to a load balancer frontend, and the consumer creates a PSC endpoint in their VPC that receives a private IP address. This endpoint connects to the producer's service attachment, enabling private communication between them.

A major advantage of PSC is that it uses Network Address Translation, so the consumer and producer VPCs do not need matching or non-overlapping IP addresses. This makes deployment simpler than VPC Network Peering, which requires careful IP planning.

PSC works with Cloud DNS and Service Directory for service discovery. When a producer publishes a service with a DNS domain name, PSC can automatically create DNS entries in a private zone in the consumer's VPC. This lets workloads resolve the service by name, which points to the PSC endpoint's private IP.

For more complex setups, PSC supports hub-and-spoke architectures where a central services VPC accesses published services for many application VPCs. PSC endpoints also work across Network Connectivity Center spoke VPCs. When connecting to serverless backends like Cloud Run, you need a Serverless VPC Access connector for the service to call back to the consumer VPC. Firewall rules must allow traffic to the PSC endpoint IPs, and you should check routing configuration if you modify default routes.

PSC keeps traffic on Google's network and lets you enforce service-level authorization. It integrates with VPC Service Controls to prevent data exfiltration. For hybrid environments, on-premises systems can reach PSC endpoints over Cloud Interconnect or Cloud VPN by advertising the endpoint's private IP through Cloud Router and configuring on-premises DNS to resolve service names to those private addresses.