GCP VPC Peering
- GCP VPC Network Peering allows internal IP address or private connectivity across two VPC networks regardless of whether they belong to the same project or the same organization.
- VPC Network Peering enables VPC networks connection, 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 provides following advantages over using external IP addresses or VPNs to connect networks, including:
- Network Latency – connectivity uses only internal addresses and hence 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 – GCP charges egress bandwidth or outbound traffic for networks using external IPs to communicate even if the traffic is within the same zone. However, for peered networks as they use internal IPs to communicate and save on those egress costs.
- VPC Network Peering is useful in these environments:
- SaaS (Software-as-a-Service) ecosystems in Google Cloud, which can be made 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.
VPC Peering 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.
- VPC peers always exchange subnet routes that don’t use privately used public IP addresses. Networks must explicitly export privately used public IP subnet routes for other networks to use them and must explicitly import privately used public IP subnet routes to receive them from other networks.
- Subnet and static routes are global. Dynamic routes can be regional or global, depending on the VPC network’s dynamic routing mode.
- VPC network can peer with multiple VPC networks (limit of 25 currently)
- IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin role.
- 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.
- An organization policy administrator can use an organization policy to constrain which VPC networks can peer with VPC networks in the organization. Peering connections to particular VPC networks or to VPC networks in a particular folder or organization can be denied. 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.
VPC Peering 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
- 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.
- Subnet route exchange can’t be disabled or subnet routes are exchanged cannot be selected. 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. It needs to be done using firewall rules
- Transitive peering is NOT supported.
- Tags or service account from one peered network in the other peered network CANNOT be used.
- Compute Engine internal DNS names created in a network are NOT accessible to peered networks. Use the IP address instead.
- By default, VPC Network Peering with GKE is supported when used with IP aliases. If you don’t use IP aliases, custom routes can be exportedso that GKE containers are reachable from peered networks.
Google Cloud – VPC Peering