Secure VPC Networks with Shared VPC and Firewalls

Shared VPC (opens in a new tab) is a centralized network model where one host project owns Shared VPC networks and multiple service projects attach to use them. Instances and load balancer backends live in the service projects, but their internal IP addresses come from subnets in the host project. Traffic flows between service projects over internal IP addresses, while central teams retain ownership of subnets, routes, and firewall rules and workload teams own only resources in their own service projects.

1.1Centralized Host and Service Project Model

The host and service project model defines where network ownership sits and where workload ownership sits. A Shared VPC Admin must first enable a project as a host project and then attach each service project to that host project. A project cannot be both a host project and a service project 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 project migration between organizations. Linked projects can sit in the same or different folders, but when folders differ the Shared VPC Admin must hold Shared VPC Admin rights to both folders. A standalone project that is neither a host nor a service project does not use Shared VPC, and networks defined inside a service project itself are never shared.

1.2Administrative Roles and Least-Privilege Delegation

Administrative role separation enforces least privilege by splitting network control from workload control. The Shared VPC Admin controls host enablement and service project attachment, then delegates network work to Network Admins and Security Admins and workload work to Service Project Admins. Network Admins create and manage shared network objects such as Cloud VPN gateways, Cloud Routers, and subnets, while Security Admins create and manage firewall rules in the Shared VPC network.

Establishing the trust boundary follows an ordered delegation where each step depends on the prior grant:

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 in their service project that draw IP addresses from the authorized shared subnets.

A Service Project Admin for one service project has no permissions in another service project by default, which isolates cross-functional teams. For example, Tier 1 web admins manage only the Tier 1 service project and Tier 2 service admins manage only the Tier 2 service project, while oversight admins hold rights in both service projects.

1.3Subnet-Level Access Control and Resource Provisioning

Subnet-level access control limits which shared subnets a Service Project Admin can consume for new workloads. A grant at the subnet level permits instance creation only in named subnets, such as 10.0.1.0/24 in us-west1 or 10.15.2.0/24 in us-east1, and the instance zone must sit in the same region as the selected subnet. A grant at the project level permits instance creation in any subnet in any Virtual Private Cloud (VPC) network in the host project. In both cases the instance receives its primary internal IPv4 address from the free range of the selected shared subnet, and internal communication between service projects remains subject to host firewall rules.

The choice of grant scope controls isolation versus flexibility:

IP ownership is split between value and object for static addresses. Ephemeral addresses are automatically assigned from the shared subnet range when the instance or internal load balancer forwarding rule is created. Static internal addresses also take their value from the shared subnet range, but the address object must be reserved in the same service project as the resource that uses it. Use of Shared VPC is not mandatory, and existing resources do not migrate automatically, so an existing instance cannot be reconfigured to use a Shared VPC network and the Service Project Admin must create a new eligible resource that selects the shared subnet.

1.4Secure Topologies for Environment Isolation and Hybrid Connectivity

Secure Shared VPC topologies centralize policy while isolating environments by host project. A single host project with a single Shared VPC network and multiple service projects is the simplest pattern for teams with common requirements, because firewall, routing, and subnet policy apply consistently to all attached teams. Multiple host projects isolate stronger boundaries, such as a Test Environment host with testing service projects separate from a Production Environment host with production service projects, which supports audit needs such as PCI, separate quota pools, and separate administration policies.

Choose the host count by operational constraints described in the best practices for VPC design (opens in a new tab). Use a single host project when workloads require multiple network interfaces that must attach to shared networks, because that attachment depends on one host. Use multiple host projects when resource needs exceed the quota or scaling limits of a single project or when each VPC needs independent IAM administration. A shared-services VPC can host common proxies, authentication, and directory services to avoid replicating them into every isolated host.

Hybrid connectivity extends the same centralized boundary to on-premises networks. The Network Admin creates a Cloud VPN gateway in the host project and a Cloud Router in the same region to exchange routes with the on-premises gateway, and traffic flows from service project instances through the host VPN gateway to on-premises services. If the VPC dynamic routing mode is global, the Cloud Router applies learned on-premises routes to all subnets in the VPC and advertises all VPC subnet routes on-premises. Security Admins control that flow with host firewall rules, so service instances can reach internal database or directory servers only when firewall rules permit, and outbound VPN billing is attributed to the host project that contains the gateway while other instance egress is attributed to its service project.

VPC Network Peering (opens in a new tab) is a direct, bilateral connection between two Virtual Private Cloud (VPC) networks that exchanges subnet routes and selected custom routes without merging firewall or identity boundaries. Each peering relationship has an exporting side that offers routes and an importing side that accepts them, and each VPC network retains its own firewall rules, IAM controls, and routing table. Route governance decides which prefixes cross that boundary and where they become usable.

2.1Non-Transitive Peering Boundary

VPC Network Peering non-transitivity means traffic flows only between the two directly peered VPC networks and never forwards through one peer to reach a third network. If network A is peered to network B, and network B is peered to network C or to an on-premises network, hosts in network A cannot reach network C through network B. This boundary holds even when Export custom routes is enabled on the middle network, so enabling export does not create transit.

The non-transitive boundary creates two operational consequences for return traffic. Traffic sent from a service-producer network, such as Agent Platform over Private Services Access, into your VPC network can be forwarded by your VPC network to on-premises destinations, but responses fail unless the on-premises network has an explicit route back to the allocated service-producer IP range. Similarly, endpoints in a second peered network cannot send responses back through your network to the original producer, which produces timeout or host-unreachable errors when a transitive path is attempted.

2.2Custom Route Export and Import Governance

Custom route exchange in VPC Network Peering governs how eligible static routes and dynamic routes learned by Cloud Router (opens in a new tab) move from an exporting VPC network to an importing peer network. The exporting VPC network must enable export of custom routes, and the peer network must enable import before the routes are programmed as peering routes. Exporting sends all eligible static and dynamic routes in the VPC network, such as routes to an on-premises network learned over a VPN tunnel or Interconnect, into the peer.

Privately used public IP ranges have stricter governance and are not imported by default. Both sides must explicitly opt in: the exporting VPC network must enable export of subnet routes using privately used public IPv4 addresses, and the importing VPC network must enable import of those ranges. The same bilateral requirement applies to stack-type changes that would newly import conflicting IPv6 subnet routes, so a configuration update is rejected unless both route tables remain consistent.

2.3Subnet Overlap Prohibitions Between Peers

Subnet route overlap rules in VPC Network Peering prevent two peered VPC networks from claiming the same or nested IPv4 destination. Peering prohibits identical IPv4 subnet routes, so two peered VPC networks cannot both use 100.64.0.0/10. Peering also prohibits containment, so if the local VPC network has 100.64.0.0/24, no peered VPC network can have 100.64.0.0/10 that contains it.

Google Cloud enforces IPv4 overlap prohibitions at three times: when VPC networks are first peered, while the networks remain peered, and when a peering configuration changes such as enabling import of privately used public IPv4 addresses. While peered, the following operations return an error if they would create an overlap:

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

IPv6 subnet routes are globally unique by definition and provide a stronger boundary than IPv4 checks. No two VPC networks in Google Cloud can use the same internal or external IPv6 subnet range, such as fc:1000:1000:1000::/64, whether or not the networks are peered. Because subnet IPv6 ranges must use a 64-bit mask length, any conflict is an exact /64 collision.

2.4Static Route and Subnet Route Precedence

Subnet route precedence in VPC Network Peering requires that subnet routes and peering subnet routes hold the most specific destination, so a static route cannot undercut them. A local static route in one VPC network cannot have a destination that exactly matches or fits within an imported peering subnet route. A peering static route imported from a peer cannot have a destination that exactly matches or fits within a local subnet route.

The two directions of conflict block different operations but share the same containment logic:

The same rules apply to IPv6 when the peering stack type is IPV4_IPV6. A local static 2001:0db8:0a0b:0c0d::/96 blocks peering to a network whose IPv6 subnet is 2001:0db8:0a0b:0c0d::/64, and changing an IPv4-only peering to IPV4_IPV6 is rejected when that conflict would appear. Conversely, a local IPv6 subnet 2001:0db8:0a0b:0c0d::/64 blocks import of a peer static route such as 2001:0db8:0a0b:0c0d::/96 that fits inside it.

2.5Dynamic Route Propagation and Routing Mode

Dynamic route propagation across VPC Network Peering is controlled by the dynamic routing mode of the exporting VPC network that owns the Cloud Routers which learned the prefixes. The exporting network determines in which regions the peering dynamic routes can be programmed in peer networks. The importing network does not expand that regional scope by its own mode.

Regional and global modes create different reachability footprints for the same learned prefix. If the exporting VPC network uses regional dynamic routing mode, that network exports dynamic routes only in the same region as the Cloud Routers that learned the prefixes. If the exporting VPC network uses global dynamic routing mode, that network exports dynamic routes in all regions, so peers in distant regions receive the same dynamic destinations.

2.6Organization Policy Guardrails for Peering Routes

Organization policy guardrails limit which address families and route types administrators can introduce into peered topologies. The constraints/compute.disableAllIpv6 organization policy constraint can prevent a network administrator from creating subnets with IPv6 address ranges, which in turn prevents those IPv6 subnet routes from becoming candidates for export. This control constrains whether IPv6 routes received from peered VPC networks can be used alongside local IPv6 subnets.

Access to change peering and route state is separately bounded by IAM, with the Compute Network Admin role (roles/compute.networkAdmin) containing the permissions needed to manage networking resources. Restricting who can create peerings, update export and import flags, and create static routes or subnets keeps unauthorized cross-VPC interconnectivity from being established through a permissive peering update.

Cloud Next Generation Firewall (Cloud NGFW) (opens in a new tab) with hierarchical and granular Virtual Private Cloud (VPC) filtering is the practice of enforcing boundary segmentation with layered rules that narrow from the whole VPC to groups to single workloads. Cloud NGFW provides a stateful, horizontally scalable firewall that is enforced in a distributed manner on each virtual machine (VM), while Shared VPC and VPC Network Peering define where that policy is owned and where it stops. Advanced design combines broad-to-narrow rule layering with identity-based targets and tuned logging to achieve micro-segmentation without exhausting per-VM rule capacity.

3.1Distributed Enforcement Model of Cloud Next Generation Firewall

The distributed enforcement model of Cloud Next Generation Firewall applies stateful firewall rules directly to each VM in a distributed manner. Traffic flows from the source VM or network to the destination VM, and the firewall decision is applied at the destination VM itself rather than through a single gateway chokepoint. Because enforcement scales horizontally with the VMs, the VPC retains full-mesh software-defined reachability while filtering is still applied per workload.

Pushing controls to endpoints is the preferred high-scale pattern for boundary protection. Hardened VMs plus Google Cloud firewall rules preserve the forwarding architecture of the VPC, while host-based endpoint agents add inspection without multi-interface bridging VMs. Multi-interface network virtual appliance (NVA) designs bridge multiple VPC networks in the same project, so aggregate resource needs can hit project-level VPC quotas and per-VM bandwidth limits. Choose native distributed rules when the requirement is scalable segmentation, and choose routed NVAs only when protection from application exploits, URL filtering, or cross-cloud policy uniformity exceeds native capabilities. When higher-layer inspection is required, third-party NVAs can be inserted into the data path with routes, but a single VM-based chokepoint works against cloud scale and requires mitigation with managed instance groups behind an internal passthrough Network Load Balancer.

3.2Hierarchical Layering From Broad VPC Rules to Granular Targets

Hierarchical layering is the ordering of firewall rules from general to specific to stay within the number of rules that can be programmed on any VM. A single complex rule is more efficient than many single-purpose rules, for example defining one ingress rule that allows 10 TCP ports instead of writing 10 separate rules that each allow one port. The policy depends on targets, which select the destination VMs that a rule applies to, so broad coverage and narrow exceptions can coexist without duplication.

The documented layering order moves from the VPC perimeter inward:

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

Traffic flows from the broadest match to the most specific enforcement, and the narrowest rule provides micro-segmentation only after the baseline is in place.

3.3Identity-Based Micro-Segmentation With Service Accounts, Network Tags, and Tags

Identity-based micro-segmentation is the use of service accounts, network tags, and Tags to scope firewall rules to specific VMs rather than relying only on IP addresses and subnet placement. Subnet isolation treats the subnet as the security boundary, which matches on-premises models where VM identity is tied to network location. Target filtering treats the workload identity as the boundary, which aligns with Google Cloud software-defined networking where identity is not based solely on subnet IP address.

A subnet-scoped isolation rule binds both sides explicitly: the rule targets VMs carrying a specific Tag, network tag, or service account, and the source filter selects the subnet by name. For example, to permit all communication within the same subnet, the firewall rule sets Targets to specified target tags with value subnet-1 and sets Source filter to Subnets selecting subnet-1, so traffic flows only from VMs in subnet-1 to VMs tagged subnet-1. The target VMs depend on the tag or service account assignment made at instance creation, and the source depends on the subnet membership of the sender. Prefer service accounts when possible because the rule follows the workload even as addresses change, while subnet-based rules require re-mapping when addresses or placement change. Choose subnet isolation when IP placement is part of identity or compliance, and choose service-account targeting when different subsets in the same subnet need different rules.

3.4Centralized Control in Shared VPC and Isolation Across Peered Networks

Shared VPC (opens in a new tab) is the model for centralized boundary control where a host project owns the VPC network, subnets, routes, and firewall rules and service projects own the instances that use them. Network policy flows from the host project to the service-project VMs: Security Admins in the host project create and manage firewall rules that control traffic among service-project instances and to on-premises networks, while Service Project Admins can only create instances in granted subnets. The instance depends on the shared subnet for its internal IPv4 or IPv6 address, but the firewall ownership boundary remains in the host project, which enforces least privilege by preventing VM administrators from making network-impacting changes. Grant the network user role at the subnet level to limit each team to only its assigned 10.0.1.0/24 or 10.15.2.0/24 style range.

VPC Network Peering connects two VPC networks over Google's software-defined network so VMs communicate with internal IP addresses subject to firewall rules, but each peered network maintains its own distributed firewall. Peering merges control-plane route exchange for subnet routes, alias IP ranges, and optionally custom static and dynamic routes, yet it never exchanges Identity and Access Management (IAM) policies, so Network and Security Admins in one Virtual Private Cloud (VPC) gain no rights in the peer. Peering is not transitive, so traffic from VPC A to VPC C through VPC B is blocked unless A and C are directly peered. This boundary means segmentation policy must be duplicated on both sides of the peering when both directions require filtering.

3.5Firewall Logging, Flow Metadata Tuning, and Audit Analysis

Firewall and flow telemetry is the record of allowed and denied connections that supports security auditing and intrusion analysis. VPC Flow Logs capture per-VM flow records to Cloud Logging, and firewall rule logging captures the specific rule decision with connection metadata. For VPC networks with mostly long-lived connections, setting the log aggregation interval to 15 minutes greatly reduces log volume while preserving network monitoring tasks such as diagnosis, filtering by VM and application, and forecasting traffic growth.

Use the following volume controls to match cost to the audit question:

• Aggregation interval tuning for monitoring: Aggregate long-lived connections over 15 minutes to reduce log count and simplify analysis of traffic changes and capacity growth.
• Sampling for usage optimization: Sample VPC Flow Logs to retain low-level samples and aggregated views for estimating inter-region, inter-zone, internet-country, and top-talker traffic without logging every flow.
• Metadata removal for forensics: Remove additional metadata when only IP addresses and ports are needed to reduce Cloud Logging consumption while still determining which IPs talked to whom and when and identifying compromised addresses.

Network Intelligence Center provides the analysis plane for this telemetry from a single console. Traffic flows from VPC Flow Logs and firewall logs to Network Topology for visualization, Connectivity Tests for path diagnosis, Firewall Insights for understanding rule interactions and shadowing, Network Analyzer for detecting misconfigurations, and Flow Analyzer for querying traffic flows. The logs depend on subnet-level enablement, and Firewall Insights depends on the logged allow and deny decisions to reveal overly broad or unused rules.

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.
• A Service Project Admin with a subnet-level grant can create instances only in explicitly authorized subnets in the matching region, while a project-level grant permits any subnet in the host project.
• VPC Network Peering is non-transitive and retains separate firewalls and IAM, so enabling custom route export does not allow a peer to reach a third network through the middle VPC.
• Peering prohibits overlapping or nested IPv4 subnet routes and blocks static routes that exactly match or fit within a local or peering subnet route, with the same containment logic for IPv6 under IPV4_IPV6.
• 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.