Private Access Options for Services

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.

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.

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. 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.

Supported services

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

Example

In the following example, the example project contains a single
VPC network with two subnets. Private Google Access is enabled
for subnet-a but not for subnet-b.
Implementation of Private Google Access (click to
enlarge)

The VPC network meets the routing
requirement for
Private Google Access
because it has a route whose next hop is the default Internet gateway. Even
though the next hop is called “default Internet gateway,” VMs that only have
internal IP addresses do not meet the Internet access
requirements. Requests to Google APIs and
services from VMs that only have internal IP addresses are not sent through
the public Internet. That traffic stays within Google's network.

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 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 a private IP address.

VM B1 can't access Google APIs and services because it only has a private
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 public IP addresses. Private Google Access
has no effect on whether or not these instances can access Google APIs and
services because both have public IP addresses.

Private Google Access for on-premises hosts

Beta

This is a Beta release of
Private Google Access from on-premises for hybrid cloud connectivity. This feature
is not covered by any SLA or deprecation policy and might be subject to backward-incompatible
changes.

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 199.36.153.4/30
and a next hop being the default Internet gateway. Even though the next hop is
called “default Internet gateway,” traffic sent to 199.36.153.4/30 stays
within Google's network instead of traversing the public Internet because Google
does not publish routes to 199.36.153.4/30 externally.

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 199.36.153.4/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 199.36.153.4/30 destination.

Supported services

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:

BigQuery

Cloud Bigtable

Cloud Dataflow

Cloud Dataproc

Cloud Data Loss Prevention API

Cloud Deployment Manager

Cloud DNS

Cloud KMS

Cloud Pub/Sub

Cloud Spanner

Cloud Storage JSON API

Container Registry

Stackdriver logging

Stackdriver Error Reporting

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 the restricted IP range for Google APIs and
services, 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 advertises the 199.36.153.4/30 IP 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
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 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

Beta

This is a Beta release of
private services access. This feature
is not covered by any SLA or deprecation policy and might be subject to backward-incompatible
changes.

Google and third parties (together known as service producers) can offer
services with internal IP addresses that are hosted in a VPC
network. You connect to these private services through a private connection. VM
instances use the private connection to connect to the internal IP addresses of
services. Instances must have internal IP addresses to use private services
access. They can have external IP addresses, but external IP addresses are not
required for, and not used by, private services access.

A private connection is implemented as a VPC Network
Peering connection between your VPC
network and the service producer's VPC network. The service
producer's network is created exclusively for you, and it is not shared with
other customers. The behaviors and constraints of VPC Network
Peering connections also apply to private connections.

Private services access requires you to first allocate an internal IP address
range and then create a private connection. An allocated range 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.

You can use private services access only with services that support it. Check
with the service producer before creating a private connection. For detailed
information about allocating a range and creating a private connection, see
Configuring Private Services
Access.

Note: When you use private services access as a service consumer, you are solely
responsible for securing your VPC networks and all resources and data available
on them. Google is not responsible for how your data and resources may be
accessed or used by the third party that you are connecting with.

Supported services

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, 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 in which to provision
resources.

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 chosen by the service but must come from the
allocated IP address range.

VM instances from one region can access resources in any region. However, 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 Google service's VPC network. After reaching the
service network, the service network routes the request to the correct
resource. Traffic travels internally within Google's network, not through the
public Internet.