thesaravanakumar/vpc_peering.md

## vpc_peering.md

      
    Raw
  

              vpc_peering.md
            
          
VPC Network Peering

Google Cloud VPC Network Peering allows internal IP address connectivity across two VPC networks regardless of whether they belong to the same project or the same organization. Traffic stays within Google's network and doesn't traverse the public internet.
VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including:

Network Latency
Network Security
Network Cost

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.

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.
Peering will be active only when the configuration from both sides matches. independent
VPC peers always exchange subnet routes that don't use privately used public IP addresses.
You can exchange custom routes (static and dynamic routes), depending on whether the peering configurations have been configured to import or export them.
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 25.
IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin (roles/compute.networkAdmin) role.

Restrictions


VPC Network Peering supports IPv4 connectivity only.
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.

The following types of endpoints and resources are reachable across any directly peered networks:


Virtual machine (VM) internal IP addresses in all subnets


Internal load balancer IP addresses 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.


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.


Creating peer connections