Securing communications and establishing boundary protection · Topic 3 of 4
VPC Segmentation, N-Tier Isolation and VPC Service Controls
Segment Google Cloud networks with VPC design, peering, Shared VPC and firewall rules, isolate N-tier apps, and stop exfiltration with VPC SC.
- 6 min
- Firewall rules segment packets; VPC Service Controls segments access to Google APIs.
- Peering is non-transitive and needs non-overlapping ranges; Shared VPC centralises network control.
- Give each tier its own service account and write firewall rules between service accounts.
What it is
Segmentation limits how far an attacker can move after one system is compromised. On Google Cloud there are two kinds of boundary: network boundaries (VPC networks, subnets, firewall rules) that control packets between workloads, and service perimeters from VPC Service Controls that control access to Google APIs such as Cloud Storage and BigQuery.
How it works
Security properties of a VPC network
A VPC network is global; its subnets are regional. Traffic between VMs in the same network is allowed only if firewall rules allow it, and the implied rule denies all ingress.
| Property | Secure practice |
|---|---|
| Default network | Do not use it; it opens SSH, RDP and ICMP from anywhere. Block it with compute.skipDefaultNetworkCreation |
| Subnet design | Custom mode with planned, non-overlapping ranges per tier and region |
| Firewall | Deny by default, allow specific flows between service accounts or secure tags |
| Logging | Flow logs and firewall rule logging where you need evidence |
VPC peering and Shared VPC
| Feature | What it gives | Security properties |
|---|---|---|
| VPC Network Peering | Private routing between two VPC networks, even in different organizations | Not transitive; ranges must not overlap; each side keeps its own firewall rules and admins |
| Shared VPC | One host project's network used by many service projects | Central team owns subnets, routes and firewall; app teams only create resources in subnets they are given |
Shared VPC roles: Shared VPC Admin (roles/compute.xpnAdmin) on the organization or folder links host and service projects. Compute Network User (roles/compute.networkUser) on specific subnets lets service project teams use only those subnets. Organization policies compute.restrictSharedVpcHostProjects and compute.restrictSharedVpcSubnetworks limit what can be attached.
When a question stresses central control of networking with separate teams owning their own projects, the answer is Shared VPC. When two independent networks just need to talk privately, it is peering.
Isolating an N-tier application
| Tier | Placement | Allowed in |
|---|---|---|
| Web | Behind an external Application Load Balancer; no external IPs | Load balancer and health check ranges only |
| App | Separate subnet, behind an internal load balancer | Only from the web tier service account |
| Data | Cloud SQL on private IP, or database VMs in their own subnet | Only from the app tier service account on the database port |
Each tier has its own service account, so firewall rules follow identity rather than addresses. For stronger isolation, put tiers in separate projects or networks and connect them with Private Service Connect.
For encapsulation and encryption between tiers, Google already encrypts traffic in transit at several layers of its network. When you must control encryption end to end, use TLS or mutual TLS between tiers, for example with Cloud Service Mesh and certificates from Certificate Authority Service.
VPC Service Controls
VPC Service Controls draws a service perimeter around projects and the Google services you list as restricted. Requests to those services from outside the perimeter are blocked, even with valid IAM credentials, and data cannot be copied to resources outside it.
| Building block | Purpose |
|---|---|
| Perimeter | Projects (and VPC networks) inside; restricted services such as storage.googleapis.com, bigquery.googleapis.com |
| Access levels | Allow requests from trusted context, such as corporate IP ranges |
| Ingress rules | Allow specific outside identities or sources to call specific services and methods inside |
| Egress rules | Allow specific inside identities to reach specific outside projects or services |
| Dry run mode | Logs what would be blocked, without blocking |
| VPC accessible services | Limits which services can be called from networks inside the perimeter |
gcloud access-context-manager perimeters create analytics_perimeter \
--title="Analytics" --policy=POLICY_ID \
--resources=projects/111111111111,projects/222222222222 \
--restricted-services=bigquery.googleapis.com,storage.googleapis.com- ingressFrom:
identities:
- serviceAccount:loader@partner-etl.iam.gserviceaccount.com
sources:
- resource: projects/333333333333
ingressTo:
operations:
- serviceName: storage.googleapis.com
methodSelectors:
- method: "*"
resources:
- projects/111111111111Blocked calls return an error that the request is prohibited by the organization's policy, with a unique identifier you can find in the Policy Denied audit logs.
A worked example
A health company stores patient data in BigQuery and Cloud Storage. It fears that a stolen analyst credential could copy tables to a personal project.
The engineer creates a perimeter around the three data projects with BigQuery and Cloud Storage restricted, first in dry run. Logs show one partner ETL job outside the perimeter, so an ingress rule allows only its service account to call Cloud Storage in the one data project it loads. The perimeter is then enforced.
How the exam asks about this
- "Prevent data in BigQuery from being copied to projects outside the company, even by users with valid credentials." A VPC Service Controls perimeter with BigQuery as a restricted service.
- "A central network team must control subnets and firewall rules, while application teams manage their own VMs in separate projects." Shared VPC with Network User granted on specific subnets.
- "The app tier must accept traffic only from the web tier." A firewall rule with the web tier's service account as source and the app tier's as target.
What to remember for the exam
- Firewall rules segment packets; VPC Service Controls segments access to Google APIs.
- Peering is non-transitive and needs non-overlapping ranges; Shared VPC centralises network control.
- Give each tier its own service account and write firewall rules between service accounts.
- Perimeters block outside access and copying out even with valid IAM; IAM still applies inside.
- Roll out perimeters in dry run, then add precise ingress and egress rules.
VPC Service Controls is not a replacement for IAM. A user inside the perimeter still needs IAM permissions, and a perimeter with broad access levels or wide ingress rules protects little.
Common mistakes
Using firewall rules to stop data exfiltration to Cloud Storage. Google APIs are reached through Google's endpoints, not your VPC's packets alone. Use VPC Service Controls.
Expecting peering to be transitive. If A peers with B and B with C, A cannot reach C through B. Use a hub design with Network Connectivity Center or Private Service Connect.
Enforcing a perimeter without dry run. Pipelines and partner access break at once. Run dry run, read the violations, then add rules.
Check yourself
What does VPC Service Controls protect that firewall rules cannot?
Access to Google-managed APIs such as BigQuery and Cloud Storage, blocking requests and data copies across the perimeter even with valid credentials.
Which role lets a service project team use only one subnet of a Shared VPC?
Compute Network User granted on that specific subnet.
How do you let one outside service account load data into a bucket inside a perimeter?
Add an ingress rule naming that identity, the Cloud Storage service and the target project.
Topic 3 of 4 in Securing communications and establishing boundary protection
Test yourself on Securing communications and establishing boundary protection
The full Google Cloud Professional Cloud Security Engineer question bank has 749 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.