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.

Before you begin

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.

VPC Network Peering setup

Within the same organization node, a network could be hosting services that need to be accessible from other VPC networks in a same or different projects.

Alternatively, one organization may want to access services offered by other organizations. This is the case in third-party services offering.

Project names are unique across all of GCP, so you do not need to specify the organization when setting up peering. GCP knows the organization based on the project name.

Setting up a VPC Network Peering session

Consider an organization-A which needs VPC Network Peering to be established between network-A in project-A and network-B in project-B. In order for VPC Network Peering to be established successfully, administrators of network-A and network-B must separately configure the peering association.

Step 1: Peer network-A with network-B

A user with appropriate IAM permissions in project-A configures network-A to peer with network-B. This work is typically done by a Network admin.

Peering from network-A to network-B (click to enlarge)
Peering from network-A to network-B (click to enlarge)

Before you begin, you will need the project IDs and network names of the networks you want to peer.

Console

  1. Go to the VPC Network Peering page in the Google Cloud Platform Console.
    Go to the VPC Network Peering page
  2. Click Create connection.
  3. Click Continue.
  4. Enter a Name of peer-ab for this side of the connection.
  5. Under Your VPC network, select the network you want to peer.
  6. Set the Peering VPC network radio buttons to In another project, unless you wish to peer within the same project.
  7. Specify the Project ID of the other project.
  8. Specify VPC network name of the other network.
  9. Click Create.

gcloud

gcloud compute networks peerings create peer-ab \
    --network network-A \
    --peer-project project-B \
    --peer-network network-B \
    --auto-create-routes

At this point, the peering state remains INACTIVE because there is no matching configuration in network-B in project-B.

Console

  1. Go to the VPC Network Peering page in the Google Cloud Platform Console.
    Go to the VPC Network Peering page
  2. Status says "Waiting for peer network to connect."

gcloud

gcloud compute networks peerings list --network network-A

NAME      NETWORK   PEER_PROJECT PEER_NETWORK AUTO_CREATE_ROUTES STATE    STATE_DETAILS
peer-ab   network-A project-B    network-B    True               INACTIVE The peering network has not been configured.

Step 2: Peer network-B with network-A

A NetworkAdmin, or a user with appropriate IAM permissions, in project-B must configure the matching configuration from network-B to network-A in order for the peering to become ACTIVE on both ends.

Peering from network-B to network-A (click to enlarge)
Peering from network-A to network-B (click to enlarge)

Console

  1. Go to the VPC Network Peering page in the Google Cloud Platform Console.
    Go to the VPC Network Peering page
  2. Click Create connection.
  3. Click Continue.
  4. Enter a Name of peer-ba for this side of the connection.
  5. Under Your VPC network, select the network you want to peer.
  6. Set the Peering VPC network radio buttons to In another project, unless you wish to peer within the same project.
  7. Specify the Project ID of the other project.
  8. Specify VPC network name of the other network.
  9. Click Create.

gcloud

gcloud compute networks peerings create peer-ba \
     --network network-B \
     --peer-project project-A \
     --peer-network network-A \
     --auto-create-routes

Step 3: VPC Network Peering becomes ACTIVE and routes are exchanged

As soon as the peering moves to an ACTIVE state, traffic flows are set up:

  • Between VM instances in the peered networks: Full mesh connectivity.
  • From VM instances in one network to Internal Load Balancing endpoints in the peered network
Peering ACTIVE (click to enlarge)
Peering ACTIVE (click to enlarge)

Console

  1. Go to the VPC Network Peering page in the Google Cloud Platform Console.
    Go to the VPC Network Peering page
  2. Status says "Connected."
  3. Go to the VPC Network Peering page in the other project to see that it also says "Connected."

gcloud

gcloud compute networks peerings list --network network-A

NAME     NETWORK     PEER_PROJECT PEER_NETWORK AUTO_CREATE_ROUTES STATE    STATE_DETAILS
peer-ab  network-A   project-B   network-B    True                ACTIVE   The peering became ACTIVE at 2016-06-08T15:10:14.111-07:00.

gcloud compute networks peerings list --network network-B

NAME     NETWORK     PEER_PROJECT PEER_NETWORK AUTO_CREATE_ROUTES STATE    STATE_DETAILS
peer-ba  network-B   project-A    network-A    True               ACTIVE   The peering became ACTIVE at 2016-06-08T15:10:14.111-07:00.

The routes to peered network CIDR prefixes are now visible across the VPC network peers. These routes are implicit routes generated for active peerings. They don't have corresponding route resources. The following command lists routes for all VPC networks for project-A.

Console

  1. Go to the Routes page in the Google Cloud Platform Console.
    Go to the Routes page

gcloud

gcloud compute routes list --project project-A

NAME                              NETWORK    DEST_RANGE     NEXT_HOP                  PRIORITY
default-route-2a865a00fa31d5df    network-A  0.0.0.0/0      default-internet-gateway  1000
default-route-8af4732e693eae27    network-A  10.0.0.0/16                              1000
peering-route-4732ee69e3ecab41    network-A  10.8.0.0/16    peer-ab                   1000

Deleting a VPC Network Peering session

Either side can remove the peering configuration. This makes the peering INACTIVE again, and all the routes to the peer network will be removed. In this example, peering configuration is removed from network-A.

Console

  1. Go to the VPC Network Peering page in the Google Cloud Platform Console.
    Go to the VPC Network Peering page
  2. Select the checkbox next to the peering you want to remove.
  3. Click Delete.

gcloud

gcloud compute networks peerings delete peer-ab --network network-A

When one end of a network peering session is deleted, peering at the other end becomes INACTIVE.

Peering VPC networks across organizations

Consider the scenario in which VM instances in project-A/network-A need to access services from two different external organizations: SaaS1 and SaaS2. In order to access those via RFC1918 space, network-A must peer with SaaS1 project-B/network-B and SaaS2 project-C/network-C where the services are hosted.

Cross-organization peering (click to enlarge)
Cross-organization peering (click to enlarge)

To create this setup, simply create two different peering sessions.

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)

Restrictions

No subnet IP range overlap across peered VPC networks

No subnet IP range can overlap with another subnet IP range in a peered VPC network.

Checks performed at VPC Network Peering setup

At the time of peering, GCP 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)

Checks performed at subnet creation in VPC Network Peering scenarios

When a VPC subnet is created or a subnet IP range is expanded, GCP 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)

GCP 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)

Legacy networks are not supported in VPC Network Peering

Legacy Networks are networks that do not have subnets. Legacy networks cannot peer with any other networks and are not supported in VPC Network Peering.

VPNs not reachable across peered networks

VPN in a network can't be reached from a peered network.

No Compute Engine DNS across projects

Compute Engine internal DNS names created in a network are not accessible to peered networks. The IP address of the VM should be used to reach the VM instances in peered network.

User-configured routes are not propagated across peered networks

User-configured routes are not propagated across peered networks. If you configure a route in a network to a destination in a VPC network, such a destination will not be reachable from a peered network.

Container Engine with VPC Network Peering

VPC Network Peering with Container Engine is supported when used with IP Aliases. Kubernetes Services, if exposed via Internal Load Balancing, and Pod IPs are reachable across VPC networks.

Limits

Number of peerings limit

A network can have up to 25 directly peered networks in total. This total includes both active and inactive peerings.

VPC Network Peering VM instances limit

A VPC network can have up to 7500 instances in itself and all directly peered VPC networks.

Each network has a "peering instance limit." This is a limit to the number of instances that can be in the network and in all directly peered networks combined.

VPC Network Peering Internal Load Balancing forwarding rules limit

The per-network limit is 50. In other words, the number of forwarding rules in a network and all its directly peered networks cannot exceed this limit.

Each network has a "peering Internal Load Balancing forwarding rule limit." This is a limit to the number of Internal Load Balancing forwarding rules that can be in the network and in all directly peered networks combined.

Troubleshooting

Q: My peering connection is set up, but I am not able to reach peer VMs or internal load balancers.

After the peering connection is ACTIVE, it may take up to a minute for all the traffic flows to be set up between the peered VPC networks. This time depends on the size of the VPC networks that are peering. If you have just set up the peering connection, please wait up to a minute and try again. Also, ensure that there are no firewall rules blocking access to/from peer VPC network subnet CIDRs.

Q: When I try to set up the peering connection, I get an error that another peering operation is in progress.

In order to avoid contention with routing updates and the like, GCP allows only one peering-related activity at a time across peered networks. For example, if you set up peering with one network and immediately try to set up another, all the tasks from the first peering may not have completed. It may take up to a minute for all tasks to complete. Alternatively, your existing network peer may be adding an internal load balancer or VM, both of which affect what is reachable between networks. In most cases, you should wait a minute or two and retry the peering operation.

Q: When I try to delete a VPC network with ACTIVE peerings, I get an error.

[Delete](/sdk/gcloud/reference/compute/networks/peerings/delete) your side of the peering connection and retry.

Q: The VPC networks that I am trying to peer have overlapping subnet CIDRs. Is there anything I can do to make this work?

No. You will have to change your VPC networks such that the subnet CIDRs are non-overlapping

Q: I have a VPC network that is peered with another network. I want to create a subnet in my VPC network. How do I create this subnet so that it does not overlap with my peer VPC network?

Please look at the peering routes that point to your peer VPC network as the next hop. These routes represent the list of subnet CIDRs in your peer VPC network. Please choose a CIDR that does not overlap with your existing subnet CIDRs and your peer VPC network's subnet CIDRs

Q: I have a VPC network that is peered with another VPC network. I want to create a subnet in my VPC network. How do I create this subnet so that it does not overlap with my peer's peer VPC networks?

At this time, there is no command that helps you to find this. Please ask the admin of the peered network to find out what subnet routes are already in that network.

Q: Are there any security or privacy concerns with VPC peering?

After peering is set up, each VPC network knows the subnet ranges of the other network. In addition, each peer VPC network is able to send and receive traffic from the all VMs in the other network unless firewall rules are in place to prevent it. Other than that, peered networks do not have visibility into each other.

Q: Can I see if there are VPC peering requests by other VPC networks for my network?

No. VPC peering works on a bi-directional basis. You set up peering from your side and your peer sets it up from their side. You only have visibility into the VPC peering requests that you have set up.

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Compute Engine Documentation