Private services access
Google and third parties (together known as service producers) can offer services with internal IP addresses that are hosted in a VPC network. Private services access enables you to reach those internal IP addresses. This is useful if you want your VM instances in your VPC network to use internal IP addresses instead of external IP addresses. For details about using private services access, see Configuring private services access.
Private services access requires you to first allocate an internal IPv4 address range and then create a private connection. An allocated range is a reserved CIDR block that can't be used in your local VPC network. It's set aside for service producers only and prevents overlap between your VPC network and the service producer's VPC network.
The private connection links your VPC network with the service producer's VPC network. This connection allows VM instances in your VPC network to use internal IPv4 addresses to reach the service resources. Your instances can have external IP addresses, but external IP addresses are not required for, and are not used by, private services access.
If a service producer offers multiple services, you only need one private connection. When you create a private connection, you use the Service Networking API to create it. However, Google Cloud implements this connection as a VPC Network Peering connection between your VPC network and the service producer's VPC network. Your VPC network shows it as a peering connection, and to delete the private connection, you must delete the peering connection.
Using IPv6 address ranges with private services access is not supported.
You can use private services access only with services that support it. Check with the service producer before creating a private connection.
Service producer network
On the service producer's side of the private connection is a VPC network, where your service resources are provisioned. The service producer's network is created exclusively for you and contains only your resources.
A resource in the service producer network is similar to other resources in your VPC network. For example, it's reachable through internal IP addresses by other resources in your VPC network. You can also create firewall rules in your VPC network to control access to the service producer's network.
For details about the service producer side, see Enabling private services access in the Service Infrastructure documentation. This documentation is for your information only and is not required for you to enable or use private services access.
Private services access and on-premises connectivity
In hybrid networking scenarios, an on-premises network is connected to a VPC network either through a Cloud VPN or Cloud Interconnect connection. By default, on-premises hosts can't reach the service producer's network by using private services access.
In the VPC network, you might have custom static or dynamic routes to correctly direct traffic to your on-premises network. However, the service producer's network doesn't contain those same routes. When you create a private connection, the VPC network and service producer network exchange subnet routes only.
The service producer's network contains a default route (
goes to the internet. If you export a default route to the service producer's
network, it is ignored because the service producer network's default route
takes precedence. Instead, define and export a custom route with a more specific
destination. For more information, see Routing
You must export the VPC network's custom routes so that the service provider's network can import them and correctly route traffic to your on-premises network. Update the VPC peering configuration associated with the private connection to export custom routes.
The following Google services support private services access:
- AI Platform Training
- Cloud Build
- Cloud Intrusion Detection System
- Cloud SQL (does not support DNS peering)
- Cloud TPU
- Google Cloud VMware Engine
- Memorystore for Memcached
- Memorystore for Redis
- NetApp Cloud Volumes Service
- Vertex AI
In the following example, the customer VPC network allocated the
address range for Google services and established a private connection that uses
the allocated range. Each Google service creates a subnet from the allocated
block to provision new resources in a given region, such as Cloud SQL
- The private connection is assigned the
10.240.0.0/16allocated range. From this allocation, Google services can create subnets where new resources are provisioned.
- On the Google services side of the private connection, Google creates a project for the customer. The project is isolated, meaning no other customers share it and the customer is billed for only the resources the customer provisions.
- Each Google service creates a subnet in which to provision resources. The
subnet's IP address range is a CIDR block that comes from the allocated IP
address range. The CIDR block is chosen by the service, and typically has a
/24IP address range. You cannot modify the service producer's subnet. A service provisions new resources in existing regional subnets that were previously created by that service. If a subnet is full, the service creates a new subnet in the same region.
- VM instances in the customer's network can access service resources in any region if the service supports it. Some services might not support cross-region communication. See the relevant service's documentation for more information.
- Egress costs for cross-regional traffic, where a VM instance communicates with resources in a different region, still apply.
- The Cloud SQL instance is assigned the IP address
10.240.0.2. In the Customer VPC network, requests with a destination of
10.240.0.2are routed to the private connection over to the service producer's network. After reaching the service network, the service network contains routes that direct the request to the correct resource.
- Traffic between VPC networks travels internally within Google's network, not through the public internet.
- To configure private services access, see Configuring private services access.