Private access options for services

Google Cloud provides several private access options. Each option allows virtual machine (VM) instances that have internal 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.

Option Clients Connection Supported services Usage
Private Google Access
Google Cloud VM instances without external IP addresses. Connect to the standard external IP addresses or Private Google Access domains and VIPs for Google APIs and services through the Virtual Private Cloud (VPC) network's default internet gateway. Supports most Google APIs and services. Also supports access to App Engine applications. Use this option to connect to Google APIs and services without giving your Google Cloud resources external IP addresses.
Private Google Access for on-premises hosts
On-premises hosts with or without external IP addresses. Connect to Google APIs and services, from your on-premises network, through a Cloud VPN tunnel or Cloud Interconnect by using one of the Private Google Access-specific domains and VIPs. The Google services that you can access depend on which Private Google Access-specific domain you use. 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
Google Cloud VM instances with or without 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 Google Cloud and Google or third-party resources.
Serverless VPC Access
Google Cloud VM instances with or without external IP addresses. Connect directly from serverless Google services through an internal VPC connection. Cloud Run (fully managed), App Engine standard environment, and Cloud Functions Use this option to connect from a serverless environment on Google Cloud 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 an address in an alias IP range that is assigned to the interface. If you disable Private Google Access, the VM instances can no longer reach Google APIs and services; 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.

Supported services

Private Google Access permits access to Cloud and Developer APIs and most Google Cloud services, except for the following services:

  • App Engine Memcache
  • Filestore
  • Memorystore

Instead, private services access might support one or more of them.

Example

The VPC network in the following example meets the routing requirement for Private Google Access because it has routes to the external IP addresses for Google APIs and services whose next hops are the default internet gateway. Private Google Access is enabled for subnet-a but not for subnet-b.

Implementation of Private Google Access (click to enlarge)

The following list provides details about the above diagram:

  • Firewall rules in the VPC network have been configured to allow egress to 0.0.0.0/0 (or at least to the server IPs for Google APIs and services).
  • VM A1 can 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 B1 cannot access Google APIs and services because it only has an internal IP address and Private Google Access is disabled for subnet-b.
  • VM A2 and VM B2 can 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 by using Cloud VPN or Cloud Interconnect from your on-premises network to Google Cloud. On-premises hosts can send traffic from the following types of source IP addresses:

  • a private IP address, such as an RFC 1918 address
  • a privately used public IP address, except for a Google-owned public IP address. (Private Google Access for on-premises hosts does not support re-using Google public IP addresses as sources in your on-premises network.)

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 Google Cloud VM instances.

On-premises hosts must connect to Google APIs and services by using the virtual IP addresses (VIPs) for either the restricted.googleapis.com or private.googleapis.com domains. Refer to Private Google Access-specific domains and VIPs for more details.

Google publicly publishes DNS A records that resolve the domains to a VIP range. Even though the ranges have external IP addresses, Google does not publish routes for them. Therefore, you must add a custom route advertisement on a Cloud Router and have an appropriate custom static route in your VPC network for the VIP's destination.

The route must have a destination matching one of the VIP ranges and a next hop being the default internet gateway. Traffic sent to the VIP range stays within Google's network instead of traversing the public internet because Google does not publish routes to them externally.

For configuration information, refer to Configuring Private Google Access for On-premises Hosts.

Private Google Access-specific domains and VIPs

The following table describes the domain names and their VIP range. You must use one of these VIPs for Private Google Access for on-premises hosts.

Domain and IP address ranges Supported services Example usage
Default domains

All domain names for Google APIs and services except for private.googleapis.com and restricted.googleapis.com.

Various IP address ranges—you can determine a set of IP ranges that contains the possible addresses used by the default domains by referencing IP addresses for default domains
Enables API access to most Google APIs and services regardless of whether they are supported by VPC Service Controls. Includes API access to Google Maps, Google Ads, Google Cloud platform, and most other Google APIs whose names end in googleapis.com. Does not support G Suite web applications. The default domains are used when you don't configure DNS records for private.googleapis.com and restricted.googleapis.com
private.googleapis.com

199.36.153.8/30
Enables API access to most Google APIs and services regardless of whether they are supported by VPC Service Controls. Includes API access to Maps, Google Ads, Google Cloud platform, and most other Google APIs, including the lists below. Does not support G Suite web applications.

Domain names that end with:
  • googleapis.com
  • googleadapis.com
  • ltsapis.goog
  • gcr.io
  • gstatic.com
  • appspot.com
  • cloudfunctions.net
  • pki.goog
  • cloudproxy.app
  • run.app
  • datafusion.googleusercontent.com
  • datafusion.cloud.google.com
Host/domain names that match:
  • packages.cloud.google.com
  • gcr.io
  • appengine.google.com
  • pki.goog
Use private.googleapis.com to access Google APIs and services using a set of IP addresses only routable from within Google Cloud. Choose private.googleapis.com under these circumstances:
  • You don't use VPC Service Controls.
  • You do use VPC Service Controls, but you also need to access Google APIs and services that are not supported by VPC Service Controls.
restricted.googleapis.com

199.36.153.4/30
Enables API access to Google APIs and services that are supported by VPC Service Controls.

Blocks access to Google APIs and services that do not support VPC Service Controls. Does not support G Suite web applications or G Suite APIs.
Use restricted.googleapis.com to access Google APIs and services using a set of IP addresses only routable from within Google Cloud. Choose restricted.googleapis.com when you only need access to Google APIs and services that are supported by VPC Service Controls — restricted.googleapis.com does not permit access to Google APIs and services that do not support VPC Service Controls.

Supported services

Services available to on-premises hosts are limited to those supported by the domain name and VIP used to access them. Refer to Private Google Access-specific domains and VIPs for details.

Example

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 restricted.googleapis.com (199.36.153.4/30).

Private Google Access for hybrid cloud use case (click to enlarge)
  • The on-premises DNS configuration maps *.googleapis.com requests to restricted.googleapis.com, which resolves to the 199.36.153.4/30.
  • Cloud Router has been configured to advertise the 199.36.153.4/30 IP address range through the Cloud VPN tunnel by using a custom route advertisement. Traffic going to Google APIs is routed through the tunnel to the VPC network.
  • A custom static routes was added to the VPC network that directs traffic with the destination 199.36.153.4/30 to the default internet gateway (as the next hop). Google then routes traffic to the appropriate API or service.
  • If you created a Cloud DNS managed private zone for *.googleapis.com that maps to 199.36.153.4/30 and have authorized that zone for use by your VPC network, requests to anything in the googleapis.com domain are sent to the IP addresses that are used by restricted.googleapis.com. 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, Google Cloud 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.

Supported services

The following Google services support private services access:

Example

In the following example, the customer VPC network allocated the 10.240.0.0/16 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 instances.

Private services access (click to enlarge)
  • The private connection is assigned the 10.240.0.0/16 allocated 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 /24 CIDR 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.2 are 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 a serverless environment on Google Cloud directly to your VPC network. This connection makes it possible for your serverless environment to access resources in your VPC network via internal IP addresses.

With Serverless VPC Access, you create a connector in your Google Cloud project and attach it to a VPC network. You then configure your serverless services (such as Cloud Run services, App Engine apps, or Cloud Functions) to use the connector for internal network traffic.

Serverless VPC Access only allows requests to be initiated by the serverless environment. Requests initiated by a VM must use the external address of your serverless service—see Private Google Access for more information.

Serverless VPC Access does not support legacy networks or Shared VPC. For more information, see Configuring Serverless VPC Access.

Supported services

The following Google services support Serverless VPC Access connectors:

  • Cloud Run (fully managed)
  • App Engine standard environment
    • All runtimes except PHP 5
  • Cloud Functions

Example

In the following example, App Engine, Cloud Functions, and Cloud Run use a Serverless VPC Access connector to send requests to internal resources in the VPC network.

Serverless VPC Access example (click to enlarge)
Serverless VPC Access example (click to enlarge)
  • The Serverless VPC Access connector is in the same project and region as the serverless services.
  • The connector is attached to the VPC network that contains the destination resources. The connector can access resources in other VPC networks and Google Cloud 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.
  • App Engine, Cloud Functions, and Cloud Run reach the destination resources by sending requests to their internal IP addresses, 10.0.0.4 and 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 the serverless environments to internal IP addresses travel internally through the Serverless VPC Access connector to the destination resource. Requests sent to external IP addresses travel through the internet.

What's next