Building a Secure VPC Architecture With Shared VPC and VPC Service Controls

As cloud footprints grow, networking and security design mature from simple VPC setups to more centralized and governed architectures. On Google Cloud, Shared VPC and VPC Service Controls form the backbone of secure, scalable, enterprise-ready networks.

If you’re running workloads across multiple teams, multiple projects, and sensitive datasets, these two capabilities are no longer optional—they’re essential.

Let’s break down how to architect a secure VPC environment using both.

---

1. Why Move Beyond Standard VPCs?

A single project with a single VPC is fine—for small teams.

But experienced leaders know this approach doesn’t scale when:

• You have multiple engineering teams
• You want central governance over networks
• You need strong data exfiltration protection
• You’re managing dozens or hundreds of GCP projects
• Compliance requirements demand strict segmentation

Shared VPC and VPC Service Controls help you build a network that’s centralized, secure, and future-ready.

---

2. Shared VPC — Centralized Networking With Distributed Ownership

Shared VPC lets you host your networking in one project (“the host project”) while attaching other projects (“service projects”) to it.

In simpler terms:

The network team controls networking.
The application teams deploy workloads.
Both stay independent without stepping on each other.

---

How Shared VPC Works

• You create VPCs, subnets, firewalls, routes, NAT in the host project.
• You attach one or many service projects to it.
• Each service project uses the centralized network primitives.

This gives your organization a single source of truth for:

• IP address planning
• Inter-service communication
• Firewall policy governance
• Routing and connectivity control
• Hybrid connectivity (VPN/Interconnect)

---

Benefits of Shared VPC Architecture

1. Centralized security governance

Security teams define firewall rules across all projects consistently.

2. Controlled east-west traffic

Application teams cannot modify network rules—reducing risk.

3. Efficient IP management

Simplify subnet planning and avoid IP overlaps across teams.

4. Scales well for large orgs

Easier onboarding and offboarding of new products/project teams.

5. Smooth hybrid connectivity

A single cloud network connects to your on-prem environments.

---

Shared VPC Design Best Practices

✔ Use separate host projects for production and non-production

Avoid accidental cross-talk and ensure blast-radius control.

✔ Segment workloads using subnet boundaries

By environment (dev/stage/prod), by domain, or by business unit.

✔ Apply hierarchical firewall policies

Keep org-wide rules at the top; use project-level overrides sparingly.

✔ Use Private Service Connect

Securely connect to managed services without exposing traffic to public internet.

✔ Keep service project IAM strict

Only grant what each team needs—nothing more.

---

3. VPC Service Controls — The Data Exfiltration Firewall

Shared VPC secures network traffic.
VPC Service Controls (VPC-SC) secures data access.

Think of VPC-SC as building a “service perimeter” around your sensitive Google-managed services (e.g., BigQuery, Cloud Storage, Firestore, Pub/Sub, Secret Manager).

Inside the perimeter = trusted zone
Outside the perimeter = untrusted zone

It prevents:

• Data exfiltration
• Unauthorized access from outside your perimeter
• Stolen credentials from accessing sensitive data
• Access coming from unexpected networks or projects

Even if a service account key leaks, VPC-SC can stop attackers from reaching your resources.

---

How VPC Service Controls Work

You define a service perimeter, which includes:

• Specific GCP projects
• Services (BigQuery, Storage, etc.)
• Access levels (Identity-Aware Proxy, approved networks, device policies)
• Restricted ingress and egress rules

Once defined, only principals and networks inside the perimeter can access protected services.

---

Key Features

1. Perimeter restrictions

Block API access from outside networks, unmanaged devices, or unapproved locations.

2. Egress policies

Control what perimeter resources can communicate with externally.

3. Access levels (context-aware access)

Control access based on:

• User identity
• Device type
• IP/network origin
• Geo-location
• TLS certificate posture

4. Dry-run mode

Test a perimeter before enforcing it—essential for production.

---

When You Should Use VPC Service Controls

• You store sensitive data (financial, operational, regulated)
• You operate in a Zero-Trust or compliance-driven environment
• Multiple engineering teams have write access to cloud resources
• You want to prevent lateral movement even if credentials leak
• You need to stop data from leaving GCP accidentally or maliciously

---

4. Designing a Secure Architecture With Both Shared VPC + VPC-SC

Using Shared VPC alone creates a governed network.
Using VPC-SC alone protects sensitive data.
Using them together creates a secure, enterprise-grade perimeter-controlled architecture.

Let’s see how.

---

Step 1: Create Two Host Projects

• Prod-Host-Network
• NonProd-Host-Network

This creates clear separation and blast-radius isolation.

---

Step 2: Attach Service Projects

Each application team gets its own service project:

• Web-Team-Service-Project
• Data-Team-Service-Project
• Analytics-Service-Project
• Finance-Service-Project

All use the centralized Shared VPC network.

---

Step 3: Segment Subnets & Workloads

Example segmentation:

• 10.10.0.0/20 → Frontend services
• 10.20.0.0/20 → Backend services
• 10.30.0.0/20 → Data pipelines
• 10.40.0.0/20 → Admin workloads

Segmentation = controlled blast radius + better auditability.

---

Step 4: Add VPC Service Control Perimeters

Create perimeters around:

• BigQuery datasets
• Cloud Storage buckets
• Firestore databases
• Secret Manager
• Artifact Registry

This prevents unauthorized data access—even from internal misconfigurations.

---

Step 5: Use Access Context Manager

Define who can access what, based on:

• Identity
• Device trust
• Source network
• Region restrictions

This enforces Zero Trust.

---

Step 6: Use Private Service Connect for Google APIs

This ensures that:

• Traffic to Google APIs stays inside Google’s private network
• No public internet paths exist
• Services like BigQuery, Storage, and Pub/Sub operate securely

---

5. Additional Best Practices for GCP Network Security

✔ Use NAT Gateways for outbound traffic

Keep workloads private without requiring public IPs.

✔ Use Firewall Insights

Identify overly broad or unused firewall rules.

✔ Deploy Cloud Armor

Protect public-facing endpoints from DDoS and application attacks.

✔ Enforce IAM least privilege

Combine IAM + VPC-SC for stronger boundaries.

✔ Enable logging everywhere

VPC Flow Logs, Cloud Logging, Cloud Audit Logs.

✔ Automate with Infrastructure as Code

Use Terraform to enforce consistency and prevent human error.

---

Final Thoughts

A modern cloud environment doesn’t rely on a single control—it uses layered security. On Google Cloud, Shared VPC provides centralized, governed networking, while VPC Service Controls adds strong data exfiltration protection.

Together, they give IT leaders:

• Predictable governance
• Network segmentation aligned with Zero Trust
• Strong perimeters for sensitive data
• Clear operational boundaries across teams
• Reduced blast radius and stronger compliance posture

This isn’t just “good networking architecture”—it’s the foundation of a secure, scalable, enterprise GCP environment.