Shared VPC: Service Project

A project that hosts workloads (VMs, GKE clusters) which attach to subnets defined in the host project’s shared VPC.

A managed network address translation service that lets resources without external IP addresses initiate outbound connections to the internet using configured external IP addresses.

A service that provides IPsec VPN tunnels over the public internet between your on-premises network and a Google Cloud VPC.

A Google Cloud feature that lets you share a VPC network from a host project with one or more service projects in the same organization so they can use common subnets and network policies.

Advanced Network Planning: Shared VPC, Load Balancing, and Hybrid Connectivity — Google Cloud Associate Cloud Engineer: Complete Exam-Ready Masterclass

Q: You run a regional internal-only PostgreSQL cluster on Compute Engine. Many app VMs in the same VPC need to connect using a single stable IP and port. Which load balancer is the best fit?

Internal TCP/UDP load balancer. PostgreSQL uses TCP, not HTTP, and traffic is internal to the VPC. An internal TCP/UDP load balancer provides a regional internal IP for non-HTTP protocols. External options would expose it to the internet, which is not required.

Module Overview and Mental Map

What You Will Learn

You will connect basic VPC concepts to advanced designs that span multiple projects and on-premises networks, focusing on Shared VPC, load balancing, Cloud NAT, and hybrid connectivity.

Four Big Ideas

We cover: 1) Shared VPC for multi-project control, 2) Load balancers for HTTP(S), TCP/UDP, and internal traffic, 3) Cloud NAT and private access to Google APIs, 4) VPN vs Interconnect for hybrid links.

Exam Focus

Associate Cloud Engineer scenarios often ask you to choose the right product or pattern from a short description. This module uses up-to-date Google Cloud networking services as of May 2026.

How the Module Flows

Steps 2–4: Shared VPC. Steps 5–7: Load balancing. Steps 8–9: Cloud NAT and private access. Steps 10–11: Hybrid connectivity. Expect diagrams, exercises, quizzes, and flashcards.

Shared VPC: Concepts, Roles, and When to Use It

What is Shared VPC?

Shared VPC lets you share a VPC network from one host project with other service projects in the same organization so they all use the same central network.

Host vs Service Projects

The host project owns the VPC, subnets, routes, and firewalls. Service projects contain workloads that attach their VMs and resources to subnets defined in the host project.

Why Use Shared VPC?

It gives centralized network and security control, consistent policies, and simpler connectivity compared to a mesh of separate VPCs and VPC peering links.

IAM and Shared VPC

IAM roles like Shared VPC Admin, Network Admin, and Compute Network User control who can attach projects, manage networks, or just use shared subnets for their workloads.

Visual Model

Picture one big host VPC rectangle with subnets, surrounded by smaller service project boxes. Each service project’s VMs plug into the shared host subnets.

Designing a Shared VPC Architecture Step-by-Step

Scenario Setup

Three teams (Payments, Analytics, Marketing) need one IP plan, centralized firewalls, separate billing, and private-only communication. This is a classic Shared VPC use case.

Step 1: Projects

Create one host project `net-core-host` and three service projects `svc-payments`, `svc-analytics`, and `svc-marketing` for team isolation and billing separation.

Step 2: Network in Host

In `net-core-host`, create `corp-shared-vpc` with custom subnets per team, and firewall rules for SSH from bastion and controlled inter-subnet traffic.

Step 3–4: Attach and Delegate

Enable Shared VPC on the host, attach service projects, then grant app teams Compute Network User on their subnets so they can attach VMs without editing network config.

Exam Signals

Phrases like "centralized network team" and "multiple projects with separate billing" strongly suggest a Shared VPC host project and Compute Network User roles.

Quick Check: Shared VPC

Test your understanding of Shared VPC basics.

A company has 10 projects owned by different teams. They want one central team to manage subnets, routes, and firewall rules, while app teams only attach their VMs to those subnets. Which combination best fits?

Use VPC peering between 10 separate VPCs and give each team Network Admin on its VPC.
Create a Shared VPC host project with a central VPC, attach the 10 projects as service projects, and grant app teams Compute Network User on shared subnets.
Create one large project for everyone and use folders to separate access.
Use Cloud VPN between projects and manage firewalls independently in each project.

Show Answer

Answer: B) Create a Shared VPC host project with a central VPC, attach the 10 projects as service projects, and grant app teams Compute Network User on shared subnets.

Shared VPC with a host project centralizes network configuration while service projects host workloads. Compute Network User lets app teams attach VMs to shared subnets without changing network settings. The other options either decentralize network control or collapse isolation.

Load Balancing on Google Cloud: The Big Picture

Three Dimensions

Classify load balancers by traffic type (HTTP vs TCP/UDP), scope (global vs regional), and exposure (external vs internal). This is how exam questions are framed.

Global External HTTP(S)

Use the global external HTTP(S) load balancer for worldwide web and API traffic on a single anycast IP, with Layer 7 features like routing and SSL termination.

Regional and Non-HTTP

Regional external HTTP(S) keeps traffic in one region. External TCP/UDP load balancers handle Layer 4 non-HTTP protocols like SMTP or custom TCP services.

Internal Load Balancers

Internal HTTP(S) and internal TCP/UDP load balancers serve internal clients in your VPC or hybrid network, for microservices or databases behind a stable internal IP.

Mental Patterns

Global + HTTP(S) + internet → global HTTP(S) LB. Internal + HTTP(S) → internal HTTP(S). Non-HTTP + internal → internal TCP/UDP. Non-HTTP + external → external TCP/UDP.

Choosing the Right Load Balancer: Three Scenarios

Scenario 1: Global Web

Global HTTPS site with users worldwide, single IP, SSL termination, and URL routing? Choose a global external HTTP(S) load balancer in front of multi-region backends.

Scenario 2: Internal APIs

Internal microservices accessed only from VPC and on-prem via VPN over HTTP? Use an internal HTTP(S) load balancer with a private IP.

Scenario 3: Legacy TCP

Custom TCP protocol on port 9000 for internet clients, no Layer 7 logic? Pick an external TCP/UDP load balancer to distribute TCP connections.

Reading Exam Clues

Look for phrases like "internal only", "global users", "non-HTTP", or "content-based routing" to map quickly to the correct load balancer type.

Quick Check: Load Balancing

Pick the best load balancer for the scenario.

You run a regional internal-only PostgreSQL cluster on Compute Engine. Many app VMs in the same VPC need to connect using a single stable IP and port. Which load balancer is the best fit?

Global external HTTP(S) load balancer
Internal HTTP(S) load balancer
Internal TCP/UDP load balancer
External TCP/UDP load balancer

Show Answer

Answer: C) Internal TCP/UDP load balancer

PostgreSQL uses TCP, not HTTP, and traffic is internal to the VPC. An internal TCP/UDP load balancer provides a regional internal IP for non-HTTP protocols. External options would expose it to the internet, which is not required.

Cloud NAT and Private Access to Google APIs

Why Cloud NAT?

Cloud NAT lets VMs and resources without external IPs make outbound connections to the internet, such as pulling images or patches, without exposing them directly.

Cloud NAT Basics

Configured per region, Cloud NAT translates private source IPs to shared external IPs for egress only. It is managed by Google; you do not run NAT VMs.

Private Google Access

Private Google Access is a subnet setting that lets VMs without external IPs reach Google APIs using their private IP, even though the API endpoints are public.

Private Service Connect for APIs

Private Service Connect creates private IP endpoints in your VPC for specific Google APIs, keeping traffic on Google’s internal network and simplifying firewall rules.

Exam Triggers

No public IPs but need internet → Cloud NAT. No public IPs but need Google APIs → PGA or PSC. Emphasis on private IP endpoints for APIs → PSC.

Designing Private Workloads with Cloud NAT and Google APIs

Scenario Requirements

No public IPs; app VMs must reach external payment gateways and Google APIs, with traffic controlled by firewall rules. This combines Cloud NAT and private API access.

Private Subnet + PGA

Create a private-only subnet and enable Private Google Access so VMs without external IPs can still reach Google APIs from their private addresses.

Add Cloud NAT

Configure Cloud NAT in the region for that subnet. VMs now initiate outbound internet connections via NAT external IPs, staying private inside the VPC.

Optional: PSC Endpoints

For stricter control, create Private Service Connect endpoints for Google APIs and point DNS to them, keeping API traffic on Google’s internal network.

Exam Distractors

If you see "no public IPs but need internet", pick Cloud NAT, not a bastion. For Google APIs, think Private Google Access or PSC, not adding external IPs to VMs.

Hybrid Connectivity: VPN vs Dedicated and Partner Interconnect

Why Hybrid Connectivity?

Hybrid connectivity links your on-prem or other clouds to your Google Cloud VPC so resources can talk privately as if on one extended network.

Cloud VPN

Cloud VPN uses IPsec tunnels over the internet. It is quick to set up, encrypted, and good for moderate bandwidth or dev/test environments.

Dedicated Interconnect

Dedicated Interconnect is a private, physical connection to Google with high bandwidth and low, consistent latency, ideal for heavy or latency-sensitive workloads.

Partner Interconnect

Partner Interconnect uses a service provider that already connects to Google, useful when you cannot colocate or want a managed private connectivity solution.

Exam Choice Patterns

Quick and encrypted over internet → VPN. High bandwidth, direct physical link → Dedicated Interconnect. Need private link via provider → Partner Interconnect.

Design Exercise: Put It All Together

Scenario Summary

Retail company with on-prem Oracle, multiple app projects, no public IPs on VMs, global HTTPS users, and a need for private access to on-prem and Google APIs.

Task: Sketch the Design

On paper, draw host and service projects for Shared VPC, pick a load balancer for global HTTPS, choose VPN or Interconnect, and place Cloud NAT and private API access.

Reference Architecture

Aim for: Shared VPC host with central VPC, global external HTTP(S) LB, Dedicated or Partner Interconnect to on-prem, and Cloud NAT plus PGA or PSC for API access.

Key Term Review

Flip these cards (mentally or by covering answers) to reinforce terminology.

Shared VPC: Host Project: The project that owns the shared VPC network, subnets, routes, and firewall rules, and shares them with service projects in the same organization.
Shared VPC: Service Project: A project that hosts workloads (VMs, GKE clusters) which attach to subnets defined in the host project’s shared VPC.
Compute Network User role: An IAM role that lets principals create resources (like VMs) that use shared VPC networks and subnets, without granting permission to modify the network itself.
Global external HTTP(S) load balancer: A Layer 7 load balancer with a global anycast IP for internet-facing HTTP(S) traffic, ideal for web apps and APIs serving users worldwide.
Internal TCP/UDP load balancer: A regional, internal Layer 4 load balancer that distributes non-HTTP traffic (like database connections) among backends within a VPC or hybrid network.
Cloud NAT: A managed network address translation service that lets resources without external IPs initiate outbound connections to the internet using shared external IP addresses.
Private Google Access: A subnet-level setting that allows VMs without external IPs to reach Google APIs and services using their private IP addresses.
Private Service Connect for Google APIs: A feature that creates private IP endpoints in your VPC for specific Google APIs, keeping traffic on Google’s internal network and simplifying firewall control.
Cloud VPN: An IPsec VPN connection over the public internet between your on-premises network and a Google Cloud VPC, suitable for secure but moderate-bandwidth connectivity.
Dedicated Interconnect: A private, physical connection from your data center to Google’s network, offering high bandwidth and low, consistent latency for production hybrid workloads.
Partner Interconnect: A connectivity option where a service provider connects your network to Google’s, giving you private connectivity without needing to colocate with Google.

Key Terms

Cloud NAT: A managed network address translation service that lets resources without external IP addresses initiate outbound connections to the internet using configured external IP addresses.
Cloud VPN: A service that provides IPsec VPN tunnels over the public internet between your on-premises network and a Google Cloud VPC.
Shared VPC: A Google Cloud feature that lets you share a VPC network from a host project with one or more service projects in the same organization so they can use common subnets and network policies.
Host project: In a Shared VPC setup, the project that owns the shared VPC network and related resources that are made available to service projects.
Service project: In a Shared VPC setup, a project that contains workloads that use subnets and networking resources from a host project’s shared VPC.
Partner Interconnect: A Google Cloud service where a supported connectivity provider delivers private connectivity between your network and Google’s network.
Private Google Access: A subnet-level configuration that enables VMs without external IP addresses to access Google APIs and services from their private IP addresses.
Dedicated Interconnect: A Google Cloud service that provides a private physical connection between your on-premises network and Google’s network with high bandwidth and low latency.
Private Service Connect: A Google Cloud feature that lets you create private endpoints in your VPC to access Google APIs or third-party services using internal IP addresses.
Internal HTTP(S) load balancer: A regional, internal Layer 7 load balancer that exposes an HTTP(S) service on a private IP address to clients within a VPC or connected networks.
Internal TCP/UDP load balancer: A regional, internal Layer 4 load balancer that provides a private IP address for distributing non-HTTP traffic among backends in a VPC.
Global external HTTP(S) load balancer: A Google Cloud Layer 7 load balancer with a global anycast IP address, used for internet-facing HTTP(S) traffic with features like SSL termination and URL-based routing.