Segmenting VPC Boundaries with Shared VPC

Configuring security properties of a VPC network, VPC peering, Shared VPC, and firewall rules means deciding who owns the network, which routes cross network boundaries, and which traffic is filtered. Shared VPC centralizes subnets, routes, and filtering in a host project while workload teams own instances in service projects. VPC Network Peering connects two Virtual Private Cloud (VPC) networks for internal communication without merging their firewalls or identities, and firewall rules (opens in a new tab) enforce distributed filtering at each virtual machine (VM).

1.1Implement Secure Shared VPC Topologies and Administrative Role Separation

Implementing secure Shared VPC topologies means placing network ownership in one host project and workload ownership in attached service projects. The host project owns Shared VPC networks, subnets, routes, and firewall rules, while instances and internal load balancer backends live in service projects and draw internal IP addresses from host subnets. Traffic flows between service projects over internal IP addresses, but central teams retain control of the network boundary.

The host and service project model defines strict attachment rules. A Shared VPC Admin must first enable a project as a host project and then attach each service project to it. A project cannot be a host and a service at the same time, and each service project can attach to only one host project, while an organization can operate multiple host projects. Host and service projects must belong to the same organization, except temporarily during migration, and networks defined inside a service project itself are never shared.

Administrative separation enforces least privilege by splitting network work from workload work. The Shared VPC Admin controls host enablement and attachment, Network Admins manage shared objects such as Cloud VPN gateways, Cloud Routers, and subnets, Security Admins manage firewall rules in the shared network, and Service Project Admins create instances only in authorized subnets. Establishing this trust boundary follows an ordered delegation:

1. Enable host: The Shared VPC Admin enables the host project and its Shared VPC networks.
2. Attach service: The Shared VPC Admin attaches each service project to that host project.
3. Grant network use: The Shared VPC Admin grants subnet-level or project-level use rights to each Service Project Admin.
4. Create workloads: Service Project Admins create instances that receive primary internal addresses from the authorized shared subnets.

Subnet-level grants confine a team to named subnets in the matching region, such as 10.0.1.0/24 in us-west1, while project-level grants permit any subnet in the host project:

Ephemeral addresses are assigned automatically from the shared subnet range, while static internal addresses also take values from that range but must be reserved as objects in the same service project as the resource. An existing instance cannot be converted to Shared VPC, so the admin must create a new resource that selects the shared subnet. For hybrid access, the Network Admin creates a Cloud VPN gateway and Cloud Router in the host project, traffic flows from service instances through the host gateway to on-premises, and Security Admins control that flow with host firewall rules.

1.2Evaluate VPC Network Peering Security Properties and Route Governance

Evaluating VPC Network Peering security means understanding a bilateral route exchange that never merges security boundaries. Each peering has an exporting side that offers routes and an importing side that accepts them, and each VPC retains its own firewall rules, Identity and Access Management (IAM) controls, and routing table. Route governance decides which subnet routes and custom routes cross that boundary.

VPC Network Peering is non-transitive, so traffic flows only between the two directly peered networks and never forwards through one peer to a third network. If network A peers with B and B peers with C or on-premises, hosts in A cannot reach C through B. Enabling Export custom routes on the middle network does not create transit, and return traffic fails without an explicit route back to the original producer range.

Custom route exchange requires action on both sides. The exporting VPC must enable export and the peer must enable import before eligible static routes and Cloud Router dynamic routes are programmed as peering routes. Privately used public IPv4 ranges need explicit opt-in on both sides, and stack-type changes that would import conflicting IPv6 routes are rejected unless both route tables stay consistent. Dynamic scope depends on the exporter: regional dynamic routing mode exports learned routes only in the same region as the Cloud Routers that learned them, while global mode exports them in all regions.

Peering prohibits overlapping or nested IPv4 subnet routes. Two peers cannot both use 100.64.0.0/10, and if one uses 100.64.0.0/24 the other cannot use a containing 100.64.0.0/10. While peered, these operations fail if they would create overlap:

• Adding a new subnet with a conflicting primary IPv4 range
• Adding a secondary IPv4 range to an existing subnet
• Expanding the primary IPv4 range of an existing subnet

Subnet routes also outrank static routes. A local static route cannot exactly match or fit within an imported peering subnet route, and an imported peering static route cannot exactly match or fit within a local subnet route. The same containment logic applies to IPv6 under IPV4_IPV6, where IPv6 subnets use /64 ranges. The constraints/compute.disableAllIpv6 organization policy can prevent creation of IPv6 subnets and therefore prevent those routes from becoming export candidates.

1.3Architect Hierarchical Firewall Policies and Granular VPC Filtering Rules

Architecting hierarchical firewall policy means layering Cloud Next Generation Firewall (Cloud NGFW) rules from broad VPC coverage to narrow workload exceptions. Cloud NGFW is a stateful, horizontally scalable firewall enforced in a distributed manner at each destination VM rather than at a single gateway. Traffic flows from the source to the destination VM, the decision is applied at the destination, and the VPC keeps full-mesh software-defined reachability.

Hierarchical layering stays within per-VM rule capacity by using fewer, broader rules first. One ingress rule that allows 10 TCP ports is more efficient than 10 single-port rules, and targets select which destination VMs a rule applies to. The documented order moves inward:

1. VPC-wide common rules: First apply baseline allow or deny rules common to all VMs in the VPC network.
2. Group rules: Then apply rules grouped across several VMs, such as a service group or all VMs in a subnet.
3. Individual workload rules: Finally apply rules to single VMs, such as a network address translation (NAT) gateway or bastion host.

Identity-based micro-segmentation scopes rules to workload identity instead of only IP placement. Service accounts, network tags, and Tags select destination VMs, while the source filter can select a subnet by name. For example, a rule can target VMs tagged subnet-1 with source Subnets set to subnet-1, so traffic flows only within that subnet. Prefer service accounts when possible because the rule follows the workload as addresses change, and choose subnet isolation when IP placement is part of compliance.

Centralized control differs between Shared VPC and peering. In Shared VPC, Security Admins in the host project create firewall rules that control traffic among service-project instances, while Service Project Admins cannot change network policy. In peering, each VPC keeps its own distributed firewall and IAM, peering is not transitive, and segmentation must be duplicated on both sides when both directions need filtering. VPC Flow Logs and firewall rule logging feed Network Intelligence Center tools such as Network Topology, Connectivity Tests, Firewall Insights, Network Analyzer, and Flow Analyzer, with aggregation, sampling, and metadata controls used to balance audit detail and cost.

Configuring network isolation and data encapsulation for N-tier applications means keeping frontend, application, and data tiers on private paths with controlled APIs between them. Isolation places each tier in its own subnet or project with deny-by-default filtering, while encapsulation hides backend implementation behind internal load balancers, private service paths, and encrypted transport. Cloud Service Mesh (opens in a new tab) and container controls extend that isolation to microservices with cryptographic identity.

2.1Private Ingress, Egress, and Managed Service Encapsulation

Private ingress, egress, and managed service encapsulation keeps tier-to-tier traffic off the public internet. Private Google Access is a subnet-level setting that lets VMs without external IP addresses reach Google APIs such as Cloud Storage over Google's internal network, which reduces cost and latency. Private Google Access is not enabled by default and must be enabled on each subnet where backend tiers need it.

Private service access creates a private path between a consumer VPC and a service-producer network that hosts managed services such as Cloud SQL or Memorystore. Traffic flows from workloads in the consumer VPC to database instances in the producer network without traversing the internet, so data tiers keep private addresses. Internal load balancers provide private ingress between tiers by terminating connections inside the VPC and forwarding to instance groups or zonal network endpoint groups (NEGs).

All VM-to-VM traffic within a VPC and between peered VPCs is encrypted, and some proxy load balancers add automatic network-level encryption to backends in Google Cloud VPC networks. That automatic encryption applies only to instance groups and zonal NEGs with GCE_VM_IP_PORT endpoints and is not auditable. The internal proxy options differ by proxy and backend protocol:

Choose HTTPS or HTTP/2 on the backend service when auditable encryption is required from the internal Application Load Balancer to backends, and the backends must serve the same protocol. When the backend is an internet NEG outside Google Cloud, traffic may cross the public internet, so a secure protocol and public CA-signed certificate are required. VPC Service Controls adds Layer 7 perimeter control above routing, with ingress control for authorized identities entering the perimeter and egress control for authorized destinations leaving it.

2.2Multi-Tier VPC Subnetting and Identity-Based Firewall Rule Enforcement

Multi-tier subnetting and identity-based enforcement places each application layer in a dedicated segment and allows traffic only between adjacent tiers. A Virtual Private Cloud (VPC) provides logical isolation, subnets group resources inside it, and firewall and identity controls decide which tier can reach the next tier. The common three-tier pattern flows from clients to the web frontend, then to the application tier, then to the backend database, ideally through an API gateway.

Decoupled topology lets tiers scale independently and supports phased migration on portable platforms such as Cloud Run or Google Kubernetes Engine (GKE) with managed databases like Cloud SQL. The resource hierarchy organizes controls top-down: the Organization is the root, Folders contain projects and other folders, and projects hold VPCs, subnets, and workloads. Grouping in-scope projects in a dedicated folder enables folder-level IAM and organization policies, such as blocking external IPs. A component is out of scope only when compromise of that component could not affect the isolated environment.

Identity-based firewall enforcement restricts east-west paths so only authorized groups can reach the next tier. Rules can state that traffic flows from the frontend group to the application group and from the application group to the database group, but never directly from frontend to database. VPC Service Controls governs VM-to-service, service-to-service, and VPC ingress and egress paths, while organization policies provide global guardrails such as disabling unneeded Service Account creation.

Data encapsulation hides backend ports behind controlled APIs and private encrypted paths. Apigee with end-to-end mutual Transport Layer Security (mTLS) exposes applications through APIs with privacy, integrity, and mutual authentication. Private connectivity preserves isolation:

• Private Google Access lets workloads reach Google APIs without an internet path.
• Private Services Access (PSA) connects workloads privately to producer networks for Cloud SQL or Memorystore.
• All VM-to-VM traffic within and between peered VPCs is encrypted, with MACsec over Cloud Interconnect, IPsec over Cloud VPN, and TLS between components.

Edge filtering stops attacks before they enter the VPC. Cloud Armor applies IP allow and deny lists at the external HTTP(S) load balancer close to users, including protection for hybrid backends behind hybrid NEGs against distributed denial-of-service (DDoS), SQL injection, and cross-site scripting. Third-party appliances can add intrusion detection or prevention (IDS/IPS) between segments but must be highly available to avoid blocking all traffic.

2.3Zero-Trust Microsegmentation and Encrypted Inter-Tier Transport

Zero-trust microsegmentation removes implicit trust between containerized tiers by requiring explicit allow rules and cryptographic identity for every call. Default Pod connectivity in GKE is flat, so every Pod can reach every other Pod, which lets an attacker move laterally after compromising one microservice. Zero-trust control replaces that openness with reachability policy plus authenticated encryption.

Kubernetes NetworkPolicies are basic flow controls that define which Pods can send and receive traffic by Pod labels, namespaces, ports, and protocols. A policy on a backend tier allows traffic only from authorized frontend Pods to specific backend ports, while all other Pod-to-Pod traffic to that backend is denied. Effectiveness depends on enablement and verification: the constraints/container.managed.enableNetworkPolicy constraint enforces network policy on GKE clusters, and network policy logging verifies that allowed and denied flows match intent.

Cloud Service Mesh is the control plane that adds mTLS encryption, identity authentication, and authorization between microservices. Traffic flows from the client sidecar proxy to the server sidecar proxy only after both sides validate identities, and the payload stays encrypted between services. The mesh also provides:

• Load balancing across healthy instances without exposing direct Pod addresses.
• Service authorization so only authenticated identities can invoke specific APIs.
• Throttling and quota to limit rates and contain cascading failure.
• Metrics for per-service telemetry and anomaly detection.
• Central provisioning of certificates and policy to each sidecar.

NetworkPolicies and mesh solve different problems and are used together:

A frontend-to-backend flow shows the composition: the NetworkPolicy permits packets from the frontend namespace to backend Pods on a port, then the mesh requires the frontend identity to authenticate via mTLS and pass authorization. If either denies, the connection fails. Hardened boundaries surround the cluster with GKE private nodes without external IPs, authorized networks for control-plane access, VPC segmentation, VPC Service Controls perimeters, and approved transports including MACsec, IPsec, TLS 1.2 or higher, and end-to-end mTLS through Apigee.

Identifying use cases and configuring VPC Service Controls means deciding when identity controls are not enough and a data perimeter is required. VPC Service Controls (VPC-SC) (opens in a new tab) is a context-based perimeter that isolates multi-tenant Google Cloud services to mitigate data exfiltration. A service perimeter wraps projects, VPC networks, and restricted services such as Cloud Storage and BigQuery, and data cannot cross that boundary unless an ingress or egress rule explicitly allows it.

3.1Analyze Data Exfiltration Risks and Mitigation Scenarios

Analyzing exfiltration risk means recognizing paths where an authorized identity could still copy sensitive data outside trusted networks. Identity and Access Management (IAM) controls who can call an API, while VPC-SC controls whether restricted-service data can cross the perimeter even when IAM would allow it. A perimeter is required for intellectual property, Payment Card Industry Data Security Standard (PCI DSS) data, and other sensitive data that must not leave trusted context.

The following vectors justify creating a perimeter:

• Stolen credentials used from unauthorized networks: traffic flows from a client with a stolen token to a protected resource, and VPC-SC denies it when the network origin is outside authorized VPCs or IP ranges.
• Malicious insider or compromised code inside: operations flow from inside to an external resource, such as gcloud storage cp to a public bucket or bq mk to an external BigQuery table, and VPC-SC blocks the copy outside.
• Misconfigured IAM or overly broad permissions: access flows from an over-privileged identity to sensitive projects, and an enforced perimeter still denies cross-boundary movement.
• Vulnerable or internet-reachable service paths: requests flow over public paths or to services not fully integrated with VPC-SC, and private connectivity plus VPC accessible services narrow which APIs those clients can reach.

VPC-SC blocks movement by enforcing controls around explicitly restricted services. Clients inside with private access do not gain access to unauthorized resources outside, and separated clients and resources exchange data only through ingress and egress rules. Context-aware access evaluates identity type, identity, device posture, and network origin, so internet access can be limited to defined IPv4 and IPv6 ranges and on-premises or cloud clients can use Private Google Access from authorized VPC resources. Companion controls close network paths: traffic flows from inside VMs to Google APIs through a Private Service Connect endpoint for the vpc-sc bundle, Cloud DNS resolves googleapis.com to that endpoint, and firewall rules deny broad egress before allowing TCP port 443 to the endpoint.

Validating perimeters uses enforcement modes and ordered setup. A perimeter in enforced mode denies violating requests, while dry run mode logs violations without denying, which supports previewing policy, measuring change impact, and mirroring production in development. Configuration follows an ordered sequence:

1. Create an access policy: Collect perimeters and access levels for the organization, with one organization policy plus optional scoped policies.
2. Secure Google-managed resources: Create service perimeters listing protected projects and restricted services.
3. Set up VPC accessible services: Optionally limit which services VPC networks inside can call, often with RESTRICTED-SERVICES.
4. Set up private connectivity: Optionally route API traffic through Private Google Access or Private Service Connect with restrictive DNS and firewall.
5. Allow context-aware ingress: Optionally define ingress rules and access levels by IP, VPC, identity, and device.
6. Configure secure data exchange: Optionally define granular ingress and egress flows, such as an outside presentation tier calling inside application tiers.

Choose scope by where sensitive data lives:

3.2Implement and Troubleshoot Granular Access Policies

Implementing granular access policies means adding narrow exceptions to a deny-by-default perimeter without reopening exfiltration paths. VPC-SC blocks API requests to restricted services from crossing the boundary, while ingress rules, egress rules, and Access Context Manager access levels permit specific identities, devices, and networks under defined conditions. An access policy collects perimeters and access levels, with one policy at the organization node plus scoped policies for folders and projects.

Context-aware access evaluates client attributes before allowing a request to reach a protected resource. An access level defines conditions on identity type, specific identity, device trust, and network origin such as IP range or VPC network. Traffic flows from the external client to the restricted API only when both IAM permissions and VPC-SC boundary conditions are satisfied. Practical patterns include allowing authorized VPC resources to use Private Google Access to reach inside and restricting internet access to defined IPv4 and IPv6 ranges.

Ingress and egress rules name both sides of each allowed flow. An ingress rule controls outside-to-inside traffic to protected resources, and an egress rule controls inside-to-outside traffic to external destinations. Each rule names source context, destination project or resource, and restricted services and methods, so a request crosses only when all conditions match. Copies outward such as gcloud storage cp to a public bucket remain denied unless an explicit egress rule permits that source, destination, and service combination. Perimeter bridges allow defined projects in different perimeters or organizations to interoperate without merging perimeters.

Limiting service use inside prevents alternate exfiltration paths. VPC accessible services restrict which Google APIs are reachable from inside, commonly with RESTRICTED-SERVICES to match the perimeter's restricted set. Service patterns permit only specific unsupported API URL patterns over private paths. In production, restrict all supported services rather than only Cloud Storage and Compute Engine, then open narrow method-level exceptions.

Private network controls move API traffic off the internet and deny internet egress. The subnet enables Private Google Access, a Private Service Connect endpoint targets the vpc-sc bundle, and a private DNS zone for googleapis.com. maps names to the endpoint address such as 10.0.1.1. A low-priority rule such as priority 65534 denies all egress to 0.0.0.0/0, while a higher-priority rule such as priority 1000 allows only tcp:443 to the endpoint address. Shared VPC deployments must include the host project alongside service projects or network controls will not align with policy.

Diagnosing failures means separating policy denials from network and IAM denials:

A missing ingress rule blocks outside-to-inside access, a missing egress rule blocks inside-to-outside copies, overly narrow accessible services block needed APIs even when the perimeter would allow them, and incorrect Cloud DNS or firewall blocks the VM from reaching the endpoint before policy is evaluated. Cloud Audit Logs reveal source network, identity, service, and method for each blocked request.

3.3Design and Configure Secure Service Perimeters

Designing secure service perimeters means defining a trust boundary that stops exfiltration without breaking legitimate service use. A service perimeter defines a boundary around projects, VPC networks, and protected APIs, so outside requests are denied by default even when IAM would allow them. Resources inside the same perimeter communicate freely when IAM and network controls permit, while cross-boundary access needs an explicit access level or ingress or egress rule.

A common unified perimeter is a single large perimeter enclosing all sensitive projects. This provides the most effective protection against exfiltration because it eliminates east-west paths between perimeters that each need authorization. Management overhead is lower because admins focus on north-south access from the internet rather than east-west traffic between perimeters. Services inside still depend on IAM least privilege and VPC firewall controls, including blocking direct internet egress so a compromised workload cannot send data out via networking.

Multiple perimeters isolate data with different trust, regulatory, or sharing needs but increase cost because every cross-perimeter flow must be reviewed. Choose multiple perimeters only when isolation itself is required:

• High-trust versus shareable data: keep non-obfuscated healthcare data separate from de-identified data shared externally.
• Regulated scope: place PCI DSS projects in a dedicated perimeter to limit compliance scope.
• Data-sharing production: use a separate perimeter for lower-tier outputs such as anonymized data exchanged with partners.
• Independent tenants: define a perimeter per partner or customer when tenant-to-tenant movement is exfiltration.

Keep design simple and start during architecture planning because protection changes service behavior. Avoid multiple bridges, demilitarized zone (DMZ) perimeters, and complex access levels. Enable all protected services in the perimeter to avoid leaving an unprotected path from a protected resource to another service, and qualify every new project for inclusion.

Ingress and egress rules are granular exceptions that name both sides. An ingress rule allows outside-to-inside access to a protected resource, and an egress rule allows inside-to-outside access to an external resource. Each rule defines sources such as user, service account, IP, VPC network, or project, plus destinations by service name, method, and target project. If caller and target share a perimeter, no rule is needed; otherwise configure the rule on the perimeter owning the protected resource. For example, a Compute Engine instance in projects/111 needing google.storage.objects.get on a bucket in projects/999 needs an egress rule in the source perimeter naming the workload identity, storage.googleapis.com, the method, and projects/999. Backup, disaster recovery, and Audit Manager patterns follow the same protected-side direction, with ingress on the vault or bucket perimeter and egress on the caller perimeter.

Choose the control by source and precision. Access levels grant north-south entry based on who and from where, such as allowing a console or signed URL from an approved IP or account. Ingress and egress rules grant service access at API and method granularity, such as Pub/Sub publishing across organizations or private VPC reads of BigQuery. Reserve bridges for stable project-to-project trust and avoid multiplying them because each bridge widens the effective boundary.

Key Facts

• Shared VPC separates ownership so a host project owns subnets, routes, and firewall rules while service projects own instances, and each service project can attach to only one host project.
• VPC Network Peering is non-transitive with separate firewalls and IAM, prohibits overlapping or nested IPv4 subnet routes, and requires both export and import to exchange custom routes.
• Cloud Next Generation Firewall enforces stateful rules in a distributed manner at each destination VM, layered from VPC-wide common rules to group rules to individual workload rules.
• Private Google Access must be enabled per subnet to let instances without external IPs reach Google APIs privately, while automatic network-level encryption to backends is not auditable and HTTPS, HTTP/2, or SSL is required for auditable encryption.
• VPC Service Controls denies restricted-service data from crossing its service perimeter unless an ingress or egress rule allows it, with enforced mode denying violations and dry run mode only logging them.