Google provides several different private access options. Each option allows VM instances with internal (RFC 1918) IP addresses to reach certain APIs and services. Choose an option that supports the APIs and services that you need to access.
The following table summarizes each option. You can configure one or all of these options. They operate independently of each other.
|Private Google Access|
|GCP VM instances require only internal IP addresses and can't have external IP addresses.||Connect to the public IP addresses of Google APIs and services through the VPC network's default Internet gateway.||Supports most Google APIs and services||Use this option to connect to Google APIs and services without giving your GCP resources external IP addresses.|
|Private Google Access for on-premises hosts|
|On-premises hosts require an internal IP address. Hosts can have external IP addresses.||Connect to the public IP addresses of Google APIs and services through a VPN tunnel or interconnect by using a restricted IP address range.||Google services that support the restricted Google IP address range||Use this option to connect to Google APIs and services through a VPC network. This method doesn't require your on-premises hosts to have external IP addresses.|
|Private services access|
|GCP VM instances require an internal IP address. Instances can have external IP addresses.||Connect to a Google or third-party managed VPC network through a VPC Network Peering connection.||Supports some Google or third-party services||Use this option to connect to specific Google and third-party services without assigning external IP addresses to your GCP and Google or third-party resources.|
|Serverless VPC Access|
|GCP VM instances require an internal IP address. Instances can have external IP addresses.||Connect directly from serverless Google services through an internal VPC connection.||App Engine standard environment and Cloud Functions||Use this option to connect from the App Engine standard environment and Cloud Functions directly to resources in a VPC network using internal IP addresses.|
Private Google Access
VM instances that only have internal IP addresses (no external IP addresses) can use Private Google Access. They can reach the external IP addresses of Google APIs and services. The source IP address of the packet can be the primary internal IP address of the network interface or any alias IP address that is assigned to the interface. If you disable Private Google Access, the VM instances can no longer reach Google APIs and service; they can only send traffic within the VPC network.
Private Google Access has no effect on instances that have external IP addresses. Instances with external IP addresses can access the Internet, according to the Internet access requirements. They don't need any special configuration to send requests to the external IP addresses of Google APIs and services.
You enable Private Google Access on a subnet by subnet basis; it's a setting for subnets in a VPC network. To enable a subnet for Private Google Access and to view the requirements, see Configuring Private Google Access.
Private Google Access permits access to Cloud and Developer APIs and most GCP services, except for the following services:
- App Engine Memcache
- Cloud Filestore
- Cloud Memorystore
- Cloud SQL
Instead, private services access might support one or more of them.
The VPC network in the following example meets the routing
Private Google Access
because it has routes to the public IP addresses for Google APIs and services
whose next hops are the default Internet gateway. Private Google Access is
but not for
The following list provides details about the above diagram:
- Firewall rules in
the VPC network allow egress to
0.0.0.0/0(or at least to the server IPs for Google APIs and services).
VM A1can access Google APIs and services, including Cloud Storage, because its network interface is located in
subnet-a, which has Private Google Access enabled. Private Google Access applies to the instance because it only has an internal IP address.
VM B1cannot access Google APIs and services because it only has an internal IP address and Private Google Access is disabled for
VM B2can both access Google APIs and services, including Cloud Storage, because they each have external IP addresses. Private Google Access has no effect on whether or not these instances can access Google APIs and services because both have external IP addresses.
Private Google Access for on-premises hosts
On-premises hosts can reach Google APIs and services over a Cloud VPN or Cloud Interconnect connection from your data center to GCP. On-premises hosts don't need external IP addresses; instead, they use internal RFC 1918 IP addresses.
To enable Private Google Access for on-premises hosts, you must configure
DNS, firewall rules, and routes in your on-premises and VPC
networks. You don't need to enable Private Google Access for any subnets in
your VPC network as you would for Private Google Access for
GCP VM instances. However, within your VPC
network, you must have a route with at least a destination of
and a next hop being the default Internet gateway. Even though the next hop is
called "default Internet gateway," traffic sent to
within Google's network instead of traversing the public Internet because Google
does not publish routes to
For on-premises hosts, requests to Google APIs and services must be sent to
restricted.googleapis.com. This is a restricted VIP (virtual IP address
range) provided by a DNS A record that Google publishes publicly. Even though
its range is
18.104.22.168/30, Google does not publish those routes. Hence,
you must add a custom route on a Cloud Router and have an appropriate
route in your VPC for the
For on-premises hosts to reach the restricted range, requests must be sent through a VPN tunnel or interconnect. Use Cloud Router to dynamically announce the restricted range. For more information, see Configuring Private Google Access for On-premises Hosts.
Private Google Access for on-premises hosts supports a subset of services compared to Private Google Access. Only Google APIs and services that support the restricted VIP are supported. For a list of supported services, refer to Supported services in the VPC Service Controls documentation.
In the following example, the on-premises network is connected to a
VPC network through a Cloud VPN tunnel. Traffic from
on-premises hosts to Google APIs travels through the tunnel to the
VPC network. After traffic reaches the VPC
network, it is sent through a route that uses the default Internet gateway as
its next hop. This next hop allows traffic to leave the VPC
network and be delivered to the restricted IP range for Google APIs and
- The on-premises DNS configuration maps
restricted.googleapis.com, which resolves to the
- Cloud Router advertises the
22.214.171.124/30IP address range through the VPN tunnel. Traffic going to Google APIs is routed through the tunnel to the VPC network.
- The VPC network includes a route that directs traffic with the
126.96.36.199/30to the default Internet gateway (as the next hop). Google then routes traffic to the appropriate API or service.
- If you use Cloud DNS to configure a private DNS zone in your network, all requests to Google APIs map to the restricted range. Only the supported APIs are accessible with this configuration, which might cause other services to be unreachable. Cloud DNS doesn't support partial overrides. If you require partial overrides, use BIND.
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 IP 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. When you create a private connection, you must specify an allocation.
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 IP addresses to reach the service resources that have internal IP addresses. Your instances can have external IP addresses, but external IP addresses are not required for, and 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, GCP implements this connection as a VPC Network Peering connection between your VPC network and the service producer's VPC network. For example, your VPC network shows it as a peering connection, and to delete the private connection, you must delete the peering connection.
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 resource 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.
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.
To export custom routes, you must create a private connection and then modify the underlying VPC peering configuration to export custom routes. For information about creating a private connection, see Configuring Private Services Access. For information about exporting custom routes, see Updating a peering connection.
The following Google services support private services access:
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 typically a
/24CIDR block that is chosen by the service and comes from the allocated IP 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. For example, VM instances can only communicate with Cloud SQL instances that are in the same region. View 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.
Serverless VPC Access
Serverless VPC Access enables you to connect from the App Engine standard environment and Cloud Functions directly to your VPC network. This connection makes it possible for your App Engine standard environment apps and Cloud Functions to access resources in your VPC network via internal IP addresses.
With Serverless VPC Access, you create a connector in your GCP project and attach it to a VPC network. You then configure your serverless services (such as App Engine apps or Cloud Functions) to use this connector for internal network traffic.
Serverless VPC Access only allows your app or function to send requests to resources in your VPC network and receive responses to those requests. Communication in the opposite direction, where a VM initiates a request to an app or function, requires you to use the public address of the app or function—see Private Google Access for more information.
The following Google services support Serverless VPC Access connectors:
- App Engine standard environment
- All runtimes except PHP 5.5 and Go 1.9
- Cloud Functions
In the following example, an App Engine standard environment app and Cloud Functions use a Serverless VPC Access connector to send requests to internal resources in the VPC network.
- The Serverless VPC Access connector is in the same project and region as the App Engine app and Cloud Functions.
- The connector is attached to the VPC network that contains the destination resources. The connector can access resources in other VPC networks and GCP projects if you use VPC Network Peering.
- The connector is assigned the IP range
10.8.0.0/28. Requests sent from the connector to the destination have a source IP address in this range.
- The App Engine app and Cloud Functions reach the destination
resources by sending requests to their internal IP addresses,
10.1.0.2. The destination resources can be in any region. Egress costs apply to traffic sent from the connector to a resource in a different region.
- Requests sent from App Engine and Cloud Functions to internal (private) IP addresses travel internally through the Serverless VPC Access connector to the destination resource. Requests sent to external (public) IP addresses travel through the public internet.
- To configure Private Google Access see Configuring Private Google Access.
- To configure Private Google Access for on-premises hosts, Configuring Private Google Access for on-premises hosts.
- To configure private services access, see Configuring Private Services Access.
- To configure Serverless VPC Access, see Configuring Serverless VPC Access.