Shared VPC concept in GCP - Deep Dive

Overview - Shared VPC concept

What is it?

A Shared VPC lets multiple projects in Google Cloud use the same virtual network. This means resources like virtual machines can communicate securely across projects without extra setup. It separates network management from project ownership, so one team controls the network while others use it. This helps organize and secure cloud resources better.

Why it matters

Without Shared VPC, each project has its own network, making it hard to connect resources safely across projects. Teams might duplicate networks or open risky connections. Shared VPC solves this by centralizing network control, reducing mistakes, saving time, and improving security. It makes cloud setups cleaner and easier to manage at scale.

Where it fits

Before learning Shared VPC, you should understand basic cloud networking concepts like virtual networks and projects. After this, you can explore advanced network security, firewall rules, and multi-project cloud architectures. Shared VPC is a key step toward managing large cloud environments efficiently.

Mental Model

Core Idea

Shared VPC is like a shared office building where different teams have their own rooms but share the same hallways and utilities managed by a central team.

Think of it like...

Imagine a big office building where the network is the building's hallways and utilities. Different teams have their own offices (projects), but they all use the same hallways to move around and share resources like electricity and internet. The building manager (network admin) controls the hallways and utilities, while teams focus on their own workspaces.

┌───────────────────────────────┐
│          Shared VPC            │
│  ┌───────────────┐            │
│  │ Host Project  │            │
│  │ (Network Owner)│           │
│  └──────┬────────┘            │
│         │                    │
│  ┌──────▼───────┐  ┌─────────▼────────┐
│  │ Service Proj │  │ Service Project  │
│  │ (Uses Shared │  │ (Uses Shared     │
│  │  Network)    │  │  Network)        │
│  └──────────────┘  └──────────────────┘
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Google Cloud Projects

Concept: Google Cloud organizes resources into projects, which are like separate containers for your cloud resources.

Each project has its own settings, permissions, and resources like virtual machines and storage. Projects help teams separate work and control access. However, by default, each project has its own network, isolated from others.

Result

You know that projects are the basic units in Google Cloud and that resources inside one project cannot talk to another project’s resources without special setup.

Understanding projects is key because Shared VPC connects multiple projects, so you must know what projects are first.

2

Foundation

Basics of Virtual Private Cloud (VPC)

Concept: A VPC is a private network in the cloud where your resources communicate securely.

VPCs let you create subnets, assign IP addresses, and set firewall rules. Normally, each project has its own VPC, which isolates its resources from others. This isolation is good for security but can make cross-project communication complex.

Result

You understand that VPCs are private networks that keep cloud resources connected and secure within a project.

Knowing how VPCs work helps you see why sharing a VPC across projects can simplify network management.

3

Intermediate

What is Shared VPC and How It Works

Concept: Shared VPC allows one project to own a VPC network and other projects to use it for their resources.

In Shared VPC, a host project owns the network. Service projects attach their resources to this network. This setup lets resources in different projects communicate as if they were in the same network, without duplicating networks or opening insecure connections.

Result

You can connect resources across projects securely and manage the network centrally.

Understanding Shared VPC shows how centralizing network control reduces complexity and security risks in multi-project environments.

4

Intermediate

Roles and Permissions in Shared VPC

🤔Before reading on: Do you think any user can create Shared VPCs or attach projects freely? Commit to your answer.

Concept: Shared VPC requires specific roles to control who manages the network and who uses it.

The host project admin manages the network and assigns 'Shared VPC Admin' role. Service project admins get 'Shared VPC User' role to attach their resources. This separation ensures only authorized people can change network settings or use the network.

Result

You understand how permissions protect the network and control access in Shared VPC setups.

Knowing roles prevents accidental network changes and enforces security boundaries between teams.

5

Intermediate

Configuring Service Projects to Use Shared VPC

🤔Before reading on: Do you think service projects automatically use the host project's network once Shared VPC is enabled? Commit to your answer.

Concept: Service projects must be explicitly attached to the host project's Shared VPC network.

After enabling Shared VPC, the host project admin attaches service projects. Then, service projects can create resources using the shared network. This step is manual to maintain control and avoid accidental network sharing.

Result

You can set up multi-project environments where resources share a network securely.

Understanding this manual attachment step helps avoid confusion about why resources can’t see each other initially.

6

Advanced

Network Security and Firewall Rules in Shared VPC

🤔Before reading on: Do you think firewall rules in the host project automatically apply to service project resources? Commit to your answer.

Concept: Firewall rules are defined in the host project and apply to all resources using the Shared VPC network.

Since the network is shared, firewall rules control traffic for all attached projects. Service projects cannot create their own firewall rules on the shared network, so the host project admin must plan rules carefully to balance security and access.

Result

You understand how to secure multi-project resources with centralized firewall management.

Knowing firewall rule scope prevents security gaps and helps coordinate network policies across teams.

7

Expert

Advanced Shared VPC: Quotas, Limits, and Best Practices

🤔Before reading on: Do you think Shared VPC has no limits on the number of service projects or resources? Commit to your answer.

Concept: Shared VPC has quotas and limits on projects, subnets, and resources to ensure performance and manageability.

Google Cloud limits the number of service projects per host project and the number of subnets per VPC. Best practices include grouping related projects, monitoring quotas, and using IAM roles carefully. Also, Shared VPC supports hierarchical firewall policies and private services access for advanced setups.

Result

You can design scalable, secure Shared VPC architectures that avoid hitting limits and maintain performance.

Understanding limits and best practices helps prevent costly mistakes and downtime in large cloud environments.

Under the Hood

Shared VPC works by letting one project (host) own the network resources like subnets and firewall rules. Other projects (service) link their resources to this network through special permissions. The Google Cloud control plane enforces network isolation and routing so that resources in service projects appear inside the host project's network. This avoids duplicating networks and allows centralized control.

Why designed this way?

Google Cloud designed Shared VPC to solve the problem of managing many projects with isolated networks. Before, teams had to create complex VPNs or open firewall holes to connect projects. Shared VPC centralizes network management for security and simplicity, while still allowing project-level ownership of resources. Alternatives like VPC peering exist but lack centralized control and scale.

┌───────────────┐          ┌───────────────┐
│ Host Project  │          │ Service Project│
│  (Network     │          │  (Resources)  │
│   Owner)      │          │               │
│  ┌─────────┐  │          │  ┌─────────┐  │
│  │ VPC     │◄────────────┤  │ VM      │  │
│  │ Network │  │          │  │ Instance│  │
│  └─────────┘  │          │  └─────────┘  │
└───────────────┘          └───────────────┘
       ▲                          ▲
       │                          │
  Firewall Rules             IAM Roles
       │                          │
       └──────────────┬───────────┘
                      │
               Google Cloud Control Plane

Myth Busters - 4 Common Misconceptions

Quick: Do you think service projects can create their own firewall rules on a Shared VPC network? Commit to yes or no.

Common Belief: Service projects can manage their own firewall rules independently on the shared network.

Reality: Only the host project controls firewall rules; service projects cannot create or modify firewall rules on the Shared VPC network.

Why it matters: If service projects assume they control firewall rules, they might leave resources exposed or block needed traffic, causing security risks or outages.

Quick: Do you think enabling Shared VPC automatically connects all projects in your organization? Commit to yes or no.

Common Belief: Once Shared VPC is enabled, all projects in the organization share the network automatically.

Reality: Projects must be explicitly attached to the Shared VPC host project; enabling alone does not connect all projects.

Why it matters: Assuming automatic connection leads to confusion when resources cannot communicate, delaying troubleshooting.

Quick: Do you think Shared VPC removes the need for IAM permissions? Commit to yes or no.

Common Belief: Shared VPC means anyone in the organization can use the shared network without extra permissions.

Reality: IAM roles are required to control who can attach projects and use the Shared VPC network.

Why it matters: Ignoring IAM leads to unauthorized access or inability to use the network, breaking security or workflows.

Quick: Do you think Shared VPC is the same as VPC peering? Commit to yes or no.

Common Belief: Shared VPC and VPC peering are the same way to connect networks across projects.

Reality: Shared VPC centralizes network ownership and control, while VPC peering connects separate networks without shared control.

Why it matters: Confusing these can cause wrong architecture choices, leading to harder management or security gaps.

Expert Zone

1

Shared VPC allows hierarchical firewall policies that apply organization-wide, enabling consistent security enforcement beyond project boundaries.

2

Service projects can use private services access with Shared VPC to connect to Google-managed services privately, improving security and performance.

3

Shared VPC supports custom routes and subnetworks that require careful planning to avoid IP conflicts and routing issues across projects.

When NOT to use

Avoid Shared VPC when projects require full network independence or when teams need to manage their own network policies fully. Alternatives include VPC peering for loosely connected networks or separate VPCs with VPNs for isolated environments.

Production Patterns

In production, Shared VPC is used to centralize network management in large organizations with multiple teams. Network admins control firewall rules and routing, while developers deploy resources in service projects. This pattern improves security, reduces duplication, and simplifies auditing.

Connections

VPC Peering

Alternative network connection method

Understanding Shared VPC helps clarify when to use centralized network control versus peer-to-peer network connections.

Role-Based Access Control (RBAC)

Builds-on IAM permissions concept

Knowing how Shared VPC uses IAM roles deepens understanding of RBAC principles in cloud security.

Office Building Management

Similar to managing shared physical infrastructure

Recognizing how Shared VPC centralizes network control like a building manager helps grasp complex cloud resource sharing.

Common Pitfalls

#1 Assuming service projects can create their own firewall rules on the Shared VPC network.

Wrong approach:

In service project:
gcloud compute firewall-rules create allow-ssh --allow tcp:22
# This command fails or has no effect on Shared VPC network

Correct approach:

In host project:
gcloud compute firewall-rules create allow-ssh --allow tcp:22
# Firewall rules must be created in the host project

Root cause:

Misunderstanding that firewall rules are managed only in the host project for Shared VPC.

#2 Not attaching service projects to the Shared VPC host project after enabling Shared VPC.

Wrong approach:

Enable Shared VPC but do not run:
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID --host-project=HOST_PROJECT_ID

Correct approach:

Run:
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID --host-project=HOST_PROJECT_ID
# This attaches the service project to the Shared VPC network

Root cause:

Assuming enabling Shared VPC automatically connects all projects.

#3 Granting overly broad IAM permissions, allowing unauthorized users to modify the Shared VPC network.

Wrong approach:

Assign 'roles/owner' to many users on the host project without restrictions.

Correct approach:

Assign 'roles/compute.xpnAdmin' only to trusted network admins and 'roles/compute.xpnUser' to service project admins.

Root cause:

Lack of understanding of least privilege principle and specific Shared VPC roles.

Key Takeaways

Shared VPC lets multiple projects share one network, centralizing network control while keeping project ownership separate.

Only the host project manages the network and firewall rules; service projects use the shared network but cannot change its settings.

Proper IAM roles are essential to control who can manage the network and who can use it, ensuring security and order.

Shared VPC simplifies secure communication across projects, reducing complexity and duplication in large cloud environments.

Understanding Shared VPC limits and best practices helps design scalable, secure cloud networks that avoid common pitfalls.

Practice

1. What is the main purpose of a Shared VPC in Google Cloud Platform?

easy

A. To automatically back up virtual machines across projects

B. To create multiple isolated networks within a single project

C. To allow multiple projects to share the same Virtual Private Cloud network

D. To enable direct internet access for all projects

Solution

1. Step 1: Understand Shared VPC concept

   Shared VPC allows multiple projects to connect to a common Virtual Private Cloud network managed by a host project.

2. Step 2: Compare options

   To allow multiple projects to share the same Virtual Private Cloud network correctly describes this sharing of a VPC across projects. Other options describe unrelated features.

3. Final Answer:

   To allow multiple projects to share the same Virtual Private Cloud network -> Option C

4. Quick Check:

   Shared VPC = Shared network across projects [OK]

Hint: Shared VPC means sharing one network across projects [OK]

Common Mistakes:

• Thinking Shared VPC creates isolated networks
• Confusing Shared VPC with backups or internet access
• Assuming Shared VPC is per project only

2. Which of the following is the correct way to enable Shared VPC on a host project using gcloud CLI?

easy

A. gcloud compute shared-vpc enable-host HOST_PROJECT_ID

B. gcloud projects add-iam-policy-binding HOST_PROJECT_ID --member=shared-vpc

C. gcloud compute shared-vpc enable --project=HOST_PROJECT_ID

D. gcloud compute networks create shared-vpc --project=HOST_PROJECT_ID

Solution

1. Step 1: Identify correct gcloud command for enabling Shared VPC

   The command to enable Shared VPC on a host project is 'gcloud compute shared-vpc enable-host'.

2. Step 2: Check options

   gcloud compute shared-vpc enable-host HOST_PROJECT_ID matches the correct syntax. Others are incorrect commands or unrelated.

3. Final Answer:

   gcloud compute shared-vpc enable-host HOST_PROJECT_ID -> Option A

4. Quick Check:

   Enable Shared VPC host with 'enable-host' command [OK]

Hint: Use 'enable-host' to activate Shared VPC on host project [OK]

Common Mistakes:

• Using 'enable' instead of 'enable-host'
• Confusing IAM binding with enabling Shared VPC
• Trying to create a network instead of enabling Shared VPC

3. Given a Shared VPC setup where Project A is the host and Project B is a service project, what happens if a VM in Project B tries to use a subnet from Project A's Shared VPC?

medium

A. The VM can use the subnet and communicate within the Shared VPC network

B. The VM creation fails because subnets cannot be shared

C. The VM uses a default subnet from Project B instead

D. The VM gets an external IP automatically

Solution

1. Step 1: Understand Shared VPC subnet usage

   In Shared VPC, service projects can create resources using subnets from the host project's VPC.

2. Step 2: Analyze VM subnet assignment

   VM in Project B can use Project A's subnet and communicate within the shared network.

3. Final Answer:

   The VM can use the subnet and communicate within the Shared VPC network -> Option A

4. Quick Check:

   Shared VPC allows subnet sharing for VM networking [OK]

Hint: Service projects use host subnets for VM networking [OK]

Common Mistakes:

• Assuming subnets cannot be shared
• Thinking VM defaults to service project subnet
• Confusing external IP assignment with subnet usage

4. You configured a Shared VPC but a service project cannot create VM instances using the host project's subnets. What is the most likely cause?

medium

A. The host project does not have any subnets created

B. The VM instance name is invalid

C. The service project is not linked to the host project

D. The service project lacks the 'compute.networkUser' role on the host project

Solution

1. Step 1: Check permissions for service project

   Service projects need 'compute.networkUser' role on the host project to use its subnets.

2. Step 2: Verify linkage and subnet existence

   While linkage and subnets are important, lack of permission is the most common cause blocking VM creation.

3. Final Answer:

   The service project lacks the 'compute.networkUser' role on the host project -> Option D

4. Quick Check:

   Missing networkUser role blocks subnet use [OK]

Hint: Check 'compute.networkUser' role for service project [OK]

Common Mistakes:

• Ignoring IAM roles and permissions
• Assuming linkage alone is enough
• Blaming VM name instead of network access

5. You want to design a secure environment where multiple teams have their own projects but share a common network with strict firewall rules managed centrally. How does using Shared VPC help achieve this?

hard

A. It requires each team to create their own VPC and manage firewall rules independently

B. It centralizes network management in one host project while teams use service projects for resources

C. It automatically applies firewall rules per project without central control

D. It isolates each team's network completely with no sharing

Solution

1. Step 1: Understand Shared VPC central management

   Shared VPC lets you manage network and firewall rules centrally in a host project.

2. Step 2: Analyze team project usage

   Teams use service projects to create resources but rely on the shared network and firewall rules from the host project.

3. Step 3: Compare options

   It centralizes network management in one host project while teams use service projects for resources correctly describes this central control with resource separation. Other options describe isolation or decentralized management.

4. Final Answer:

   It centralizes network management in one host project while teams use service projects for resources -> Option B

5. Quick Check:

   Shared VPC centralizes network and firewall control [OK]

Hint: Shared VPC centralizes network, teams use separate projects [OK]

Common Mistakes:

• Thinking Shared VPC isolates networks fully
• Assuming firewall rules are per project automatically
• Believing teams manage their own VPCs independently