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 an internal IP address and can't have external IP addresses.||Connect to the public IP addresses of Google APIs and services through the VPC network's 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.|
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.
Private Google Access permits access to Cloud and Developer APIs and most GCP services, except for the following services:
- Cloud SQL
- Cloud Filestore
- App Engine Memcache
- Cloud Redis
Instead, Private services access might support one or more of them.
In the following example, the example project contains a single
VPC network with two subnets. Private Google Access is enabled
subnet-a but not for
- The VPC network meets the routing requirement for Private Google Access because it has a route whose next hop is the Internet gateway.
- 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).
- Private Google Access is
subnet-abut not for
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 a private IP address.
VM B1can't access Google APIs and services because it only has a private IP address and Private Google Access is disabled for
VM B2can 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
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 route traffic destined to
188.8.131.52/30 to the default
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
184.108.40.206/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:
- 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
- Stackdriver logging
- Stackdriver Error Reporting
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 routed to the Internet gateway and then goes to Google APIs and services.
- The on-premises DNS configuration maps
restricted.googleapis.com, which resolves to the
- Cloud Router advertises the
220.127.116.11/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
18.104.22.168/30to the 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. 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.
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, such as Cloud SQL instances.
- The private connection is assigned the
10.240.0.0/16allocated 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.2are 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.
- 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.