VPC Service Controls: Stop Data Exfiltration in GCP

VPC Service Controls is a Google Cloud feature that draws a security boundary, called a service perimeter, around Google managed resources such as Cloud Storage buckets and BigQuery datasets, so that data cannot be read from or copied to resources outside that boundary. It is the main control Google Cloud offers against data exfiltration by stolen credentials, malicious insiders, or misconfigured IAM policies.

If you already know IAM, this is the next layer to learn. IAM answers "who is allowed to call this API." VPC Service Controls answers "from where, and can the data leave." Google recommends running both together for defense in depth, and cloud security interviews increasingly expect you to explain the difference.

Why IAM alone does not stop exfiltration

Most cloud data loss incidents are not exotic. They follow a short list of patterns:

• A service account key leaks into a public repository and is used from an attacker controlled machine.
• An engineer with legitimate access runs gcloud storage cp and copies a sensitive bucket to a personal project.
• A bucket or dataset is accidentally shared too broadly through an IAM binding.
• Compromised code inside a workload calls out to an external Google Cloud resource that the attacker controls.

In every one of those cases IAM behaves exactly as configured. The credential is valid. The permission is granted. The request succeeds. IAM has no concept of "this valid identity is calling from the wrong network" or "this data is now leaving my trusted boundary."

VPC Service Controls adds that missing dimension. A perimeter evaluates context: the network the request came from, the source IP range, the identity type, and whether the source and destination resources sit inside the same boundary. A stolen key is far less useful when the perimeter rejects any call that does not originate from an authorized VPC network.

How a service perimeter works

A service perimeter is a boundary you place around projects, VPC networks, or both. Inside the perimeter, communication flows freely. Across the perimeter, communication to restricted Google Cloud services is blocked by default.

Three practical consequences follow from that default deny behavior:

1. A VM inside the perimeter can read and write a Cloud Storage bucket in the same perimeter, but cannot reach a bucket outside it.
2. A copy between two Cloud Storage buckets succeeds only if both buckets are inside the same perimeter.
3. Access from the public internet to protected resources is denied unless you explicitly allow it.

Important scoping note: the perimeter protects Google managed services only. It does not block calls to third party APIs on the internet. It is also designed to control the movement of data, not metadata. Google is explicit that resource attributes such as bucket names may move in ways the perimeter does not check, so you still rely on IAM and custom roles for metadata control.

You also do not need a VPC network at all to use it. If your resources are not on a VPC, you can grant access using access levels built from external IP ranges or specific IAM principals.

The four building blocks

Component	What it does	When you reach for it
Service perimeter	Draws the boundary around projects and networks, blocking cross perimeter traffic to restricted services by default	Always, this is the foundation
Access level	Classifies internet requests by attributes such as source IP range, device policy, or geolocation	Letting admins reach protected resources from the console or a corporate IP range
Ingress and egress rules	Fine grained allowances for a specific identity, service, and resource crossing the boundary in one direction	Partner data exchange, CI pipelines, cross perimeter reads
Perimeter bridge	Bidirectional access between projects in two different perimeters	Legacy pattern, Google now recommends ingress and egress rules instead because they are more granular

Access levels are created in Access Context Manager, the service that maps an incoming request to a classification based on client attributes. Perimeters themselves live in an access policy. An organization has exactly one organization level access policy, and you can additionally create scoped policies attached to specific folders or projects when you want to delegate perimeter administration further down the resource hierarchy.

Dry run mode is the step people skip

Turning on a perimeter in enforced mode against a live environment is how teams cause outages. Google provides dry run mode precisely to avoid this. A dry run perimeter logs every request that would have been denied, without actually denying anything.

The safe rollout sequence looks like this:

1. Create the perimeter in dry run mode around the projects you intend to protect.
2. Run it for a full business cycle so that weekly and monthly jobs, backups, and reporting pipelines all execute at least once.
3. Review the violation logs and the violation dashboard to see what legitimate traffic would break.
4. Write the ingress and egress rules or access levels needed for that legitimate traffic.
5. Repeat until the dry run log is clean, then enforce.

Skipping step two is the most common mistake. A quarterly data export or a monthly reconciliation job that only runs on the last day of the month will not appear in a three day dry run, and it will fail loudly the first time the perimeter is enforced.

Google also documents a useful offensive twist on dry run mode: honeypot perimeters. You can stand up a perimeter specifically to log and identify unexpected probing of accessible services.

Private connectivity and the restricted VIP

A perimeter is only as strong as the network path into it. Google Cloud provides a restricted virtual IP, restricted.googleapis.com, which resolves to the 199.36.153.4/30 range. That range is not announced to the internet. Routing your API traffic through the restricted VIP means requests to supported services never traverse the public internet, and it blocks workloads from calling services that VPC Service Controls does not support.

For hybrid environments, you extend the perimeter to on premises networks using Private Google Access on premises extensions over an authorized VPN or Cloud Interconnect. The key rule is that the VPC network holding the landing zone from on premises must itself be part of the perimeter.

Where new engineers get stuck

Three issues account for most VPC Service Controls frustration:

Unsupported services. Not every Google Cloud service is supported. Google's guidance is direct: do not enable unsupported services inside a perimeter, especially alongside low level storage services such as Cloud Storage or Pub/Sub. Deploy them in projects outside the perimeter and grant their service account access through an access level if they genuinely need to read protected data. Trying to restrict an unsupported service through the CLI or the Access Context Manager API simply returns an error.

Console access. Reaching protected resources through the Google Cloud console requires an access level that permits your IPv4 or IPv6 range or your specific user accounts. Teams often build a perfect perimeter, then lock themselves out of the console.

Debugging denials. When something breaks, the answer is in Cloud Audit Logs. VPC Service Controls emits violation entries, and Google ships a violation analyzer plus a troubleshooter for diagnosing denials. Learning to read those logs is a genuinely marketable skill, because it is what separates an engineer who can deploy a perimeter from one who can operate it.

Build this in a lab, not on slides

Reading about perimeters is not the same as owning one. A useful practice exercise: create a project with a Cloud Storage bucket holding dummy data, place it in a dry run perimeter, attempt a gcloud storage cp to a bucket in an unprotected project, then read the violation in the audit log. Write an egress rule that allows exactly that one copy for exactly one service account, and confirm nothing else got wider. That single exercise teaches perimeters, ingress and egress rules, and audit log troubleshooting at once.

This is the pattern our 20 week curriculum follows across AWS, Azure, Google Cloud, and AI platform security: build the control, break it deliberately, then prove you can diagnose and fix it. If you want context on the identity layer that sits underneath perimeters, start with our guides to Google Cloud IAM and Security Command Center and GCP service account security. For the broader boundary concept across all three clouds, see cloud network security fundamentals.

Authoritative reference material lives in the VPC Service Controls overview and the ingress and egress rules documentation.

Frequently asked questions

Does VPC Service Controls replace IAM?

No. IAM provides identity based access control, deciding which principal may call which API. VPC Service Controls provides context based perimeter security, including control over data leaving the boundary. Google recommends using both together for defense in depth.

Does a service perimeter block access to third party APIs?

No. A service perimeter works specifically with Google managed services. It does not block access to third party APIs or other services on the internet. Egress controls for those paths come from your VPC firewall and networking configuration.

What is dry run mode used for?

Dry run mode logs requests that violate the perimeter policy without actually denying them. You use it to discover which legitimate workloads would break before you enforce the perimeter, and it can also be used to create honeypot perimeters that surface unexpected probing.

What is the difference between an ingress rule and an egress rule?

An ingress rule allows an API client outside the perimeter to access resources inside it. An egress rule allows a client or resource inside the perimeter to access Google Cloud resources outside it. Both are directional and can be scoped to specific identities, services, and resources.

Should I use a perimeter bridge or ingress and egress rules?

Google recommends ingress and egress rules over perimeter bridges. A bridge is bidirectional and grants projects in each perimeter equal access within its scope, while ingress and egress rules give you far more granular control over direction, identity, and service.

Do I need a VPC network to use VPC Service Controls?

No. If you have no resources on a VPC network, you can still create a perimeter and allow traffic from external IP ranges or from specific IAM principals using access levels.

Ready to build these controls with your own hands instead of reading about them? Review the full program curriculum or enroll now.