Valid credentials are not proof of good intentions.

Google’s documentation describes VPC Service Controls as creating security perimeters around Google Cloud managed services to reduce the risk of data exfiltration. Exfiltration is a security word for data leaving your control, whether stolen by an outside attacker, leaked by a careless employee, or copied by a malicious insider. VPC Service Controls adds a layer of protection that works alongside IAM, not in place of it.

Think about how many ways data can leave a cloud project even when every permission looks correct. An attacker steals a service account key and calls a storage API from a laptop in another country. A developer, with legitimate access, copies a database into a bucket in a personal project. A misconfigured IAM policy accidentally makes a dataset readable by too many people. Google lists exactly these situations: access from unauthorized networks using stolen credentials, data theft by malicious insiders or compromised code, data exposed by misconfigured IAM policies, and copying data out of the perimeter through service operations such as copying to a public storage bucket.

What problem it solves that IAM cannot

IAM answers “who may do this?” It does not ask “from where?” or “to where?” A valid identity using a valid permission from anywhere on the internet is, from IAM’s point of view, simply allowed. VPC SC adds the missing questions about location and destination. It checks whether the request comes from inside an approved boundary and whether the data is being moved to somewhere approved.

Who needs it

Organizations holding data that must not leak: financial records, health information, personal data governed by privacy laws, intellectual property, and anything covered by contractual or regulatory promises. Smaller teams without such data can often manage with careful IAM alone, but the idea is valuable for anyone who wants a safety net against stolen credentials.

A short history of the problem

For years, cloud security advice focused on building a strong perimeter around your virtual networks. Firewalls, private subnets, and gateways protected machines. But as organizations adopted managed services, such as hosted storage and analytics warehouses, their most valuable data moved into places that are reached through public service interfaces, not through the machines on a private network. A stolen key could be used from anywhere to call those interfaces. The classic network perimeter no longer surrounded the data. VPC Service Controls was created to redraw a boundary around the data services themselves, using identity, network origin, and destination as the checks.

Why the name can confuse beginners

The words “VPC” and “service controls” suggest a network feature, yet the product is mostly about APIs and data. A VPC, or Virtual Private Cloud, is your private network inside Google Cloud. The perimeter can include VPC networks, but its main job is controlling access to Google service APIs. Keep this distinction in mind and many confusing documentation pages will read more easily.

The three jobs of a perimeter

It helps to think of the perimeter as doing three jobs. The first is shielding: stopping requests from the wrong place from reaching your data services. The second is containing: stopping data from being carried to the wrong place by someone or something inside. The third is recording: writing down every blocked or would-be blocked attempt so you can learn from it. When you evaluate a design, ask whether all three jobs are being done. A fence that shields but does not record leaves you blind, and a fence that records but does not contain only tells you about the theft after it happens.

Ten terms carry nearly the entire subject.

Perimeter versus firewall

A network firewall controls traffic between machines by address and port. A service perimeter controls access to Google-managed service APIs and the data behind them. They solve different problems. A firewall cannot stop an authorized user from copying a storage bucket to another project through the storage API, because that traffic goes to a Google service, not between your machines. A perimeter can.

What a perimeter does not cover

Per Google, perimeters cover Google-managed services only. They do not block third-party APIs or arbitrary internet services. A virtual machine inside a perimeter that can reach the internet can still send data to a website, unless you also control its network egress by other means. VPC SC is one layer in a set of defenses.

The role of Access Context Manager

Behind the scenes, perimeters and access levels are managed through a Google service called Access Context Manager. This is why command-line instructions and quota pages mention it. You may notice that its own limits apply in addition to those of VPC Service Controls. When you automate configuration, you are really calling Access Context Manager interfaces, so learn its name and look for its documentation as well.

Regular perimeters and bridges

Google describes a standard kind of perimeter and an older, special kind called a bridge, which connects two perimeters so projects can share data. Google recommends ingress and egress rules instead because they offer finer control. For new designs, prefer rules. For existing designs that use bridges, plan a gradual move to rules when time allows.

Principals and identities in rules

Rules refer to identities in several forms: individual users, service accounts, and groups. Prefer groups for people and dedicated service accounts for software. When someone changes jobs, you change group membership rather than editing perimeter rules, which keeps the rule set stable and the change history clean.

No single control is enough. The layers support each other.

Google states plainly that VPC Service Controls is not a replacement for IAM and recommends using both. It also controls data movement, not metadata, so metadata access should still be governed with IAM, including custom roles. The following diagram shows a request passing through several checks.

flowchart TD
  REQ["API request to a Google service"] --> AUTH{"Authenticated identity?"}
  AUTH -- "No" --> D1["Rejected"]
  AUTH -- "Yes" --> IAM{"IAM allows this action?"}
  IAM -- "No" --> D2["Rejected by IAM"]
  IAM -- "Yes" --> VPCSC{"Perimeter check: request source and destination allowed?"}
  VPCSC -- "No" --> D3["Rejected by VPC Service Controls"]
  VPCSC -- "Yes" --> OK["Request proceeds to the service"]
        

Read the diagram top to bottom. First the system confirms who is calling. Then IAM decides whether that identity may perform the action. Finally the perimeter checks whether the request crosses the boundary in a way that is not allowed. Only a request that passes all three reaches the service. This explains a common surprise: a request can be perfectly permitted by IAM and still be rejected, because the perimeter check is separate and independent.

The related controls Google suggests

• Domain-restricted sharing, which stops resources from being shared with identities outside approved domains.
• Uniform bucket-level access for storage, which simplifies and strengthens permissions.
• Multi-factor authentication for people.
• Post-deployment scans that check configuration after it is applied.
• Infrastructure-as-code reviews, so changes to perimeters are reviewed like software.

An everyday example of the layers

Imagine a data analyst, Asha, who has permission to read a customer dataset. Her laptop is stolen while she is signed in, and the thief tries to export the dataset to an outside bucket. IAM says Asha is allowed to read. The firewall does not see the request. The perimeter sees that the request comes from an unapproved network and that the destination is outside the fence, so it blocks it and writes a violation to the log. Each layer saw a different piece of the picture, and only the combination stopped the theft.

Why layered defense survives mistakes

People make mistakes: they grant too much access, forget to rotate a key, or leave a bucket open. A single control means one mistake equals one breach. Layers turn single mistakes into near misses. A permission mistake meets the perimeter and is blocked. A perimeter mistake meets IAM and is limited. Detection catches whatever slips through both. Over years, this redundancy is what keeps ordinary human error from becoming a headline.

A perimeter is a short list of choices. Understanding each choice makes the rest easy.

According to Google’s creation steps, a perimeter is defined by a name and a handful of settings. First, the resources inside it: projects, or VPC networks (selected through the project that contains them). Second, the restricted services: the Google services the perimeter protects. Third, optionally, the VPC accessible services: which services may be reached from inside the perimeter’s networks. Fourth, optionally, access levels, ingress policy, and egress policy.

flowchart TD
  subgraph PERIM["Service Perimeter"]
    P1["Project A: data lake"]
    P2["Project B: analytics"]
    S1["Restricted services: storage, analytics"]
  end
  OUT["Client outside the perimeter"] -->|"Blocked by default"| PERIM
  P1 |"Free communication"| P2
  OUT2["Approved client"] -->|"Ingress rule or access level"| PERIM
  P1 -->|"Egress rule"| EXT["Approved destination outside"]
        

Inside the box, projects communicate freely with each other. Across the boundary, access to restricted services is blocked by default. Two kinds of exceptions open controlled gaps: ingress rules and access levels for traffic coming in, and egress rules for traffic going out.

Resource format cautions

Google’s guidance for creating perimeters says to refer to projects by their project number, not by name or readable ID. A project number is a long numeric identifier assigned by Google. Using the wrong form is a classic cause of failed configuration.

Naming rules

Perimeter names can be up to 50 characters, must start with a letter, may contain only ASCII letters, numbers, or underscores, are case sensitive, and must be unique within the access policy. Pick names that tell the reader the purpose, such as “prod_data_lake” or “finance_analytics”.

Accessible services must also be restricted

Google notes that a service can be made accessible inside the perimeter only if it is also restricted. This surprises people, so remember it: the “VPC accessible services” setting narrows which restricted services machines inside the perimeter’s networks may call. It cannot add services that the perimeter does not already protect.

Choosing what goes inside

Put projects inside a perimeter when they hold data you cannot afford to lose control of, or when they process that data. Leave outside the projects that mostly host public content or experiments. Avoid mixing sensitive and non-sensitive workloads in one project, because a project is the unit you place inside a perimeter. A clean project structure makes perimeters simpler. If projects are already mixed, consider splitting them as part of the rollout.

Planning for growth

Organizations create new projects constantly. Decide in advance how a new project joins a perimeter: through a template that adds it automatically, or through a request process. A perimeter that new sensitive projects forget to join is a fence with a hole that grows over time.

Testing the boundary

Once a perimeter exists, deliberately test it from both sides with harmless requests. Try to read a protected object from a project outside, and try to write one into the perimeter. Confirm the results match your design. These small, repeatable tests become part of your acceptance checks whenever the configuration changes.

The policy is the folder that holds everything. Access levels are the reusable “who is trusted” definitions.

Access policies and their scope

An access policy holds your perimeters and access levels. Google’s creation steps explain that the policy’s scope must include every project and VPC network you want to add to a perimeter. The scope can be the entire organization, a folder, or a project. The quotas page states that an organization can have one organization-level access policy and up to 50 folder- and project-scoped policies.

Scoped policies are valuable in large companies. Instead of one central team controlling every perimeter, a department can administer its own folder’s policy. Google lists delegated administration among the benefits, along with organization-wide policies.

Access levels

An access level describes conditions under which a request from outside is considered trusted. Conditions can include network address ranges, device attributes, and user or group identity. Google says access levels can allow internet access based on IP range, device, or user. Think of them as named, reusable passes: “corporate office network”, “managed laptops”, “security team members”.

Access levels versus ingress rules

Both let outside traffic in. Access levels are coarse: if you meet the level, you can reach the restricted services in the perimeter. Ingress rules are fine-grained: they can say which identities, from which sources, may call which methods on which services and projects. Google recommends using ingress and egress rules over the older perimeter bridges because of that finer control.

Choosing the right scope

Organization-wide policies give central control and consistency, which suits companies with a strong security team. Folder or project-scoped policies suit large companies with autonomous business units, or companies that want to try the feature in one department first. A common route is to start with a scoped policy for a pilot department, learn, and later decide whether to centralize. Remember that the organization allows only one organization-level policy, so decide carefully who owns it.

Keeping access levels healthy

Access levels decay silently. Office addresses change, groups grow, and devices are replaced. Assign each access level an owner and review it on a schedule. When an address range is no longer used, remove it, because an unused range owned by someone else tomorrow becomes a doorway into your data.

The controlled doors in your fence.

By default a perimeter blocks communication across its boundary to supported services. Real systems need some crossing: a partner uploads files, an analytics project outside reads one dataset, a pipeline inside copies results to an approved archive. Ingress and egress rules make these crossings explicit.

flowchart TD
  R["Request crosses perimeter boundary"] --> Q1{"Direction?"}
  Q1 -- "Inward" --> I1{"Matches an access level or ingress rule?"}
  I1 -- "Yes" --> A1["Allowed"]
  I1 -- "No" --> B1["Blocked and logged as violation"]
  Q1 -- "Outward" --> E1{"Matches an egress rule?"}
  E1 -- "Yes" --> A2["Allowed"]
  E1 -- "No" --> B2["Blocked and logged as violation"]
        

The diagram shows the simple logic. Every crossing is either inward or outward. If there is a rule that matches the request’s details, it passes. If not, it is blocked and recorded. This makes the default safe: forgetting to write a rule leads to a visible, logged denial, not a silent leak.

What a good rule describes

• Who: the specific identities or identity types allowed.
• From where or to where: the sources or destinations, such as particular projects.
• Which service and method: only the exact operations needed, such as reading objects but not deleting them.
• A clear title: a human-readable explanation of why the rule exists, which helps later reviews.

Rule limits

The quotas page states that each perimeter configuration may hold up to 6,000 attributes across its ingress and egress rules, counting projects, networks, access levels, method selectors, identities, roles, and wildcards. It also notes a limit of 1,000 identity groups in ingress and egress rules per policy. Large rule sets therefore need discipline: use groups where possible and avoid sprawling lists of individual identities.

Reading a rule like a sentence

A helpful habit is to read every rule aloud as a plain sentence. For example: “The analytics service account from project Alpha may read objects from the storage service in project Beta.” If you cannot say the rule in a clear sentence, it is probably too vague. If the sentence sounds alarming, such as “any identity may do anything to anything”, the rule is too broad. Teams that insist on sentence-form summaries in their review process catch most problems before they reach production.

Rules for automated systems

Pipelines, schedulers, and deployment tools are the most common sources of crossing traffic. They run as service accounts, often across many projects. When writing their rules, list the exact service accounts and the exact projects, and prefer separate service accounts for separate jobs. A single shared account used by many pipelines forces you to grant the union of everything they need.

Testing rules before trusting them

After writing a rule, test both directions: confirm that the intended client can do the intended action, and confirm that a similar but unintended client cannot. For example, a rule allowing one service account to read one bucket should still block a different service account, and should still block the same account from deleting objects. Tests like these catch rules that are accidentally broader than their authors intended.

How machines inside your network reach Google services without wandering through the open internet.

By default, virtual machines call Google service APIs using public addresses. For protected environments, you want those calls to stay on Google’s network and to reach only services that support perimeter checks. Google describes the restricted VIP, the name restricted.googleapis.com, as providing private access to supported services without internet exposure. A VIP, short for virtual IP address, is a special address that stands for a group of servers.

The role of DNS

Machines find service addresses through DNS, the internet’s phone book. To use the restricted VIP, you configure your network’s DNS so that the names of Google APIs resolve to the restricted addresses. Then API calls from inside your network travel the private path. Without this step, calls may take the ordinary route, and your protection depends only on what the perimeter checks at the service side.

Why it matters

• It keeps traffic off the public internet, reducing exposure.
• It limits reachable services to those that support the perimeter model, so an attacker inside cannot reach unprotected Google APIs and use them as an exit path.
• It works alongside the perimeter’s own checks, adding network-level discipline.

Hybrid environments

Companies with on-premises data centers often connect to Google Cloud through private links. Their on-premises machines can also use private access to Google services through those links, with DNS arranged to use the restricted addresses. Plan this early, because many surprises come from on-premises tools calling services through paths that the perimeter does not expect.

Developers working from home

Once a perimeter is enforced, a developer on a home network may be unable to use the console or command line against protected services. Solutions include access levels for managed devices and approved user groups, a company VPN with fixed exit addresses, or remote workstations that live inside the environment. Choose one approach and document it, because ad hoc exceptions for individuals multiply quickly and are hard to review.

Keeping the internet exit controlled

Remember that machines inside a perimeter might still send data to arbitrary internet sites. Combine the perimeter with controls on outbound network traffic, such as egress firewall rules or proxies for sensitive environments. The perimeter protects Google services; other tools must protect the rest of the exit paths.

The single most important feature for a safe rollout.

Google describes two modes. In enforced mode, the perimeter actively blocks access to protected services that violates its rules. In dry run mode, it logs violations as if the services were protected, but does not block anything. Dry run lets you see exactly which requests would have been denied, so you can write the right rules before any real traffic is affected.

flowchart TD
  A["Design perimeter: projects and services"] --> B["Create it in dry run mode"]
  B --> C["Collect violation logs for days or weeks"]
  C --> D{"Violations are legitimate traffic?"}
  D -- "Yes" --> E["Write narrow ingress or egress rules"]
  E --> C
  D -- "No, they are real threats" --> F["Leave blocked, investigate"]
  F --> G{"Logs clean for a full business cycle?"}
  G -- "No" --> C
  G -- "Yes" --> H["Switch to enforced mode"]
  H --> I["Monitor closely, keep rollback ready"]
        

The loop repeats until the logs show only violations you are happy to block. A full business cycle matters, because some jobs run only monthly or quarterly, such as financial close or annual reporting. Enforcing after only a quiet weekend of logs is a classic mistake that breaks the quarterly job six weeks later.

What to look for in dry run logs

How long should dry run last?

There is no universal number. The principle is to cover every important rhythm of the business: daily, weekly, monthly, quarterly, and yearly where possible. Many teams settle on a minimum of several weeks for general workloads, and a full quarter for projects tied to financial or regulatory cycles. If a yearly job exists, record it explicitly and test it in dry run through a scheduled run or a manual trigger, instead of waiting a year.

Communicating with teams

Tell application owners what is happening before enforcement. Share the list of violations that involve their systems, ask them to confirm which are legitimate, and give a date. Surprise is the enemy of security programs. Teams that feel informed become allies, and teams that feel ambushed look for ways around the controls.

Dry run is not a substitute for thinking

Dry run shows what happened during the observation window. It cannot show traffic that did not occur during that window, and it cannot tell you whether a flow is acceptable. A human must decide, for each observed violation, whether it is a legitimate need or a risk. Treat the logs as evidence for a discussion, not as an automatic rule generator.

The conceptual steps, in the order you will perform them.

Google describes creation in the console, in the command line, and through the programming interface. The console flow gives a good picture of the decisions, so here is its outline in plain language. Roles and prerequisites are documented in the “before you begin” section of the official page, so confirm them there.

The thirty-minute rule

During propagation, requests may fail with an error message stating that the request is prohibited by the organization’s policy. This confuses people who make a change, test immediately, and conclude that the change is wrong. Wait, test again, and only then investigate. Plan changes in maintenance windows and allow the delay in your runbooks.

Infrastructure as code

Perimeters are security-critical configuration. Treat them as code: store the definition in version control, require peer review for changes, and apply through automation. Google lists infrastructure-as-code reviews among recommended practices. This gives every change an author, a reviewer, a reason, and a rollback path.

Rollback thinking

Before enforcing any change, decide how you would undo it. The simplest rollback is switching the perimeter back to dry run or removing a resource from it, accepting the thirty-minute delay. Write the steps down and name the person with authority to execute them at night. A rollback plan that exists only in someone’s memory fails when that person is on holiday.

Testing after enforcement

After enforcement, run a set of tests that prove both sides: that legitimate flows still work and that forbidden flows are blocked. For example, confirm that the nightly pipeline completes, and also confirm that copying a protected dataset into an outside project fails. A security control that has never been seen to block anything has not been proven to work.

Documentation that helps at 3 a.m.

Write a short runbook for each perimeter. Include its purpose, the projects inside it, the owner, the list of rules with their reasons, the break-glass procedure, and the first three things to check when something is denied. Store it where on-call staff can find it quickly. Keeping this document current is part of the cost of running the feature, and it pays back the first time a late-night denial blocks an important job.

Not everything can sit inside a perimeter, and not every combination works smoothly.

Google maintains a list of supported products, and states that only services on that list should be included in a perimeter. Unsupported services should run in projects outside the perimeter, and access levels can let them reach perimeter data. Attempting to restrict an unsupported service returns an error. Google also warns that unsupported services may fail in protected projects, and that cross-project access to data of supported services is blocked unless allowed by rules.

Building your compatibility map

Before drawing any perimeter, list every Google service your applications use, including indirect ones such as logging, monitoring, container registries, and build services. Mark each as supported or unsupported, and note special instructions from the documentation. This map reveals which projects can be moved inside easily, which need exceptions, and which should stay outside.

Keeping up with product change

The list of supported products and their behaviors grows and changes. A service that was unsupported last year may be supported today, and new features may bring new interactions. Assign someone to review release notes regularly and to re-run your compatibility map each quarter. This small habit prevents the situation where an upgrade or a new feature quietly bypasses or breaks your assumptions.

Dealing with Google-managed flows

Some Google services call other Google services on your behalf, for example when a managed pipeline reads from storage and writes to an analytics store. These flows may appear in violation logs under identities you did not create. Read the documentation for each such service to learn which identities and projects it uses, and write rules for them carefully. Never allow a broad class of Google-owned identities without understanding why.

Know the ceilings before you design, not after you hit them.

The following numbers come from Google’s quotas and limits page as retrieved for this guide. They apply separately to each enforced and dry-run configuration where the page says so, and they can change, so check the current page.

Reading the limits wisely

Google notes that quota usage adds enforced and dry-run counts together, and that each entry is counted even if it appears elsewhere in the policy. Resources referenced only in ingress or egress policies do not count as protected resources, and resources should be added in batches of 10,000 or fewer. The access context services also impose their own limits. The page does not state a maximum number of access levels or of rules per perimeter; the limits are attribute-based.

Staying within bounds

• Use identity groups in rules instead of long lists of individual accounts.
• Keep rule titles short but meaningful, since total title length is also limited.
• Use scoped policies to split a very large organization into manageable pieces.
• Remove obsolete rules regularly, so that old attributes do not eat your allowance.

An example of sizing

Suppose a company has 300 projects, of which 120 hold sensitive data. It plans four domain perimeters containing roughly thirty projects each. This sits far below the protected resource limit of 40,000 for an access policy. The binding constraint will more likely be rule complexity: if each perimeter needs hundreds of identities and projects across its ingress and egress rules, the attribute allowance of 6,000 can be approached. Planning with groups and shared service accounts keeps you comfortably inside.

Monitoring your usage of limits

Track how close you are to each limit and set a reminder to review before reaching eighty percent. Hitting a ceiling in the middle of an urgent change is a stressful way to learn about it. Plan clean-ups and policy splits well ahead of time.

When something is blocked, you need to know what, who, and why, quickly.

Google lists audit logging among the benefits of VPC SC, so you can monitor access patterns. A blocked request produces a log entry describing the violation. Google also publishes tools for diagnosis: search results show a troubleshooter, a violation analyzer, and a unique identifier attached to each denial that helps you find the exact cause. Because the documentation pages for those tools could not be read in full while preparing this guide, treat the specifics below as a method and check the tools’ pages for exact steps.

sequenceDiagram
  participant User as Developer or application
  participant Svc as Google service API
  participant VPCSC as Perimeter check
  participant Log as Audit logs
  participant Admin as Administrator
  User->>Svc: Request
  Svc->>VPCSC: Evaluate source, identity, destination
  VPCSC-->>User: Denied with error and identifier
  VPCSC->>Log: Record violation details
  User->>Admin: Report error and identifier
  Admin->>Log: Search by identifier
  Log-->>Admin: Which rule was missing and why
  Admin->>VPCSC: Add narrow rule in dry run, then enforce
        

The sequence shows a healthy troubleshooting habit. The user reports the error message and its identifier. The administrator searches the logs by that identifier to find the exact violation: who called, from where, to what. From that, the administrator decides whether it is legitimate and writes the smallest rule that allows it, testing in dry run first.

A diagnosis checklist

Building a violation dashboard

Create a simple view of denied requests by day, by perimeter, by identity, and by destination. Look for three patterns: a sudden spike, which may indicate an attack or a broken deployment; a steady background of the same denials, which signals a rule that should be written or a client that should be fixed; and rare, strange denials involving unknown identities, which deserve immediate investigation. A dashboard makes these patterns obvious at a glance.

Playbook for a suspected attack

If violations suggest an attacker, act in a set order. Preserve the logs. Identify the identity involved and disable or rotate its credentials. Check what else that identity can reach. Review recent changes to perimeters in case the attacker tried to widen the fence. Inform the incident response team. Only after containment should you work on long-term fixes.

Handling noisy denials

Some clients retry blocked requests repeatedly, generating thousands of identical log entries from a single misconfigured job. Identify the source and fix it, either by writing the rule if legitimate or by repairing the client if not. Leaving noise unattended hides real alerts and inflates log costs. Aim for a steady state in which almost every denial in the logs is interesting.

Whoever can edit the fence can open it. Protect the fence’s controls.

Perimeters are powerful, so permissions to change them must be tightly held. A person who can edit a perimeter could add their own project to an egress rule and copy data out. Treat perimeter administration as a privileged function, comparable to administering identities.

Separation of duties

Delegated administration

Google lists delegated administration among benefits, through scoped access policies for folders and projects. A business unit can manage its own perimeters within its scope while the central team governs the organization-level policy. Define clearly which decisions are local and which are central, so that a local team cannot accidentally weaken company-wide guarantees.

Exception process

Every rule that opens the fence is an exception. Record each with an owner, a business reason, an approving person, and a review date. Send reminders at review time and remove rules that are no longer needed. Over time, an unmanaged list of exceptions turns a strict perimeter into a sieve.

Reviews and attestations

Hold a recurring review in which each rule owner confirms that their rule is still needed and still correct. Record the confirmation. Rules that cannot be confirmed within an agreed time move to a disabled state for observation, and are removed if nobody objects. This keeps the fence from slowly turning into a collection of forgotten exceptions.

Evidence for auditors

Auditors like clear evidence. Keep exports of perimeter configurations at regular intervals, the history of approved changes, the violation logs, and records of exception reviews. Together these show that the control exists, that it was changed carefully, and that it was watched. Preparing this package in advance turns audit season from a scramble into a routine hand-over.

Shapes that appear again and again in real organizations.

One perimeter per sensitivity zone

The simplest design draws one perimeter around all production projects that hold sensitive data, and another around everything else. It is easy to explain and audit. Its weakness is size: a single huge perimeter can become hard to change, because any adjustment affects many teams.

Perimeter per business domain

Each domain, such as finance, marketing, or operations, gets its own perimeter. Communication across domains is explicit through ingress and egress rules. This mirrors organizational ownership and limits the blast radius of mistakes, but it requires more rules and coordination.

Shared services outside, workloads inside

Common utilities, such as logging projects, container registries, or shared networking, sometimes sit outside perimeters so that many perimeters can use them. Narrow rules allow workloads to reach the shared services and no further. Take extra care to protect the shared projects themselves, since they now connect many zones.

flowchart LR
  subgraph FIN["Perimeter: Finance"]
    F1["Finance data projects"]
  end
  subgraph MKT["Perimeter: Marketing"]
    M1["Marketing analytics projects"]
  end
  subgraph SHR["Shared services (outside or own perimeter)"]
    S1["Logging and registries"]
  end
  F1 -->|"Egress rule: logs only"| S1
  M1 -->|"Egress rule: logs only"| S1
  F1 -->|"Egress rule: approved summary tables"| M1
  EXT["Partner"] -->|"Ingress rule: one dataset, one identity"| M1
        

Each arrow in the diagram corresponds to one reviewed rule. Notice how little crosses the boundaries: logs go to shared services, summary tables go from finance to marketing, and one partner identity reaches one dataset. The picture of the architecture is also the list of exceptions, which makes reviews straightforward.

Hybrid and partner access

When on-premises systems or partners need access, prefer identity-based ingress rules that name the specific service accounts or groups, combined with access levels for trusted networks, over broad network-only exceptions. Identity-based rules remain valid when network addresses change.

Evolving the architecture over time

No first design is final. Start with something simple, learn from logs and incidents, and refine. It is common to begin with a single perimeter, discover that one team needs very different rules, and then split. Plan for change by keeping configuration as code, keeping names meaningful, and keeping documentation current. Architecture that can change safely is worth more than architecture that looks perfect on the first day.

Checklist for any new architecture

• Every sensitive project is inside exactly one perimeter, and the owner is named.
• Every crossing is drawn as an arrow with a reason, and each arrow has a matching reviewed rule.
• Shared services are protected as carefully as the workloads that use them.
• Unsupported services are identified and isolated in projects outside the fence.
• Monitoring, break-glass access, and rollback steps are written down and tested.

The bill is not always the biggest cost.

The pages reviewed for this guide describe features and limits but do not state a separate price for VPC Service Controls. Pricing details can differ by account and change over time, so confirm on Google’s pricing pages or with your account team whether any charge applies. What is certain is that the real cost lies in effort: design time, rule writing, troubleshooting, and the ongoing review of exceptions.

Where the effort goes

Hidden costs

• Log volume from violations can grow quickly during dry run, which affects log storage costs.
• Moving unsupported services into separate projects may require redesigning applications.
• Training for engineers who have never seen a denial that IAM does not explain.

Justifying the effort to leaders

Leaders ask what risk the effort removes. Frame the answer in terms of scenarios: a stolen key, an insider copy, a misconfigured permission. For each, explain what happens with and without the perimeter. Add the cost of a breach in your sector, including fines, notification, and lost trust. Compare that with the modest, mostly human cost of running the controls. Concrete scenarios persuade better than abstract security language.

An honest balance sheet.

The central trade-off

Strict perimeters lower the risk of data leaving but raise the friction of everyday work. Loose perimeters keep teams moving but weaken the protection. The right point depends on the value of the data and the maturity of your processes. Many organizations start loose on less sensitive data and strict on the crown jewels, then tighten gradually.

Questions to ask before committing

• Which datasets would hurt us most if they left our control, and are they in supported services?
• Do we have the staff to run dry run reviews and exception processes?
• How will developers and partners reach the protected data after enforcement?
• What other controls cover non-Google destinations, such as the open internet?
• How will we know the perimeter is working, beyond the absence of incidents?

Who should lead the program?

A successful program has a clear owner, usually in the security or platform team, with a named sponsor among leadership. Application teams participate as partners, supplying knowledge of their systems. Without an owner, the work stalls at the first inconvenient outage. Without partners, the owner writes rules that break real work.

Reusable ways of applying perimeters.

Pattern: dry run as standard practice

Make dry run a required step for every change. Any new rule or perimeter first appears in dry run, spends an agreed period collecting evidence, and is then promoted. Teams that follow this pattern rarely cause outages with security changes.

Pattern: break-glass access

Prepare a documented, tightly controlled emergency route for administrators to regain access if a mistake locks everyone out. Test it in a safe environment, restrict who may use it, and alert whenever it is used.

Pattern: golden path for new projects

Provide a template that creates a new project with the right labels, logging, identity groups, and perimeter membership already applied. Teams that follow the golden path get protection automatically and fast onboarding. Teams that step outside it must justify why. This turns security from a gate into a convenience.

Mistakes that cause outages or false confidence.

Warning signs of drift

Watch for these signals: exceptions that outnumber the perimeters, rules without owners, teams asking to “just turn it off”, violation logs that nobody reads, and projects created outside the standard process. Each is a sign that the program is losing grip. Address them early with a short cleanup and a refreshed conversation about why the controls exist.

A realistic path from zero to enforced perimeters.

Best practices

Common mistakes

• Enforcing after only a short quiet period and breaking monthly or quarterly jobs.
• Using project names or IDs instead of project numbers in configuration.
• Forgetting the thirty-minute propagation delay when testing.
• Not planning for on-premises tools and developer laptops.
• Forgetting that dry run and enforced configurations both count against quotas.

Training the people

Prepare a short guide explaining what a perimeter denial looks like, whom to contact, and what information to include in a request. Run a brief session for developers and support staff. A well-informed help desk resolves most issues in minutes, whereas an uninformed one passes every denial to the security team and creates delay and resentment.

Measuring success

Track a few numbers: percentage of sensitive projects inside perimeters, number of active exceptions and their average age, time to resolve a legitimate denial, and number of violations investigated. If exceptions only grow and resolution times only lengthen, the program needs attention. If sensitive coverage rises while friction falls, you are succeeding.

Handling resistance

Some teams will resist, fearing outages and delays. Listen to the specific fears and address them: show the dry run results for their systems, promise a fast path for urgent exceptions, and name a contact who answers quickly. Resistance often fades when people see that the program takes their work seriously, and when the first few exception requests are handled in hours, not weeks.

Stories that show the ideas under pressure.

Lessons that repeat

Across these stories, the same truths appear. Evidence beats guesses. Narrow rules beat broad ones. Ownership and expiry keep exceptions honest. And a perimeter that has been seen to block something is worth far more than one that has never been tested.

Quick answers to common questions.

It creates security perimeters around Google Cloud managed services to reduce the risk of data exfiltration, working alongside IAM.

No. Google recommends using both. IAM decides who may act; the perimeter adds checks on where requests come from and where data may go.

No. It covers Google-managed services only and does not block third-party APIs or arbitrary internet services.

A mode that logs violations as if the services were protected but does not block access, so you can test a perimeter’s impact before enforcing it.

Google says perimeter changes can take up to thirty minutes to take effect. During that time requests may fail with a policy error.

Ingress rules allow clients outside the perimeter to reach resources inside. Egress rules allow clients or resources inside to reach resources outside.

Not necessarily. Google notes a VPC network is not required, and access can also be allowed based on external address ranges or IAM principals.

Google’s documentation recommends ingress and egress rules instead, because they offer finer control.

Examples from Google’s quotas page: 6,000 attributes across a perimeter’s rules, 10,000 perimeters and 40,000 protected resources per access policy, and one organization-level access policy with up to 50 scoped policies. Check the current page.

Only those on Google’s supported products list. Attempting to restrict an unsupported service returns an error.

Google states it is designed to control data movement, not metadata. Use IAM, including custom roles, for metadata access control.

Identify your most sensitive data, map the services and identities that touch it, create a perimeter in dry run, collect evidence for a full business cycle, write narrow rules, and then enforce.

Yes, if the destination project is outside the perimeter and no egress rule allows the copy. The attempt is blocked and logged as a violation.

Write a narrow ingress rule naming the partner’s specific identity, the exact project and service, and only the methods required, and give it an owner and an expiry date.

VPC Service Controls draws a fence around Google-managed services so that data stays where you intend, even when credentials are stolen or permissions are misconfigured. It works as a second layer beside IAM, adding checks on where requests come from and where data may go. Its strength depends on discipline: test in dry run, write narrow rules, govern exceptions, watch the logs, and keep the surrounding layers strong.