VPC Network Peering overview

Google Cloud VPC Network Peering allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks regardless of whether they belong to the same project or the same organization.

VPC Network Peering enables you to connect VPC networks so that workloads in different VPC networks can communicate internally. Traffic stays within Google's network and doesn't traverse the public internet.

VPC Network Peering is useful in these environments:

  • SaaS (Software-as-a-Service) ecosystems in Google Cloud. You can make services available privately across different VPC networks within and across organizations.
  • Organizations that have several network administrative domains that need to communicate using internal IP addresses.

If you have multiple network administrative domains within your organization, VPC Network Peering allows you to make services available across VPC networks by using internal IP addresses. If you offer services to other organizations, VPC Network Peering allows you to make those services available by using internal IP addresses to those organizations. The ability to offer services across organizations is useful if you want to offer services to other enterprises, and it is also useful if you own or control more than one organization.

VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including:

  • Network Latency: Connectivity that uses only internal addresses provides lower latency than connectivity that uses external addresses.
  • Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
  • Network Cost: Google Cloud charges egress bandwidth pricing for networks using external IPs to communicate even if the traffic is within the same zone. If however, the networks are peered they can use internal IPs to communicate and save on those egress costs. Regular network pricing still applies to all traffic.

For information about creating peering connections, see Using VPC Network Peering.

Key properties

Peered VPC networks exhibit the following key properties:

  • VPC Network Peering works with Compute Engine, GKE, and App Engine flexible environment.
  • Peered VPC networks remain administratively separate. Routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks.
  • Each side of a peering association is set up independently. Peering will be active only when the configuration from both sides matches. Either side can choose to delete the peering association at any time.
  • Peering and the option to import and export custom routes can be configured for one VPC network even before the other VPC network is created. Although route exchange only occurs after both sides have been configured.
  • VPC peers always exchange subnet routes that don't use privately reused public IP addresses. Networks must explicitly import subnet routes that use privately reused public IP addresses to receive them.
  • You can exchange custom routes (static and dynamic routes), depending on whether the peering configurations have been configured to import or export them. For more information, see Importing and exporting custom routes.
  • Subnet and static routes are global. Dynamic routes can be regional or global, depending on the VPC network's dynamic routing mode.
  • A given VPC network can peer with multiple VPC networks, but there is a limit.
  • IAM permissions for creating and deleting VPC Network Peering are included as part of the project owner, project editor, and network admin roles.
  • Peering traffic (traffic flowing between peered networks) has the same latency, throughput, and availability as private traffic in the same network.
  • Billing policy for peering traffic is the same as the billing policy for private traffic in same network.
  • If you're an organization policy administrator, you can use an organization policy to constrain which VPC networks can peer with VPC networks in your organization. You can deny peering connections to particular VPC networks or to VPC networks in a particular folder or organization. The constraint applies to new peering configurations and doesn't affect existing connections. An existing peering connection can continue to work even if a new policy denies new connections. For more information, refer to the constraints/compute.restrictVpcPeering constraint.

Restrictions

When peering with VPC networks, consider the following restrictions:

  • A subnet CIDR range in one peered VPC network cannot overlap with a static route in another peered network. This rule covers both subnet routes and static routes. Google Cloud checks for overlap in the following circumstances and generates an error when an overlap occurs.
    • When you peer VPC networks for the first time
    • When you create a static route in a peered VPC network
    • When you create a new subnet in a peered VPC network
  • A dynamic route can overlap with a subnet route in a peer network. For dynamic routes, the destination ranges that overlap with a subnet route from the peer network are silently dropped. Google Cloud uses the subnet route.
  • Only VPC networks are supported for VPC Network Peering. Peering is NOT supported for legacy networks.
  • You can't disable the subnet route exchange or select which subnet routes are exchanged. After peering is established, all resources within subnet IP addresses are accessible across directly peered networks. VPC Network Peering doesn't provide granular route controls to filter out which subnet CIDR ranges are reachable across peered networks. You must use firewall rules to filter traffic if that's required. The following types of endpoints and resources are reachable across any directly peered networks:
    • Virtual machine (VM) internal IPs in all subnets
    • Internal load balanced IPs in all subnets
  • Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
  • You cannot use a tag or service account from one peered network in the other peered network.
  • Compute Engine internal DNS names created in a network are not accessible to peered networks. Use the IP address to reach the VM instances in peered network.
  • By default, VPC Network Peering with GKE is supported when used with IP aliases. If you don't use IP aliases, you can export custom routes so that GKE containers are reachable from peered networks.

Routing order

Carefully review Routing order to learn how Google Cloud resolves route conflicts among networks in a peering group.

Importing and exporting custom routes

Subnet routes that don't use privately reused public IP addresses are always exchanged between peered networks. You can also exchange custom routes, which include static and dynamic routes, and routes for subnets that use privately reused public IP addresses if network administrators in both networks have the appropriate peering configurations.

When you import custom routes, your VPC network can receive custom routes from the peer network only if that network is exporting them. Similarly, if you export custom routes, the peer network can receive custom routes only if that network is importing them.

When you import or export custom routes, networks only exchange custom routes with direct peers. For example, if your VPC network is peered with multiple networks, routes that your network imports from one peered network aren't exported to the other peered networks.

When you create or modify a peering configuration, you can choose to import routes, export routes, or both. The peer network administrator must similarly configure their peering configuration before routes are exchanged. This process ensures that both network administrators explicitly agree to exchange custom routes before they are exchanged.

Benefits of exchanging custom routes

Sharing custom routes with peered VPC networks allow networks to learn routes directly from their peered networks. For example, if a custom route in a peered network is updated, your VPC network automatically learns and uses the updated custom route without requiring any action from you.

Exchanging custom routes can be helpful in the following scenarios:

  • If you have GKE clusters without VPC native addressing, you might have multiple static routes to direct traffic to VM instances that are hosting your containers. You can export these static routes so that the containers are reachable from peered networks.
  • If you have a VPN tunnel or interconnect, you can share custom routes so that peer networks can reach your on-premises network. For dynamic routes, you must add Cloud Router custom route advertisements in your VPC network to announce peered network subnets to your on-premises network.

Considerations

When you configure importing or exporting custom routes, consider the following behaviors:

  • At the time of peering, Google Cloud checks to see if there are any subnet IP ranges that overlap subnet IP ranges in the other network. If there is any overlap, peering is not established. This overlap check is for VPC subnet ranges only. Static and dynamic routes are not checked. If the peering goes forward, they are exported as they are.
  • Both static and dynamic routes are exported or imported. You can't choose to import or export only one type of route.
  • Custom routes imported from one VPC network can't be exported to another peered VPC network transitively.
  • The following routes are excluded from being imported and exported:
    • Tagged routes are never exchanged between peer networks. Tagged routes are custom static routes scoped to specific VM instances by using network tags. Network tags can only be resolved in the VPC network in which they're created.
    • Static routes with a next hop to the default Internet gateway are never exchanged. For example, the default route (0.0.0.0/0) with a next hop of default Internet gateway isn't exchanged between peer networks.
  • Imported routes could lead to unintended changes to traffic flow, such as changes to the routing order. For more information, see Routing order.
  • When a VPC network imports custom routes from a peer network, the destination ranges are imported as-is. However, the next hop for an imported routes is set to the name of the peering connection. Traffic is routed to the peered network where the actual next hop is defined.

Networking features in VPC Network Peering scenarios

The following sections demonstrate how VPC Network Peering behaves in certain scenarios.

Overlapping subnets at time of peering

At the time of peering, Google Cloud checks to see if there are any subnets with overlapping IP ranges between the two VPC networks or any of their peered networks. If there is an overlap, peering is not established. Since a full mesh connectivity is created between VM instances, subnets in the peered VPC networks can't have overlapping IP ranges as this would cause routing issues.

Overlapping subnet IP ranges between two peers (click to enlarge)
Overlapping subnet IP ranges between two peers (click to enlarge)

If there were any subnets with overlapping IP ranges between peers of a given VPC network, it would cause a routing conflict. For example, suppose VPC network N1 has already peered with VPC network N2, then VPC network N3 tries to peer with N2. This is an invalid peering because N3 has a subnet Subnet_5 whose IP range overlaps with Subnet_1 in network N1.

Overlapping subnet IP ranges with three peers (click to enlarge)
Overlapping subnet IP ranges with three peers (click to enlarge)

Overlapping subnets when creating or expanding subnets

When a VPC subnet is created or a subnet IP range is expanded, Google Cloud performs a check to make sure the new subnet range does not overlap with IP ranges of subnets in the same VPC network or in directly peered VPC networks. If it does, the creation or expansion action fails. For example, when a new subnet subnet_3 is created in network N2 in the following figure, the IP ranges must not overlap with the IP ranges defined in the directly peered network N1.

Subnet creation check (click to enlarge)
Subnet creation check (click to enlarge)

Google Cloud also ensures that no overlapping subnet IP ranges are allowed across VPC networks that have a peered network in common. If it does, the creation or expansion action fails. For example, when a new subnet subnet_5 is created in network N3 in the following figure, the IP ranges must not overlap with the IP ranges defined in directly peered network N2, or with network N1, because N1 is already peered with N2.

Subnet creation check with three peers (click to enlarge)
Subnet creation check with three peers (click to enlarge)

On-premises access from peer network

You can use either Cloud VPN or Cloud Interconnect to securely connect your on-premises network to your VPC network. If you export custom routes, peered VPC networks can also connect to your on-premises network. On the on-premises side, you must create routes so that traffic going to VPC networks is directed to the VPN tunnel.

HA VPN and Cloud Interconnect require dynamic routing. Classic VPN tunnels can use either static or dynamic routing; however, certain use cases of Classic VPN tunnels are deprecated.

For dynamic routing, use Cloud Router to dynamically update routes between your VPC network and your on-premises network by using the Border Gateway Protocol (BGP). Cloud Routers can learn and propagate routes within its region or for all regions within a VPC network. This behavior depends on the VPC network's dynamic routing mode, which can be regional or global.

The following use cases shows how resources in peered VPC networks are accessible after they've imported and exported custom routes. Each example shows two networks (network-a and network-b) that are peered to one another. In one example, the dynamic routing mode for network-b is regional, and in the other example it's global.

Regional dynamic routing

If you use regional dynamic routing, only resources in the same region as the Cloud Router can access the on-premises network. This restriction applies to the Cloud Router's VPC network and any peered VPC networks, regardless of the peered VPC network's dynamic routing mode. In the following example, network-b contains a VPN tunnel (which could also be an interconnect) and a Cloud Router. The dynamic routing mode of network-b is set to regional. In the peered network, subnet-a is in the same region as the Cloud Router in network-b.

After a peering connection is established, network-a can access the VPN tunnel in network-b. This access is limited to subnets that are in the same region as the Cloud Router. For example, the VM instance vm-a can reach the VPN tunnel because it's in the same region as the Cloud Router. VM instances in other regions can't reach the tunnel.

Cloud Router doesn't learn routes and propagate routes from peered VPC networks. As a result, you must have a custom route advertisement on the Cloud Router that propagates the 10.8.1.0/24 range to the on-premises network on the BGP session.

The following table summarizes the resulting routes for network-a and network-b if they both import and export custom routes:

Network Destination Next Hop Origin
network-a 0.0.0.0/0 Internet gateway local
10.8.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-to-b peer
10.10.0.0/16
(dynamic route limited to us-west1)
peering-a-to-b peer
network-b 0.0.0.0/0 Internet gateway local
10.8.2.0/24 network-b local
10.10.0.0/16
(dynamic route limited to us-west1)
vpn-b local
10.8.1.0/24 peering-b-to-a peer
10.30.0.0/16 peering-b-to-a peer

Global dynamic routing

If network-b enables global dynamic routing, resources in all regions can access the on-premises network. This applies to the Cloud Router's VPC network and any peered VPC networks, regardless of the peered VPC network's dynamic routing mode.

In the following example, resources in network-a can access the VPN tunnel in network-b, regardless of their region. For example, the VM instances vm-a1 and vm-a2 can reach the on-premises network even though vm-a2 is in a different region than the VPN tunnel.

Cloud Router must also include custom route advertisement to announce the 10.8.1.0/24 and 10.9.1.0/24 ranges to the on-premises network on the BGP session.

The following table summarizes the resulting routes for network-a and network-b if they both import and export custom routes:

Network Destination Next Hop Origin
network-a 0.0.0.0/0 Internet gateway local
10.8.1.0/24 network-a local
10.9.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-to-b peer
10.10.0.0/16
(global dynamic route)
peering-a-to-b peer
network-b 0.0.0.0/0 Internet gateway local
10.8.2.0/24 network-b local
10.10.0.0/16
(global dynamic route)
vpn-b local
10.8.1.0/24 peering-b-to-a peer
10.9.1.0/24 peering-b-to-a peer
10.30.0.0/16 peering-b-to-a peer

VPC network as a transit network

Imagine that you have a single on-premises connection, such as a VPN tunnel or interconnect, between your VPC network and on-premises network. You want to share this connection with other VPC networks so that you don't have to recreate an on-premises connection for all of the other VPC networks.

You can have other VPC networks peer with your VPC network (also known as a transit network) so that the other networks can use the on-premises connection. All peered networks can leverage the on-premises connection, but they won't be able to route traffic to another peer through the transit network.

In the following example, there are three VPC networks. network-b is peered with network-a and network-c. All networks are exporting and importing custom routes. network-b acts as the transit network, where the VPN tunnel is located.

  • By default, the Cloud Router that manages routes for tunnels connected to the Cloud VPN gateway in network-b automatically advertises the subnet IP address ranges of subnets in network-b.

  • Routes to on-premises destinations are installed as custom dynamic routes in network-b by the Cloud Router that manages routes for tunnels connected to the Cloud VPN gateway in network-b.

  • You must add the subnet IP address ranges for subnets in network-a and network-c by configuring custom route advertisements on the Cloud Router that manages routes for tunnels connected to the Cloud VPN gateway in network-b.

  • The custom dynamic routes (to on-premises destinations) are exchanged using VPC network peering to both network-a and network-c because network-b has been configured to export custom routes, and the other two networks have been configured to import them.

  • This example provides the following reachability:

    • VM instances in network-a can reach other VMs in network-b and systems in the on-premises network.
    • VM instances in network-b can reach other VMs in both network-a and network-c, as well as systems in the on-premises network.
    • VM instances in network-c can reach other VMs in network-b and systems in the on-premises network.
    • Because VPC Network Peering isn't transitive, VM instances in network-a and network-c cannot communicate with each other unless you also peer network network-a with network-c.

Internal load balancers

VM instances in peer networks can access the internal IP addresses of internal TCP/UDP load balancers in your VPC network if the following conditions are met:

  • If Global access is disabled on an internal TCP/UDP load balancer, clients must be in the same region as the load balancer. They also must be in the same VPC network as the load balancer or in a VPC network that is connected to the load balancer's VPC network by using VPC Network Peering.

  • If Global access is enabled on an internal TCP/UDP load balancer, clients can be in any region. They still must be in the same VPC network as the load balancer or in a VPC network that's connected to the load balancer's VPC network by using VPC Network Peering.

  • Ingress firewall rules that apply to the load balancer's backend VMs allow traffic from sources in peer networks. These ingress firewall rules must be created in the VPC network that contains the load balancer.

For more information, see:

Firewall rules

When you connect networks using VPC Network Peering, firewall rules are not exchanged between them. To allow ingress traffic from VM instances in a peer network, you must create ingress allow firewall rules. By default, ingress traffic to VMs is blocked by the implied deny ingress rule.

If you need to restrict access to VMs such that only other VMs in your VPC network have access, ensure that the sources for your ingress allow firewall rules only identify VMs in your VPC network, not ones from peer networks. For example, you can specify source IP ranges for just the subnets in your VPC network.

To restrict access to an internal TCP/UDP load balancer, create ingress firewall rules that apply to the load balancer's backend VMs.

Shared VPC

VPC Network Peering allows peering with a Shared VPC. A Shared VPC host project is a project that allows other projects to use one of its networks. The following diagram shows this setup.

Shared VPC with network peering (click to enlarge)
Shared VPC with network peering (click to enlarge)

Network-SVPC is in a Shared VPC network in host project P1. Service projects P3 and P4 are able to attach VM instances to Network-SVPC. Network-SVPC peers with Network-A. As a result:

  • VM instances in Shared VPC service projects that are using the Network-SVPC (VM3 and VM4) have private, internal IP connectivity with any endpoints associated to Network-A.
  • VM instances associated to network-A will have private, internal IP connectivity with any endpoints associated to Network-SVPC, regardless of whether those endpoints live in the host project or in a service project.

It is possible to set up VPC Network Peering between two Shared VPC networks.

Multiple network interfaces per VM instance

A VM instance can have multiple network interfaces, one per VPC network. For those instances, Google Cloud assigns destination-based IP routes, where each interface gets a route from the subnet that it is in. Additionally, Google Cloud provides a default route to the primary network interface. With destination-based routing, any traffic that's not destined to any of the instance's subnets egresses from the primary network interface. For more information, see DHCP behavior with multiple network interfaces.

When you have peer networks that include VM instances with multiple network interfaces, you might need to change the default destination-based routing policy to a source-based routing policy. For more information, see Configuring policy routing.

The following scenarios demonstrate when a VM instance might or might not require a source-based routing policy

Routing policy required

In the following example, vm1 requires a source-based routing policy so that vm1 and vm2 can successfully communicate. Without a routing policy, all traffic egresses through vm1-nic0 to network-a unless traffic is destined to subnet-b where nic1 is located. This means that traffic from vm1 destined to network-c is dropped or sent to the incorrect destination because the VM instance always sends traffic out of its primary interface.

Routing policy requirement depends on subnet IP ranges

In the following example, the primary network interface of vm1 is in a network that is peered with another network. You don't need to configure policy routing on vm1.

In the following example, vm1-nic1 and vm2-nic0 are in overlapping subnets. When peering is established, Google Cloud checks for overlapping IP ranges only between peers and not between other networks where instances contain network interfaces. To ensures that communication between vm1 and vm2 works, you must add a source-based routing policy on vm1-nic0.

Peering between interfaces

The following example shows a VM instance with multiple network interfaces, where each one is in a network that's peered with each other. In this case, vm1 doesn't require a source-based routing policy. Traffic leaving the VM instance to each subnet uses the corresponding network interface.

If vm1 sends traffic to the IP address of vm2-nic1, traffic goes into nic1 but egresses out of nic0. Similarly, if vm3 sends traffic to the IP address of vm2-nic0, traffic goes into nic0 but egresses out of nic1.

Subnet secondary ranges

A subnet has a single primary IP address range and, optionally, one or more secondary IP address ranges. For each subnet IP address range, Google Cloud creates a subnet route. When you use VPC Network Peering, Google Cloud always exchanges the subnet routes that don't use privately reused public IP addresses between the two peered networks. If firewall rules in each network permit communication, VM instances in one network can communicate with instances in the peered network.

When you establish a peering relationship, Google Cloud checks that a subnet's primary and secondary ranges don't overlap with other ranges in peered networks.

What's next