Private Connectivity Across VPC Networks

VPC Network Peering (opens in a new tab) is a bilateral connection that provides internal IP address connectivity between two Virtual Private Cloud (VPC) networks. The two networks can be in the same Google Cloud project, in different projects, or in different organizations, and can use any combination of IPv4-only, dual-stack, and IPv6-only subnets. Traffic flows only between the two directly peered networks, so peering is non-transitive and does not forward traffic to a third network.

1.1Cross-Project Prerequisites and IAM Governance for Peering

Cross-project peering governance controls who can create and inspect a peering because no administrator can list peering requests for a VPC network. The administrator who creates the local side must obtain the peer VPC network name and, when the peer is in another project, its project ID from the peer administrator. The Compute Engine API must be enabled in the project, and peering operations are governed by Identity and Access Management on the project. Governance of peering operations depends on the Compute Network Admin role (roles/compute.networkAdmin) or a custom role with explicit peering permissions:

• compute.networks.addPeering to create a peering configuration
• compute.networks.updatePeering to change route exchange or stack type
• compute.networks.removePeering to delete a peering configuration
• compute.networks.listPeeringRoutes to inspect route exports and import candidates

Google Cloud allows only one peering operation at a time across peered networks. A second concurrent operation fails with Error: There is a peering operation in progress on the local or peer network. Try again later.

1.2Creating Bilateral Peering Connections Across Projects

A bilateral peering connection becomes usable only after both VPC networks configure peering toward each other. The first configuration alone leaves the peering in an INACTIVE state with a message such as waiting for the connection to be created by the peer network. The peering changes to ACTIVE in both networks only after the second, matching configuration is created. The ordered activation sequence for network-a in project-a and network-b in project-b is:

1. Create first side: Create peer-ab in network-a that references project-b and network-b, with import and export of custom routes selected.
2. Create matching side: Create peer-ba in network-b that references project-a and network-a, usually performed by the peer network administrator.
3. Exchange implicit routes: When both sides are ACTIVE, subnet routes and enabled custom routes are exchanged automatically as implicit routes that have no corresponding route resources.

In gcloud, the same result uses gcloud compute networks peerings create on each side with --network, --peer-project, and --peer-network. In Terraform, the network-peering module links local_network to peer_network by self link, where each self link includes the project ID and VPC network name and can be retrieved with gcloud compute networks describe or networks.get.

1.3Custom Route Exchange and Stack Types for Peering

Custom route exchange controls whether static routes, dynamic routes learned by Cloud Router, and subnet routes with privately used public IPv4 addresses move across a VPC Network Peering connection. A network imports routes only when the peer network exports them, and the peer receives routes only when it is configured to import them. Subnet routes are exchanged automatically for an ACTIVE peering, while custom routes require explicit import and export on both sides. Stack type and subnet-route options must align on both sides of the connection. By default the stack type is IPV4_ONLY, which exchanges only IPv4 routes, and both sides must specify IPV4_IPV6 to exchange IPv4 and IPv6 routes. Even when a VPC network uses global dynamic routing mode, IPv6 routes learned from Cloud Router remain regional. Subnet routes that contain privately used public IPv4 addresses are exported by default but are not imported by default until the importing side selects import of subnet routes with public IP. The gcloud flags make the direction explicit:

• --export-custom-routes sends custom routes to the peer
• --import-custom-routes accepts custom routes from the peer
• --export-subnet-routes-with-public-ip sends privately used public IPv4 subnet routes
• --import-subnet-routes-with-public-ip accepts privately used public IPv4 subnet routes

To disable an option, use the corresponding --no- form, such as --no-import-custom-routes or --no-export-subnet-routes-with-public-ip.

1.4Peering Update and Delete Modes for Decentralized Control

Peering update strategy determines whether one administrator can change route exchange unilaterally or whether both sides must agree. Independent mode is the default update strategy and allows each side to update its own import, export, and stack-type settings without peer acknowledgment. Consensus mode requires coordinated acknowledgment, so a change takes effect only after both the local network and the peer network accept it.

Moving from independent to consensus mode requires setting Update strategy to Consensus in Advanced options or --update-strategy=CONSENSUS on both configurations. To cancel a pending consensus update, reset each modified parameter to its previous value. Deletion follows the same governance model: each side removes its own peering configuration, and the network itself cannot be deleted until its peering connection is removed.

1.5Verifying Routes and Securing Peered Traffic with Firewall Rules

Route verification for VPC Network Peering distinguishes between offered routes and installed routes. The Routes page Effective routes tab, filtered by Type to Peering subnet, Peering static, or Peering dynamic, shows the routes actually installed in the selected VPC network and region, including suppressed routes and the routing-order reason for suppression. Overlapping or conflicting peer prefixes therefore appear as candidates that may be omitted from effective routing, which prevents unintended exposure between decentralized VPC networks. Traffic verification and boundary enforcement depend on VPC firewall rules, because peering alone does not open access. Each peered VPC network retains its own ingress and egress firewall policy, so administrators create firewall rules that allow or deny traffic between the peered address ranges on each side. VPC Flow Logs show flows sent and received by virtual machine instances, while Firewall Rules Logging records which allow or deny rule was hit and can be reviewed in Cloud Logging to confirm that only intended cross-peering traffic passes.

Shared VPC (opens in a new tab) is a Google Cloud model that shares one or more Virtual Private Cloud (VPC) networks (opens in a new tab) from a central host project with other service projects in the same organization. The host project contains the Shared VPC networks, including subnets, routes, and firewalls, while attached service projects contain workloads such as Compute Engine instances that use those shared subnets with internal IP addresses. This split lets organization administrators keep centralized control of the network boundary while delegating only workload creation to separate teams.

2.1Shared VPC Administrative Boundaries for Host and Service Projects

Administrative boundaries in Shared VPC are defined by the Google Cloud organization, folders, and the host-to-service project relationship. Participating host and service projects must belong to the same organization, except temporarily during project migration between organizations, and linked projects can sit in the same or different folders if the administrator has Shared VPC Admin rights to both folders. A project is either a host project or a service project, never both at the same time, and each service project can be attached to only one host project, while an organization can operate multiple host projects. A host project must first be enabled as a host project by a Shared VPC Admin, and only then can service projects be attached to it to participate in Shared VPC. A standalone project that is neither a host nor a service project does not use Shared VPC at all, and any VPC network defined inside a service project remains local to that project and is never shared. This boundary ensures that network administration, auditing, and access control stay with the host project, while service projects provide isolated administrative domains for different departments, cost centers, or tiers.

2.2IAM Roles and Least-Privilege Delegation for Shared VPC

Identity and Access Management (IAM) delegation in Shared VPC enforces least privilege by separating who can change the network from who can launch resources into it. Shared VPC Admins delegate network administration to Network and Security Admins in the host project, while Service Project Admins receive only the ability to create and manage instances that use approved shared subnets, with no permission to make network-impacting changes.

• Shared VPC Admin: enables the host project, attaches service projects, and grants subnet-level or project-level use permissions to Service Project Admins.
• Network Admin: creates and manages shared network resources such as subnets, Cloud VPN gateways, Cloud Router instances, and routes in the Shared VPC network.
• Security Admin: creates and manages firewall rules in the Shared VPC network to control traffic among service-project instances and on-premises systems.
• Service Project Admin: creates and manages eligible resources, such as instances and internal load balancer components, inside an attached service project by selecting an authorized shared subnet.

Subnet-level delegation is the preferred control for isolation because it limits a Service Project Admin to specific subnets, while project-level permission grants use of any subnet in any VPC network in the host project. For example, an admin for Service Project A with access only to 10.0.1.0/24 must create the instance in a zone in us-west1 to match that subnet region, while an admin with project-level access could place Instance C in any subnet such as 10.7.1.0/24 in us-east1. Best practice is to grant the network user role at the subnet level so each team receives only the address space it needs.

2.3Service Project Attachment and Resource Provisioning Workflow

The service project attachment workflow establishes the trust boundary before any workload can use the shared network. The Shared VPC Admin enables the host project, attaches each service project to that host, and then grants the appropriate Service Project Admins subnet-level or project-level network-use permissions for the Shared VPC network. Only after attachment can a Service Project Admin create a new eligible resource and configure it to use a shared subnet, selecting the Shared VPC network and an available shared subnet whose region determines the allowed instance zone. Attachment does not convert existing resources to Shared VPC, so resources that already exist in a newly attached service project must be re-created to use the shared network. An existing instance cannot be reconfigured to move into a Shared VPC subnet, and the same re-creation limitation applies to private zones. When IP addresses are assigned, the primary internal IPv4 address comes from the free range of the selected shared subnet, and a static internal address object must be created in the same service project as the resource that uses it even though its value comes from the host subnet range.

2.4Centralized Firewall Governance and Hybrid Boundary Control in Shared VPC

Centralized firewall governance in Shared VPC means all firewall rules for the Shared VPC network are created and managed in the host project by Security Admins. Instances in different service projects that share the same Shared VPC network communicate internally over internal IPv4 or IPv6 addresses only as allowed by those host-level firewall rules. This central policy point lets administrators apply consistent access controls across many service projects while Service Project Admins retain only Compute Instance Admin-like ability to create and delete instances. The same central control extends to hybrid boundaries when the Shared VPC network connects to on-premises through Cloud VPN and Cloud Router. A Network Admin creates the Cloud VPN gateway and tunnel in the host project, with a Cloud Router in the same region exchanging routes with the on-premises gateway. If the VPC dynamic routing mode is global, the Cloud Router applies learned on-premises routes to all subnets in the VPC network and shares routes to all VPC subnets with its on-premises counterpart. Subject to host firewall rules, service-project instances can then reach internal on-premises services such as database or directory servers without exposing each service project to direct network management.

2.5Cross-Project Isolation Strategies for Production, Testing, and Tiers

Cross-project isolation strategies in Shared VPC use separate host projects, separate service projects, and narrow subnet grants to maintain organizational network control. A single host project with a single Shared VPC network and multiple attached service projects keeps policy centralized and is effective when teams share common requirements. Multiple host projects provide stronger isolation when environments need separate administration policies, separate quotas, or compliance separation, such as a Test Environment host with testing service projects kept fully apart from a Production Environment host with production service projects. A two-tier web service shows how tier isolation works within one shared network by mapping each tier to its own service project and subnet. Tier 1 service-project admins receive access only to 10.0.1.0/24 for externally facing instances behind an external Application Load Balancer, while Tier 2 admins receive access only to 10.0.2.0/24 for internal instances behind an internal passthrough Network Load Balancer. Admins who oversee the whole service hold Service Project Admin rights in both projects plus project-level use of the host project. Use a single host project if resources require multiple network interfaces, and use multiple host projects if resource needs exceed a single project quota or if each VPC needs independent IAM controls for networkAdmin, securityAdmin, networkUser, and networkViewer.

Private Google Access for on-premises hosts is a configuration that lets private on-premises systems reach Google APIs and services without using public internet paths. Traffic flows from on-premises hosts through a Cloud VPN tunnel or Cloud Interconnect VLAN attachment into a Virtual Private Cloud (VPC) network (opens in a new tab), and then from the VPC network to Google API virtual IP (VIP) ranges. The VPC network depends on Cloud Router route advertisements, Cloud DNS name resolution, and VPC Service Controls policy to keep that traffic private and inside a defined boundary.

3.1How Private Access Keeps Hybrid Traffic Private

Private access for hybrid workloads removes the need for on-premises hosts to have external IP addresses to use Google services. Resources with only private internal addresses can still interact with key Google and Google Cloud services through Private Google Access or Private Service Connect while remaining isolated from the public internet. Private Google Access is configured per subnet, along with Cloud NAT, VPC Flow Logs, and alias IP ranges, so control is applied where the workload resides. In a hybrid design, the on-premises environment connects to one or more VPC networks by Cloud VPN or Dedicated Interconnect or Partner Interconnect. The connection method does not change the private-access model: on-premises DNS and routing must still direct Google API traffic into the VPC network rather than to the default internet gateway. Organizational policies can further restrict which resources are allowed to use external IP addresses to enforce that isolation.

3.2Advertising API Routes with Cloud Router for On-Premises Hosts

Cloud Router is the Border Gateway Protocol (BGP) speaker that exchanges routes between the VPC network and the on-premises network over Cloud VPN or Cloud Interconnect. To make Google APIs reachable from on premises, the Cloud Router advertises a custom route for the Google API VIP range back to the on-premises environment. The documentation uses the range 35.199.192.0/19 as the advertised destination that on-premises hosts use to reach Google APIs privately. The advertisement creates a return path that pulls on-premises-to-Google traffic through the tunnel or attachment instead of the internet. First the hybrid connection is established with BGP enabled, then a custom advertised route for 35.199.192.0/19 is added on the Cloud Router in the VPC network that fronts the on-premises connection, and then the on-premises router installs that route and forwards matching traffic into Google Cloud. If the dynamic routing mode of the VPC network is global, the Cloud Router applies learned routes in all subnets in the VPC network and shares routes to all VPC subnets with its on-premises counterpart. Firewall rules on both sides must still allow the API traffic and DNS traffic that supports it.

3.3Configuring Cloud DNS for Hybrid Name Resolution

Cloud DNS (opens in a new tab) provides the name resolution that steers API names to private VIP addresses and connects on-premises and Google Cloud namespaces. Cloud DNS forwarding zones query on-premises DNS servers, inbound DNS server policies allow queries from on-premises environments, and DNS peering zones forward requests within Google Cloud environments. A complete hybrid setup combines these three mechanisms so corp.example.com resolves on premises and gcp.example.com resolves in Google Cloud from either side. A single Shared VPC hybrid configuration follows an ordered sequence:

1. Make on-premises authoritative: Set up on-premises DNS servers as authoritative for corp.example.com.
2. Create Google Cloud authoritative zone: Configure an authoritative private zone, for example gcp.example.com, on Cloud DNS in the host project of the Shared VPC network.
3. Allow inbound forwarding: Set a DNS server policy on the host project to allow inbound DNS forwarding and expose inbound forwarder addresses in the Shared VPC network.
4. Forward cloud to on premises: Create a forwarding zone in the Shared VPC network that forwards corp.example.com to the on-premises DNS servers.
5. Forward on premises to cloud: Configure forwarding to gcp.example.com on the on-premises servers, pointing at the inbound forwarder IP address in the Shared VPC network.
6. Allow DNS traffic: Permit DNS traffic on the on-premises firewall and Google Cloud firewall rules.
7. Advertise API range: Add the custom advertised route for 35.199.192.0/19 on Cloud Router instances to the on-premises environment.

With multiple separate VPC networks that are not peered, the same pattern extends with DNS peering between production and development, for example a peering zone from development to production for prod.gcp.example.com and from production to development for dev.gcp.example.com. In that model the custom advertised route for 35.199.192.0/19 is added in the VPC network that holds the hybrid connection, such as the production Shared VPC network.

3.4Enforcing Data Boundaries with VPC Service Controls for Hybrid Access

VPC Service Controls is the control that places VPC resources, Google-managed services, and the on-premises network inside a service perimeter to control movement of data across the perimeter boundary. Using VPC Service Controls, projects and the on-premises network can be grouped into a single perimeter that prevents data access through Google-managed services even when private connectivity is working. The perimeter applies to API traffic that arrives over the private hybrid path, so private routing and private DNS do not bypass data-movement policy. Service perimeters cannot contain projects from different organizations, but perimeter bridges allow projects and services in different service perimeters to communicate. This boundary sits above routing and DNS: Cloud Router and Cloud DNS determine how on-premises hosts reach the API VIP, while VPC Service Controls determines whether that API call is allowed to move data across the perimeter.

Key Facts

• VPC Network Peering is bilateral and non-transitive, becoming ACTIVE only after both VPC networks create matching peering configurations toward each other.
• Custom routes across VPC Network Peering move only when the exporting network exports them and the peer network imports them, with stack type and public-IPv4 subnet-route options aligned on both sides.
• Shared VPC shares networks from a central host project with service projects in the same organization, where a project cannot be both host and service and a service project attaches to only one host.
• Shared VPC firewall rules are managed centrally in the host project, while Service Project Admins receive subnet-level or project-level permission to place instances into shared subnets.
• Private Google Access for on-premises hosts sends API traffic from on premises through Cloud VPN or Cloud Interconnect into the VPC network, requiring Cloud Router to advertise 35.199.192.0/19 and Cloud DNS to resolve API names to private VIPs.