This document describes recommended VPC Service Controls deployment architectures.This document is for network administrators, security architects, and cloudoperations professionals who run and operate large, production scale deploymentson Google Cloud and who want to mitigate the risk of sensitive data loss.

Because VPC Service Controls protection affects cloud servicesfunctionality, we recommend that you plan the enablement ofVPC Service Controls in advance, and consider VPC Service Controlsduring architecture design. It's important to keep VPC Service Controlsdesign as simple as possible. We recommend that you avoid perimeter designs thatuse multiple bridges, perimeter network projects or aDMZ perimeter,and complex access levels.

Use a common unified perimeter

A single large perimeter, referred to as acommon unified perimeter, providesthe most effective protection against data exfiltration compared to usingmultiple, segmented perimeters.

A common unified perimeter also provides the benefit of lower managementoverhead for the teams responsible for perimeter creation and maintenance.Since services and network resources within a perimeter can communicate freelywith the necessary IAM and network controls permissions, theteams responsible for perimeter management will primarily be concerned withnorth-south access, which is access from the internet to resources inside theperimeter.

When an organization uses multiple smaller perimeters, perimeter managementteams must devote resources to managing east-west traffic between anorganization's perimeters in addition to north-south traffic from outside theorganization. Depending on the size of the organization and the number ofperimeters, this overhead can be considerable. We recommend that you layer yourperimeter with additional security controls and best practices, such as ensuringthat resources within the VPC network don't have direct internet egress.

Service perimeters aren't intended to replace or reduce the need forIAM controls. When you are defining access controls, we recommendthat you ensure that the principle of least privilege is followed andIAM best practices are applied.

For more information, seeCreating a serviceperimeter.

Use multiple perimeters in one organization

Certain use cases might require multiple perimeters for an organization. Forexample, an organization that handles healthcare data might want one perimeterfor high-trust, non-obfuscated data and a separate perimeter for lower-tier,de-identified data to facilitate sharing with external entities while stillprotecting the high-trust data.

If your organization wants to comply with standards such asPCI DSS, youmight want to have a separate perimeter around your regulated data.

When data sharing is a primary use case for your organization, consider usingmore than one perimeter. If you produce and share lower-tier data likede-identified patient health data, you can use a separate perimeter tofacilitate sharing with outside entities. For more information, see referencepatterns forsecure data exchange.

Additionally, if you use your Google Cloud organization to host independent,third-party tenants such as partners or customers, consider defining aperimeter for each tenant. If you consider data movement from from one of thesetenants to another to be exfiltration, we recommend that you implement aseparate perimeter.

Perimeter design

We recommend that you enable all protected services when you create a perimeter,which helps reduce operational complexity and minimize potential exfiltrationvectors. Because leaving APIs unprotected increases possible exfiltration vectors,there should be reviews and justifications if your organization opts to protectone API and not another.

All new projects should go through thereview and qualification process that isdescribed in the following sections. Include in the perimeter all the projectsthat pass the qualification conditions.

Make sure that there isn't a path to the private VIP from any of the VPCs inthe perimeter. If you allow a network route toprivate.googleapis.com, younegate VPC Service Controls protection from insider data exfiltration. Ifyou must allow access to a non-supported service, try to isolate the use ofunsupported services into a separate project, or move the entire workload outsidethe perimeter.

Review and qualify projects

A typical enterprise has many projects that represent workloads and high-levelconstructs such as control planes, data lakes, business units, and lifecyclestages. In addition to organizing these projects and components into folders,we recommend that you qualify them to be inside or outside of aVPC Service Controls perimeter. To make the qualification, consider thefollowing questions:

• Is there a component that has a hard dependency on aservice that VPC Service Controls doesn't support?

  VPC Service Controls enforcement is unambiguous, so this type ofdependency might not function in a perimeter. We recommend that you modifythe workload to isolate the requirement for unsupported services into aseparate project, or move the workload out of the perimeter altogether.

• Does the project contain only components that have no sensitive data anddon't consume sensitive data from other projects?

If you answered yes to any of the preceding questions, we recommend that youdon't put the project into a perimeter. You can work around this, as discussedin theAllowlist design topic. However, we recommend that you minimize perimeter complexity.

What's next

• Learn how tocreate a service perimeter.
• Learn how to test the impact of a perimeter using thedry run mode.
• Learn aboutingress and egress rules that enablecommunication between service perimeters.