1. Using VPC Network Peering
    1. When using VPC Network Peering to connect VPC network to another network, Google Cloud shares subnet routes between the networks
    2. The subnet routes allow traffic from the peer network to reach internal TCP/UDP load balancers in your network
    3. Access is allowed if the client virtual machine (VM) instances in the peer network are located in the same region as the internal TCP/UDP load balancer, unless global access is configured
    4. Access is allowed with global access configured, client VM instances from any region of the peered VPC network can access the internal TCP/UDP load balancer
    5. Ingress firewall rules allow traffic from client VMs in the peer network
    6. Google Cloud firewall rules are not shared among networks when using VPC Network Peering
    7. Users cannot selectively share only some of your internal TCP/UDP load balancers by using VPC Network Peering
    8. Users can limit access to the load balancer's backend VM instances by using firewall rules
  2. Using Cloud VPN and Cloud Interconnect
    1. Users can access an internal TCP/UDP load balancer from a peer network that is connected through a Cloud VPN tunnel or interconnect attachment (VLAN) for a Dedicated Interconnect connection or Partner Interconnect connection
    2. The peer network can be an on-premises network, another Google Cloud VPC network, or a virtual network hosted by a different cloud provider
  3. Access through Cloud VPN tunnels
    1. Internal TCP/UDP load balancer can be accessed through a Cloud VPN tunnel when both the Cloud VPN gateway and tunnel are located in the same region as the internal TCP/UDP load balancer's components
    2. When appropriate routes provide paths for egress traffic back to the clients from which the load balancer traffic originated.
    3. Cloud VPN tunnels that use dynamic routing rely on a Cloud Router to manage custom dynamic routes that serve this purpose
    4. Cloud VPN tunnels that use static routing require custom static routes, which are created automatically if tunnels are created by using the Google Cloud Console
    5. Ingress firewall rules allow traffic to the backend VMs, and egress firewall rules allow the backends to send responses back to the on-premises clients
    6. In the peer network, at least one Cloud VPN tunnel exists with appropriate routes whose destinations include the subnet where the internal TCP/UDP load balancer is defined and whose next hop is the VPN tunnel
    7. If the peer network is another Google Cloud VPC network, its Cloud VPN tunnel and gateway can be located in any region
    8. Clients in the peer network can connect to a Cloud VPN located in any region, provided that there is a route for the Cloud VPN tunnel on that VPN gateway to the network in which the load balancer resides
    9. For Cloud VPN tunnels that use dynamic routing, make sure that the VPC network uses global dynamic routing mode so that the custom dynamic routes learned by the Cloud Router for the tunnel are available to VMs in all regions
  4. Access through Cloud Interconnect
    1. Access an internal TCP/UDP load balancer from an on-premises peer network that is connected to the load balancer's VPC network when the interconnect attachment (VLAN) and its Cloud Router are located in the same region as the load balancer's components
    2. On-premises routers share appropriate routes that provide return paths for responses from backend VMs to the on-premises clients
    3. Interconnect attachments (VLANs) for both Dedicated Interconnect and Partner Interconnect use Cloud Routers to manage the routes they learn from on-premises routers
    4. Ingress firewall rules allow traffic to the backend VMs, and egress firewall rules allow the backend VMs to send responses
    5. Routing and firewall rules in the on-premises peer network allow communication to and from the backend VMs in your VPC network
    6. Clients in the peer network that are accessing the interconnect attachment (VLAN) and Cloud Router through which the peer network accesses the internal TCP/UDP load balancer don't need to be located in the same region as the load balancer
    7. When global access is configured, the Cloud Router can be in a region different from the load balancer's region
  5. Multiple egress paths
    1. In production environments, users probably will be using multiple tunnels or attachments for redundancy
    2. If each tunnel or each interconnect attachment (VLAN) is configured in the same region as the internal TCP/UDP load balancer, multiple simultaneously accessible paths can be provided for traffic to and from the load balancer
    3. Multiple paths can provide additional bandwidth or can serve as standby paths for redundancy
    4. Cloud VPN tunnels are always associated with a specific Cloud VPN gateway
    5. A tunnel cannot be created without a gateway
    6. Interconnect attachments (VLANs) are also associated with Cloud Interconnect connections
    7. After packets are delivered to the VPC network, the internal TCP/UDP load balancer distributes them to backend VMs according to the configured session affinity
    8. For ingress traffic to the internal TCP/UDP load balancer, the VPN tunnels must be in the same region as the load balancer