VPC Network Peering

Google Cloud Platform (GCP) Virtual Private Cloud (VPC) Network Peering allows private RFC1918 connectivity across two VPC networks regardless of whether or not they belong to the same project or the same organization.

Overview

VPC Network Peering allows you to build SaaS (Software-as-a-Service) ecosystems in GCP, making services available privately across different VPC networks within and across organizations, allowing workloads to communicate in private RFC1918 space.

VPC Network Peering is useful for:

  • Organizations with several network administrative domains.
  • Organizations that want to peer with other organizations.

If you have multiple network administrative domains within your organization, VPC Network Peering allows you to make services available across VPC networks in private RFC1918 space. If you offer services to other organizations, VPC Network Peering allows you to make those services available in private RFC1918 space to those organizations. The ability to offer services across organizations is useful if you want to offer services to other enterprises, and it is useful within your own enterprise if you have several distinct organization nodes due to your own structure or as a result of mergers or acquisitions.

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

  • Network Latency: Public IP networking suffers higher latency than private networking.
  • Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
  • Network Cost: GCP 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.

Key Properties

Peered VPC networks exhibit the following key properties:

  • VPC Network Peering works with Compute Engine 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 can be configured for one VPC network even before the other VPC network is created.
  • A given VPC network can peer with multiple VPC networks, but there is a limit.
  • A subnet CIDR prefix in one peered VPC network cannot overlap with a subnet CIDR prefix in another peered network. This means that two auto mode VPC networks that only have the default subnets cannot peer. GCP checks for overlap in the following circumstances:
    • When you peer VPC networks for the first time
    • When you create a new subnet in a peered VPC network
  • A route CIDR range in one peered VPC network cannot overlap with a subnet CIDR range in another peered network. GCP checks for overlap in the following circumstances:
    • When you peer VPC networks for the first time
    • When you create a route in a peered VPC network
    • When you create a new subnet in a peered VPC network
  • Only VPC networks are supported for VPC Network Peering. Peering is NOT supported for legacy networks.
  • IAM Permissions: There are new IAM permissions for creating and deleting VPC Network Peering. These permissions are included in the Project owner/editor and Network admin roles.
  • Once networks have peered, every internal, private IP is accessible across peered networks. VPC Network Peering does not provide granular route controls to filter out which subnet CIDRs are reachable across peered networks. You must use firewall rules to filter traffic if such filtering is needed. The following types of endpoints/resources are reachable across directly peered networks:
    • Virtual machine (VM) internal IPs in all subnets
    • Internal load balanced IPs in all subnets
  • The following types of endpoints/resources are NOT propagated to directly peered networks:
    • Static routes
    • VPNs
  • 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 also directly connected, VPC network N2 cannot communicate with VPC network N3 over the peering.
  • 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 remains unchanged from billing policy for private traffic in same network.

Networking features in VPC Network Peering scenarios

Internal Load Balancing

For Internal Load Balancing across peered networks, forwarding rules based on Internal Load Balancing in one network will be installed automatically on VM instances in peered network also. You do not have to add any extra configuration for this. The figure below describes how VM instances in network-B access the load balanced backends in network-A. The Internal Load Balancing configuration from network-A is automatically applied to network-B in this case. Internal Load Balancing services are available to clients in directly peered networks only. That is, in the case that network-B peers with network-C, the Internal load balanced backends in network-A will not be reachable from clients in network-C.

Internal Load Balancing with VPC Network Peering (click to enlarge)
Internal Load Balancing with VPC Network Peering (click to enlarge)

Firewall

Firewall rules are not imported into peered networks. You can configure firewall rules in each network separately to control the traffic you want to allow or block from peered networks.

If you have peering between your VPC network and another VPC network, you may want to block traffic to a given set of VM instances or Internal Load Balancing endpoints. You must use firewall rules to do this as there is no way to exclude certain VM instances or Internal load balancers from the peering. If you want to disallow communication with certain VM instances or Internal load balancers, you can install ingress firewall rules on the network you want to block the communication to.

  • VM instances: In this case, you can install an ingress firewall that only allows traffic from certain source IPs. These source IPs can map to the subnet CIDRs in your own VPC network. This blocks any traffic originating from the peered VPC networks.
Firewall with VPC network peering (click to enlarge)
Firewall with VPC network peering (click to enlarge)
  • Internal load balancers: In this case, you can install ingress firewall rules in the VPC network with the Internal load balancer. These source IPs can map to all or part of the subnet CIDRs in the your own network. If ingress firewall rules are put in place for all subnet CIDR ranges in the peered network, then no instance in that network would be able to reach the Internal load balancer 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 the project where they live, whether is the host project or a service project.

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

Multiple Network Interfaces per instance

An instance can have multiple network interfaces, one each in different VPC networks.

The following diagram shows a situation where we can see the interplay between the two features. In this case, VM1 has a network interface in both network-A and network-B. network-B is peered with another Network-C.

Multiple network interfaces with network peering (click to enlarge)
Multiple network interfaces with network peering (click to enlarge)

IP3 can send traffic to IP2 because IP2 is in Network-B, and Network-B routes are automatically propagated to Network-C when the two networks are peered. For IP2 to send traffic to IP3, however, you need to configure policy routing for the IP2 interface.

Flows for IP1 are not installed in Network-C. Hence Network-C cannot access IP1.

IP Aliasing

With IP Aliasing, a subnet can have primary and secondary IP ranges. The VM instances in such a subnet can get one IP from the primary range and one or more from the secondary range.

With Cloud VPC Peering, both primary and secondary IP ranges of a subnet are reachable by VM instances in the peered network.

Subnet overlap checks across peered networks ensure that primary and secondary ranges do not overlap with any peered ranges.

IP aliasing with network peering (click to enlarge)
IP aliasing with network peering (click to enlarge)

What's next

  • See Using VPC Network Peering for instructions on setting up VPC Network Peering as well as restrictions and troubleshooting.

Send feedback about...