VPC Network Peering

Google Cloud Platform (GCP) Virtual Private Cloud (VPC) Network Peering allows private RFC 1918 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 RFC 1918 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 RFC 1918 space. If you offer services to other organizations, VPC Network Peering allows you to make those services available in private RFC 1918 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, 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 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 subnet CIDR range in one peered VPC network cannot overlap a route in another peered network. This rule covers both subnet routes and custom routes. GCP 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
  • 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 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 TCP/UDP Load Balancing

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:

  • The VMs are located in the same region as the internal TCP/UDP load balancer.
  • 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.

Refer to using VPC Network Peering for additional information.

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 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.
¿Te sirvió esta página? Envíanos tu opinión: