VPC Service Controls draws an invisible wall around your Google Cloud data, so that even a person holding a valid key cannot use it from the wrong place.

Google Cloud stores your data in services such as Cloud Storage, which keeps files, and BigQuery, which keeps tables for analysis. You reach these services by sending requests to their APIs, which are the online doorways that programs knock on. Normally the main question at the doorway is “who are you, and are you allowed?” That check is called IAM, short for Identity and Access Management.

VPC Service Controls, often shortened to VPC-SC, adds a second question: “where are you coming from, and where is the data going?” It lets you draw a service perimeter around chosen projects and services. Requests that stay inside the perimeter are fine. Requests that try to cross the wall, in or out, are blocked unless you wrote a rule that allows them.

The goal in one sentence

The main goal is to reduce the risk of data exfiltration, a technical word that means data being copied or moved out of a place where it should have stayed. That can happen by accident, through a mistake, or on purpose, through a thief or an unhappy insider. VPC-SC makes such copying much harder.

Who uses it

Organizations that hold sensitive or regulated data use it most: hospitals, banks, insurers, government bodies and companies with valuable research. Any team that needs to prove to an auditor that “this data cannot leave this boundary” finds it useful. Smaller teams can use it too, though they must be ready for the extra planning it requires.

Product names, screens and limits change over time. This guide teaches ideas that stay stable and points out where you should confirm details in the official Google Cloud documentation.

Most cloud data leaks do not happen because a lock was picked. They happen because a valid key was used in a place or a way nobody expected.

Imagine a company that keeps customer records in a cloud storage bucket. The team does everything right: only a small group has permission, passwords are strong, and access is logged. Yet there are still several ways the data can leave.

In all four cases, IAM is working as designed. The identity is valid, and the permission exists. IAM answers “who,” and it has no opinion about “from where” or “to where.” That gap is the reason VPC Service Controls exists.

Why the perimeter idea helps

With a perimeter, a stolen key becomes much less useful. The thief works from outside the wall, so requests are refused even though the identity is valid. A mistaken copy to an outside bucket fails because the destination is outside the wall. A public setting on a bucket does not automatically let the whole internet in. Each of these problems is turned from a disaster into a log entry.

A handful of words carry the whole subject. Learn them first, and every later chapter becomes easy to read.

Organization, folder and project

Google Cloud arranges resources in a tree. At the top is the organization, which represents your company. Below it are optional folders, which group things such as departments. At the bottom are projects, which hold actual resources like buckets, tables and virtual machines. VPC Service Controls needs an organization, because policies are managed at that level.

Service and API

A service is a Google Cloud product such as Cloud Storage or BigQuery. Each service is used through its API, which is its public doorway. VPC-SC protects the doorway, not the building. This is why we say it works at the API level.

Service perimeter

A service perimeter is a boundary you define around a set of projects and a set of services. Inside the perimeter, the protected services can talk to each other and to the protected projects freely. Crossing the boundary is controlled.

Restricted services

The list of services that the perimeter protects is called the restricted services. If Cloud Storage is on the list, then Cloud Storage buckets in the protected projects are guarded by the wall. Services that are not on the list are not guarded by it.

Access policy and Access Context Manager

An access policy is the container that holds your perimeters and access levels for an organization. Access Context Manager is the Google Cloud service that stores and manages these objects. You will see its name in roles and logs.

Access level

An access level is a named set of conditions about the caller, such as “comes from the office network address range” or “is in an allowed country” or “is one of these identities.” An access level can be attached to a perimeter to let trusted outside callers in.

Ingress and egress rules

Ingress means coming in. An ingress rule allows specific requests from outside into the perimeter. Egress means going out. An egress rule allows specific requests from inside to reach outside resources. Both rules say who, to what, and for which operations.

Dry run and violations

A violation is a request that the perimeter blocks, or in practice mode would have blocked. Dry run is a practice mode where violations are only recorded in logs and nothing is blocked. It is the safest way to learn what a perimeter would do.

Many beginners assume VPC Service Controls is another kind of firewall. It is not, and understanding the difference prevents costly surprises.

IAM: who may do what

IAM attaches permissions to identities. It says “this person may read objects in that bucket.” It does not look at the network location of the caller, and it does not care where data goes next.

Firewalls: what network traffic may pass

A firewall in Google Cloud controls network traffic to and from virtual machines and other network resources, based on addresses, ports and protocols. It works at the network layer. It cannot see that a request to the Cloud Storage API is copying a customer table to an outside bucket, because that traffic looks like ordinary encrypted web traffic to a Google address.

Private networking: how traffic travels

Features such as Private Google Access let machines without public addresses reach Google APIs over Google’s internal paths. This protects the route, but it does not decide which projects the machine may talk to. A machine on a private path can still copy data to any bucket it has rights to, including one in a stranger’s project.

VPC Service Controls: where requests come from and go to

VPC-SC checks each API request against the perimeter. It considers the project of the target resource, the origin of the caller, and the identity and operation. It can stop a request that is fully allowed by IAM and by the firewall.

The system has a small number of parts. Seeing how they connect makes the rest of the guide feel like a story, not a list.

flowchart TD
  ORG["Google Cloud Organization"] --> POL["Access policy"]
  POL --> PER["Service perimeter"]
  POL --> AL["Access levels from Access Context Manager"]
  PER --> PRJ["Protected projects"]
  PER --> SVC["Restricted services such as Cloud Storage and BigQuery"]
  PER --> ING["Ingress rules"]
  PER --> EGR["Egress rules"]
  PER --> VAS["VPC accessible services"]
  AL --> PER
  PER --> LOG["Audit logs of violations"]

The access policy

At the top sits the access policy of your organization. There is one main policy per organization. For large companies, scoped policies can be created for a folder or project, so that different teams manage their own perimeters without touching others.

The perimeter and what it holds

A perimeter lists the projects it protects, the services it restricts, and optional lists that fine-tune behavior: access levels that let outside callers in, ingress and egress rules for specific exceptions, and VPC accessible services, which limit which APIs may be reached from inside the perimeter’s networks.

The enforcement point

Enforcement happens inside Google’s API front end. When a request for a restricted service arrives, Google evaluates it against the perimeters that apply. You do not install an agent or a gateway for this. This is both convenient and a reason that the feature is configured as policy, not as network equipment.

The logs

Every blocked request, and every would-be block in dry run, creates an audit log entry with details about the caller, the target and the reason. These logs are the main tool for learning, debugging and monitoring.

The simplest way to learn the behavior is to picture four kinds of requests and ask what happens to each.

flowchart LR
  subgraph OUT["Outside the perimeter"]
    ATT["Caller with stolen credentials"]
    EXTB["Bucket in an outside project"]
  end
  subgraph IN["Inside the perimeter"]
    VM["Application or virtual machine"]
    BQ["BigQuery dataset"]
    GCS["Cloud Storage bucket"]
  end
  ATT -. blocked .-> GCS
  VM --> BQ
  VM --> GCS
  GCS -. blocked copy .-> EXTB

Case 1: inside to inside

An application in a protected project reads a table from BigQuery in another protected project of the same perimeter. This is the normal case. The perimeter allows it, and then IAM still checks permission. Nothing special is needed.

Case 2: outside to inside

A caller outside the perimeter tries to read a bucket inside it. Even with a valid identity, the request is refused unless an access level or an ingress rule describes it. This case protects you from stolen credentials used from far away.

Case 3: inside to outside

An application inside tries to copy data to a bucket in a project outside the perimeter. This is the exfiltration case. The request is refused unless an egress rule allows that destination. The copy fails even though the user may have write rights on the outside bucket.

Case 4: outside to outside

Two resources that are both outside the perimeter talk to each other. The perimeter does not care. It only guards the protected projects and their restricted services.

A perimeter only protects what it knows how to protect. Understanding service support avoids false confidence.

VPC Service Controls does not work with every Google Cloud product. Google publishes a list of supported products, which includes many storage, data analytics, machine learning, messaging and compute-related services. Some products are fully supported, and some have limitations, such as certain features that do not work inside a perimeter. The list grows over time, so always check the current list before you design.

Restricted services in the perimeter

When you configure a perimeter, you choose which services to restrict. You can restrict all supported services, or only a chosen few. A common starting point for beginners is to restrict the services that actually hold sensitive data, such as Cloud Storage and BigQuery, then widen the list as your confidence grows.

Unsupported or unrestricted services

If a service is not supported, or is not on the restricted list, its API is not guarded by the perimeter. Data in that service can still be reached according to IAM alone. Therefore, a careful design lists every service that touches sensitive data and checks that each one is both supported and restricted.

Features with limits

Some services behave differently inside a perimeter. For example, a feature may need an extra rule to work across projects, or may not be available at all. Read the notes for each service you depend on, and test in dry run before enforcing.

Abstract rules become clear when you watch ordinary tasks, such as copying a file or running a query, meet the wall.

Cloud Storage: copying files

Copying a file between two buckets in projects of the same perimeter works normally. Copying to a bucket in a project outside the perimeter is blocked unless an egress rule allows that destination. Reading a file from outside the perimeter is blocked unless an access level or ingress rule allows the caller. This is why a bucket that was accidentally made too open becomes much less dangerous.

BigQuery: queries, exports and public data

BigQuery is a service for analysing large tables with questions called queries. A query that reads tables in several protected projects of one perimeter works well. A query that mixes your table with a table in a project outside the perimeter may be blocked. Exporting results to a bucket or table outside the perimeter is blocked unless a rule allows it. Reading a public dataset hosted by someone else may also count as crossing the boundary, so such reads often need a narrow egress rule. Dry run shows these cases clearly.

Messaging: publishing and subscribing

Messaging services such as Pub/Sub move small messages between programs. A topic and its subscriptions in the same perimeter work normally. If a subscription in one perimeter reads from a topic in another, both sides of the crossing need rules, just as for files and tables. Teams often forget these quiet background flows until the logs show them.

Virtual machines and applications

A virtual machine in a protected project that calls Cloud Storage or BigQuery in the same perimeter works as usual. If the machine’s calls leave through the wrong network path, for example the public internet, Google may see them as outside requests. This is why DNS and routing settings for private access matter so much.

Log exports

Many companies export logs to a bucket or a dataset in another project for long-term storage. That destination may be outside the perimeter, and the export can fail after enforcement. Plan the log destination as part of your design, either inside the perimeter or with a clear, narrow rule.

The access policy is the folder in which all your perimeters and access levels live. Its structure decides who can change what.

Each organization has one organization-level access policy. All perimeters and access levels created in it are visible to those who manage it. In a small company, one policy is plenty. A single security team creates the perimeters and everyone else lives inside them.

Why scoped policies exist

In a large company, one central team cannot know every project’s needs. Scoped policies let administrators create a policy limited to a folder or a project, and delegate its management to the team that owns that area. A scoped policy can only affect the resources in its scope. This reduces risk, because a mistake by one team cannot lock out the entire company.

Good habits for policies

• Use clear, consistent names for perimeters and access levels, so the purpose is visible in logs.
• Write a short description in each object, saying who owns it and why it exists.
• Keep configuration in version control, so changes are reviewed and reversible.
• Limit who can edit the policy, because an edit can open or close many doors at once.

Access levels answer one question: which outside callers should be treated as trusted guests?

An access level is created in Access Context Manager. It is a named bundle of conditions, and a request that meets the conditions “has” that access level. You then attach the access level to a perimeter, and requests from outside that satisfy it are allowed in.

What conditions can describe

• Network address ranges. For example, the public addresses of your office or your company’s VPN. Requests coming from those ranges qualify.
• Geographic regions. Requests that appear to come from selected countries qualify. This is helpful but not exact, since location is estimated from addresses.
• Identities. Selected users or service accounts qualify, regardless of where they are.
• Device conditions. With additional Google products for device management, a condition can require a company-managed, up-to-date device. Availability depends on your licenses.

Conditions can be combined. A level can say that a request must satisfy all conditions, or any of them. A careful team uses narrow combinations, such as “these identities, and from this VPN range.”

Access levels or ingress rules?

Access levels give a broad “trusted caller” status that applies to all restricted services and all projects in the perimeter. Ingress rules, covered next, can be narrower, naming the exact service and operation. A common pattern uses access levels for human administrators on a corporate network, and ingress rules for specific machines or partners.

Ingress rules are written exceptions. They say that one precise kind of request from outside may enter, and nothing else may.

An ingress rule has two halves. The from half describes the caller: which identities, such as certain service accounts, and which sources, such as a particular access level, or specific projects or networks. The to half describes the target: which projects, which services and which methods, meaning which operations on those services.

An example in words

Your company has an automation system outside the perimeter that must read objects from one bucket service inside it. An ingress rule can say: “Allow the automation system’s service account, coming from this project, to call only the read operations of Cloud Storage, on this one protected project.” Any other caller, other service or other operation remains blocked.

Why narrow rules matter

Each rule is a small hole in the wall. A rule that names one identity, one service and a few operations is a tiny peep-hole. A rule that allows all identities, all services and all operations is a gaping door. The narrower the rule, the lower the risk if that identity is later compromised.

Egress rules guard the most important exit: the path by which data could leave. Each one should be rare and well justified.

Real systems sometimes need to send data out. A company might export reports to a partner’s bucket, or an application inside the perimeter may need to read a public dataset hosted by Google or another party. Egress rules provide a controlled way to do that.

Structure of an egress rule

Like ingress rules, egress rules have a from half and a to half. The from half describes the caller inside the perimeter, usually an identity or a type of identity. The to half names the outside resources, such as specific projects, the services and the methods allowed. A rule might say: “Allow this one export job’s service account to write to this one project’s storage service, using only the create-object method.”

flowchart LR
  subgraph P1["Perimeter A: production data"]
    DA["Analytics project"]
  end
  subgraph P2["Perimeter B: partner sharing"]
    DB["Shared dataset project"]
  end
  DA -->|Egress rule allows export| DB
  EXT["Trusted partner network"] -->|Ingress rule allows read| DB

Two-sided crossings

When data moves between two perimeters, both sides may need a rule. The perimeter that the data leaves needs an egress rule, and the perimeter that receives it needs an ingress rule. If only one side is configured, the request still fails. Many first-time users are surprised by this, so remember that crossing a wall means passing two gates.

Real organizations have more than one perimeter, and sometimes those perimeters must exchange data. There are a few ways to do it, from old to modern.

The perimeter bridge

A perimeter bridge is an older feature that connects two perimeters, so projects in each can talk to each other for the services they restrict. It is simple, but it is broad. Once two perimeters are bridged, all their projects and services can interact, which may be much more than anyone wanted.

Ingress and egress rules instead

Modern designs prefer ingress and egress rules, which allow exactly one kind of crossing at a time. Google’s current guidance leans toward these rules for new designs. Because documentation evolves, check the latest recommendation before you create anything that connects perimeters.

Putting projects in one perimeter

Sometimes the best answer is not a rule at all. If two projects work together closely and hold similar data, put both in the same perimeter. Then all traffic between them is internal and needs no exception. The downside is a bigger perimeter, so weigh how much the two projects trust each other.

Besides guarding the data, you can also limit which Google APIs may be reached from the private networks inside the perimeter.

Machines inside your VPC networks can talk to many Google APIs. A perimeter can include a setting called VPC accessible services. It lists the services that may be reached from the perimeter’s networks. If you set it to only the services your applications really need, a compromised machine cannot use other Google APIs as an escape route.

What it protects against

Think of a virtual machine that has been taken over by an attacker. The attacker might try to call a Google API that you never intended anyone to use, perhaps one that can send data to the attacker’s account. If that API is not in the list of accessible services, the call fails right from the start.

How to use it wisely

• Begin by allowing all restricted services, and watch the logs to see which APIs your machines actually call.
• Then narrow the list to the services you really need, and add any supporting services that your tools use behind the scenes.
• Remember that the list restricts calls made through the networks inside the perimeter, not calls made from elsewhere.
• Document why each service is on the list.

When a request arrives at a Google API, a short chain of questions decides its fate. Knowing the chain makes every error message readable.

flowchart TD
  R["API request arrives"] --> S{"Is the service restricted by a perimeter?"}
  S -->|No| IAM["Only IAM is checked"]
  S -->|Yes| P{"Is the target resource in the perimeter?"}
  P -->|No| IAM
  P -->|Yes| I{"Does the caller come from inside the perimeter?"}
  I -->|Yes| OKI["Perimeter allows it, then IAM is checked"]
  I -->|No| AL{"Does an access level or ingress rule allow it?"}
  AL -->|Yes| OKI
  AL -->|No| DENY["Request denied and a violation is logged"]

Step by step

For private networks, on-premises offices and virtual machines without public addresses, a few network settings make the perimeter work as intended.

Why the network matters

A machine in a private network reaches Google APIs through a special route. If it uses the ordinary public addresses of Google APIs, the request may be treated like any outside request. Google offers special names and address ranges so that traffic from your networks arrives as part of your perimeter and is recognized as internal.

The restricted and private virtual addresses

Two special names exist for private access: restricted.googleapis.com and private.googleapis.com. The restricted one only reaches APIs that support VPC Service Controls, which means requests to unsupported APIs fail and cannot become a hidden escape route. The private one reaches most Google APIs, including some that VPC-SC does not cover. For perimeter-focused designs, the restricted address range is the safer choice.

DNS and routing

To send traffic to the restricted address range, your network’s DNS (the system that turns names into addresses) is set so that Google API names point to the restricted range. Routes must also be present so traffic can reach it. Private Service Connect endpoints for Google APIs offer another modern way to do the same job, with an option designed for VPC-SC. Confirm the current method in the documentation, since recommended paths change.

flowchart LR
  ONP["On premises network"] --> VPN["VPN or Interconnect"]
  VPN --> VPC["VPC network inside the perimeter"]
  VM2["Virtual machines"] --> DNS["DNS maps Google API names to restricted addresses"]
  VPC --> DNS
  DNS --> RV["Restricted Google API address range"]
  RV --> API["Google APIs checked by the perimeter"]

On-premises machines

Offices and data centers connected by VPN or Interconnect can also use the restricted address range, if routes and DNS are set up to send API traffic through the private link. Their requests then appear as coming from inside the perimeter’s network, and no public access level is needed for them.

Many companies use a shared network owned by one project and used by many. Perimeters must respect that structure.

A Shared VPC lets a central host project own a network that other service projects use. The virtual machines live in the service projects, but their traffic travels over the host project’s network. This is a popular way to keep networking under central control.

The rule of thumb

Put the host project and all of its service projects in the same perimeter. If a service project is outside the perimeter while the host is inside, its machines use a network that belongs to the perimeter, and requests may be blocked or treated in confusing ways. Keeping them together avoids a large class of problems.

Planning your perimeters around networks

• List all Shared VPC host projects and their service projects before you create perimeters.
• Keep a Shared VPC family in one perimeter, unless you have a clear plan for crossing rules.
• Remember that adding a new service project later means adding it to the perimeter too.
• Test network-heavy workloads, such as managed data services running in private networks, in dry run first.

The biggest risk with VPC Service Controls is not the technology. It is switching on a wall without knowing what already crosses it.

Dry run is the feature that makes VPC Service Controls safe to adopt. Treat it as a required step, never as an optional extra.

Every perimeter can have two configurations side by side: the enforced configuration, which actually blocks requests, and a dry-run configuration, which only logs what would happen. You can create a perimeter with only a dry-run configuration. You can also add a dry-run configuration to an enforced perimeter, to test a proposed change before applying it.

flowchart LR
  A["Plan and inventory"] --> B["Create dry run perimeter"]
  B --> C["Collect violation logs"]
  C --> D["Add access levels and rules"]
  D --> E{"Logs clean for long enough?"}
  E -->|No| C
  E -->|Yes| F["Enforce the perimeter"]
  F --> G["Operate and review"]
  G --> D

What dry run teaches you

• Which services and callers cross the boundary today.
• Which automation and scheduled jobs were forgotten.
• Which partners or tools depend on outside access.
• How much noise to expect once the perimeter is enforced.

How long to wait

Watch for at least one full business cycle. Monthly reports, quarterly audits and yearly tasks may use paths that a two-day test never sees. Many teams run dry mode for several weeks before enforcing, and longer for complex systems.

Using dry run for every change

Dry run is also the right way to test future changes. Propose the new rule or new project in the dry-run configuration, and watch the logs. Only when the picture is clean, promote the change into the enforced configuration.

The power to change a perimeter is the power to open every door in it. That power should belong to very few people.

Perimeters and access levels are managed through Access Context Manager, and access to them is controlled by IAM roles at the organization level or, for scoped policies, at the folder or project level. There are ready-made roles for administering, editing and only reading policies. Names change slowly, so confirm the exact roles in current documentation. The ideas below stay the same.

Good habits

• Give administrator rights to a small group, and review that group regularly.
• Require a written request and a second reviewer for any change to enforced perimeters.
• Keep changes in code and version control, so every change has an author, a reason and a time.
• Create a “break-glass” procedure for emergencies, with extra logging and an after-event review.
• Allow application teams to read logs of their own violations, so they can solve problems without waiting for a security person.

Every blocked request leaves a trail. Reading it is the main skill of anyone who runs a perimeter.

When a request is denied, or would be denied in dry run, Google Cloud writes an audit log entry in the project that holds the targeted resource, and at the organization level where configured. The entry says who called, from where, to what service and method, which perimeter applied, and the reason for the violation. The error shown to the caller includes a unique ID that points to that exact log entry.

Reading the error message

The user sees a message saying that the request is prohibited by the organization’s policy, together with a unique identifier. That identifier is the key. Anyone with permission can search the logs for it and see the full details, which saves guessing.

Common violation reasons

What to record about each violation

• The caller identity and where it was running.
• The target project, service and method.
• Whether the entry is dry run or enforced.
• The decision: fix, allow with a rule, or leave blocked because it should be blocked.

A calm, ordered method turns a frightening error into a ten-minute task.

flowchart TD
  V["Request blocked"] --> U["Copy the unique ID from the error"]
  U --> L["Find the audit log entry or use the troubleshooting tool"]
  L --> R{"What is the violation reason?"}
  R -->|No matching access level| N1["Caller is outside: consider a narrow access level or ingress rule"]
  R -->|Resources not in same perimeter| N2["Crossing perimeters: consider rules or moving a project"]
  R -->|Service not allowed from VPC| N3["Adjust the list of VPC accessible services"]
  N1 --> T["Test the change in dry run first"]
  N2 --> T
  N3 --> T
  T --> E["Apply the narrowest fix and document it"]

Tools that help

Google Cloud provides tools for this work. A troubleshooting tool takes the unique ID and explains the violation in plain language. A violation analyzer in the console groups violations and suggests the kind of rule that might fix them. Names and screens evolve, so look for the current options in the VPC Service Controls section of the console.

A calm routine

Machines are the most common source of surprise violations. Pipelines, scheduled jobs and Google’s own helper accounts all cross boundaries.

Build and deployment pipelines

A continuous integration and delivery pipeline builds code, tests it and deploys it. If the pipeline runs outside the perimeter, for example on a hosted build service or a laptop, its calls into protected projects are outside-to-inside and need an ingress rule or an access level. If it runs inside, its calls are internal, but its calls to outside tools, such as public package sources or other projects, may need egress rules.

Infrastructure as code tools

Tools that create cloud resources from files run with a service account and call many APIs. If they run from a company laptop or a hosted runner, they come from outside. A common solution is to run them from a build service inside the perimeter, or to give their identity a very narrow ingress rule.

Service agents

Many Google Cloud services act on your behalf using special accounts called service agents. For example, a data analysis service may read from your storage bucket using its own agent. These agents are managed by Google, and VPC-SC has built-in handling for many of them, but some flows still need explicit rules, especially when data crosses projects. Dry run reveals which ones appear in your logs.

Scheduled jobs and partners

Monthly exports, yearly audits and partner integrations tend to hide until they fail. Ask each team for a list of recurring jobs before enforcing, and watch for them in dry-run logs.

A perimeter is not a one-time installation. It has a life: it is born, it matures, it changes, and eventually parts of it are retired.

Following one request through the life of a rule

Imagine a partner needs to read a monthly report. In month one, the request is blocked, and the violation appears in the logs. The security team and the partner agree on a narrow ingress rule. It is tested in dry run during the next cycle, and then enforced. For a year, the partner’s reads succeed quietly. At the yearly review, the owner confirms the partnership is still active. Two years later the partnership ends, and the rule is removed. Each stage has an owner and a date.

There is no single right number. The best design balances strong separation against the effort of managing many boundaries.

One big perimeter

A single perimeter around everything is simple to explain and has few internal exceptions. It protects against outside threats. Its weakness is that nothing separates one internal team’s data from another’s. A compromised project can reach all others in the perimeter, subject only to IAM.

Many small perimeters

One perimeter per application or per data set gives strong separation. A breach in one area cannot easily spread. The cost is more rules, since every cross-team flow now crosses a wall, and more work for administrators.

Common middle paths

• By environment: separate perimeters for production and non-production, so test projects cannot reach production data.
• By sensitivity: a strict perimeter for regulated data, and a lighter one for general work.
• By business unit: each department manages its own perimeter through a scoped policy.
• By purpose: a perimeter for shared tools such as logging and monitoring, with narrow rules to and from the others.

A good security tool is honest about what it does not do. Knowing the limits helps you build the other layers you need.

What VPC Service Controls helps with

• Stolen credentials used from outside the allowed boundary.
• Accidental or deliberate copying of data to projects outside the perimeter.
• Accidentally public resources, where the perimeter can still block outside callers.
• Limiting which APIs your private networks can reach.
• Giving auditors a clear, logged boundary.

What it does not do

• It is not a network firewall. It does not control traffic between virtual machines, or traffic to the open internet.
• It does not replace IAM. A perimeter never grants permission, and weak IAM remains a risk inside the wall.
• It does not cover everything. Unsupported or unrestricted services are not guarded.
• It cannot stop a trusted person inside from misusing data. An authorized insider who works from an allowed place can still read what IAM allows, and can copy data to places inside the perimeter or to their own screen.
• It does not encrypt or classify data. Those are separate controls.
• It cannot protect data that left through other channels. For example, a virtual machine sending data to a website on the internet is a network matter, not an API matter.

A perimeter is strongest when it stands among other protections. Here are the neighbors that matter most.

Organization policies

Organization policies are guardrails that limit which settings may be used in your cloud, for example where resources may be created, or whether certain risky actions are allowed at all. They stop bad configurations from being made in the first place, while the perimeter judges requests as they happen. Together they cover both “what may exist” and “what may move.”

Least-privilege IAM

IAM remains the main source of permission. Keep roles narrow, prefer groups to individuals, and review who holds powerful roles. Inside a perimeter, IAM is the last line that limits what an allowed caller can do.

Short-lived credentials

Credentials that expire quickly give a thief little time. Prefer attached platform identities and short-lived tokens to downloadable key files. Many organizations also block the creation of key files entirely using an organization policy.

Audit logging and monitoring

Beyond violations, record who reads or changes data. Data access audit logs may need to be switched on for services that hold sensitive information. Alerts on unusual behavior help catch an insider who works within the rules.

Encryption and key control

Data in Google Cloud is encrypted by default. Some organizations add customer-managed encryption keys for extra control over who can decrypt data. Encryption protects the content, and the perimeter protects the access path, so the two complement each other.

Sensitive data discovery

You cannot protect what you have not found. Tools that scan for sensitive data, such as customer identifiers, can help you decide which projects belong inside a strict perimeter.

A perimeter that nobody watches slowly decays. A few simple alerts and dashboards keep it healthy.

Violations are written to audit logs, and logs can be turned into numbers. Cloud Logging lets you create log-based metrics, which count matching log entries over time. Cloud Monitoring can then draw charts and send alerts from those counts. This is how you learn about problems before users complain.

Useful numbers to watch

Alerts worth setting

• Sudden spike in violations. This may mean a broken deployment, a new misconfigured job, or an attacker probing.
• Violations from unusual places. A burst of denied requests from a country you never use deserves a look.
• Any change to an enforced perimeter. Administration changes are rare and important, so notify the security team each time.
• Dry-run violations after a change. If you test a new rule, alert on any new dry-run violations.

Keep the logs safe and long enough

Audit logs may be needed months later by investigators or auditors. Route copies of important logs to a protected storage place or analysis tool, with its own access controls. Be careful that the destination of the log export is itself compatible with your perimeter rules, otherwise the export may be blocked.

The money cost of a perimeter is usually small. The people cost is where careful planning matters.

Direct cost

Check the current pricing documentation for any charge related to VPC Service Controls itself, because pricing can change. In any case, there are indirect costs: log storage, log analysis, and the services that run your monitoring. Audit logs of violations can grow large if a misconfigured job keeps failing, so watch the volume.

Operational effort

The real investment is time. Someone must plan the design, run the dry-run period, write and review rules, answer questions from developers, and review the configuration regularly. Estimating this effort honestly is part of the decision.

Ways to keep effort low

• Write a short guide, with common errors and fixes, for developers.
• Use templates for new projects that already include the perimeter membership.
• Standardize rules, so the same kind of request gets the same kind of answer.
• Manage configuration as code, which makes reviews faster and mistakes rarer.

Every control is a bargain. Look at both sides honestly, then decide how much perimeter you really need.

Compared with other approaches

Trade-offs to think about

Protection versus agility. Each wall slows some legitimate work. A faster approval process for narrow rules keeps teams productive.

Coverage versus complexity. Restricting more services protects more, but it adds more exceptions to manage. Begin with the services that hold the most sensitive data.

Centralization versus ownership. A central team gives consistency, and scoped policies give speed. Many companies use both, with shared standards.

Patterns are lessons that other teams paid for. Anti-patterns are the traps they fell into.

Six helpful patterns

Three costly anti-patterns

The habits below are simple. They come from many teams learning the hard way.

Best practices

• Protect the data first, not the whole company. Begin with the datasets that would hurt most if leaked.
• Verify service support. List every service on the data path and confirm each is supported and restricted.
• Keep Shared VPC families together. Host and service projects belong in one perimeter.
• Test administrators’ access path. Make sure your own team can still manage the perimeter after enforcement.
• Use the restricted network path. Configure DNS and routes so private traffic uses restricted addresses.
• Write rules as narrowly as you can. Name identities, target projects and methods.
• Document and review. Add owners, reasons and review dates to every exception.
• Monitor violations and changes. Alert on spikes and on edits to enforced perimeters.
• Train developers. A one-page guide on reading the unique ID saves hours.

Common mistakes and quick fixes

Things will occasionally go wrong. A prepared team recovers in minutes, and an unprepared team in days.

Principles for recovery

• Understand before you loosen. A rushed wide exception may stay for years.
• Keep a break-glass path. A rarely used, heavily logged way for a few trusted people to regain control.
• Use temporary exceptions with an end date. If an urgent exception is unavoidable, record who approved it and when it must be removed.
• Review after every incident. Ask what the dry run missed, and add that lesson to your checklist.
• Keep configuration in version control. Rolling back a bad change is far easier when the previous version is saved.

Different organizations use VPC Service Controls for different reasons. Find the story that looks like yours.

The wider picture

Industries with strict rules about data, such as health care, finance, insurance and public services, are the most common users. We describe these as general patterns, and do not claim that any named company uses VPC Service Controls in a specific way, because public information on this is limited. Many well-known data breaches in the cloud era involved valid credentials used from unexpected places, and this is the pattern that perimeters are designed to blunt.

The deeper lesson is about assumptions. Old security assumed that anyone inside the network is trusted. Modern security assumes that identities can be stolen and mistakes will happen, so it adds boundaries that hold even then. A perimeter turns “we hope nobody does this” into “this cannot happen without being noticed.”

Let us follow a made-up security engineer named Ravi as he protects a customer data project from start to finish.

Ravi works at a small insurance company. The company keeps claim records in a storage bucket and an analysis dataset, both in one project called the claims project. The data is sensitive, and the auditors have asked for proof that it cannot leave the company’s cloud organization. Ravi decides to use VPC Service Controls.

First he lists who and what touches the claims project. The analytics team reads data from the office network. A nightly job copies a summary to a reporting project. A partner company reads one file each month. A build pipeline running on a hosted service deploys small tools. He also finds an old test script that copies data to a developer’s personal project, which makes everyone nervous.

He creates a perimeter in dry-run mode around the claims project and the reporting project, restricting the storage and analysis services. For three weeks he reads the logs. As expected, the monthly partner read and the hosted pipeline appear as violations. The old test script appears too, with a violation that says the destination is outside the perimeter. Ravi has the script removed, and happily records that the perimeter just found a real risk.

For the partner, he writes a narrow ingress rule that allows only the partner’s service account to read objects from one project. For the pipeline, he moves the deployment tool to a build service running inside the company’s projects. For human users, he creates an access level based on the office network’s address range and the company VPN. He also tests an access level for administrators, so that the security team will not be locked out.

After two quiet weeks of clean dry-run logs, Ravi enforces the perimeter on a Tuesday morning, with the team on standby. A few small questions arrive, and each one is answered with the unique ID and the troubleshooting tool. He sets up an alert for spikes in violations and for any change to the enforced perimeter. At the next quarterly review, he checks that every rule has an owner and a reason.

A perimeter works best when the surrounding habits are clear. A few agreements prevent most confusion.

A request process

Create a simple, written process for asking for an exception. The request should say who needs access, to what, why, for how long, and who owns it. A security reviewer checks that the rule is narrow, and a second person approves it. A simple form is enough, as long as every exception leaves a record.

Standards for naming and documentation

Choose clear names for perimeters and access levels, such as the environment, the data type and the owner team. Write a short description for each object. When a new teammate reads the configuration, the names should explain the design.

Ownership

Decide who owns the perimeter design, who owns each rule, and who watches the logs. A common split is that a central security team owns the overall design and access levels, platform teams own rules for their areas, and application teams own the reasons for their requests.

Regular rhythm

Hold a short quarterly review. Check every rule for an owner and a reason, remove expired exceptions, and look at the top sources of violations. Share a short summary with the wider engineering community, so everyone learns from it.

You do not need to learn everything at once. Move from simple and safe to detailed and powerful.

Keep a notebook of every violation you solve, with the reason and the fix. After a month it becomes your own handbook, and you will recognise common patterns quickly, which is the real skill behind running perimeters well.

Short, honest answers to the questions beginners ask most often.

If you remember only a few ideas from this long guide, make them these.