Configuring Private Google Access

Private Google Access (PGA) is the method by which resources in Google Cloud such as Google Cloud Compute Engine (GCE), Google Cloud VMware Engine (GCVE) or on-premise, can access Google Cloud APIs without having Internet access or needing an assigned external IP address.

For on-premise clients, this connectivity can take place through private hybrid connections such as Interconnect which may be faster than the subscribed Internet service.

For an overview, check out

Ultimately, PGA is delivered through a set of public IP addresses which are not advertised on the Internet but are available via the Google Cloud VPC in your project.

  • for is used for services that are supported by VPC Service Controls and blocks access to services that do not support VPC service controls.
  • for is used for most services (except Workspace web or interactive websites) regardless of their support for VPC Service Controls.

In this post, we’ll cover working with which supports most APIs.

To enable clients to use PGA to access common APIs, two things need to be configured:

  1. Routing: Clients need to have a network route to reach these IP addresses.
  2. DNS: Clients need to resolve the public API fully-qualified domain name (FQDN, such as to one of the 4 IP addresses in the range:, .9, .10, and .11.


In order to access the range for, we need to first determine where our clients are located on the network and how they get to the Internet.

Google Compute Engine

Compute Engine clients on a VPC must meet the requirements to use PGA. Two of these requirements are the VM must not have an external public IP address and it must use a subnet which has PGA enabled. Enabling PGA is done per-subnet, not per-VPC. Clients will access the range through the VPC’s standard default internet gateway route.

If the default internet gateway route has been overridden by a custom route that directs Internet-bound traffic ( to a firewall appliance, then an additional custom route must be created for the range with a next hop of default-internet-gateway and a priority that is higher than the custom route for

This way, traffic for will go out the default Internet gateway of the VPC. It doesn’t actually go to the Internet – instead the underlying Google Cloud network will accept that traffic and direct it to the private internal interfaces of Google APIs.

In the screenshot below, the routes are ordered from highest priority (lowest number) to lowest priority (highest number). The private-google-access route has a priority of 90 which is a higher priority than the route for with a priority of 100 that leads to another network. Therefore, traffic for the PGA range will go out the default Internet gateway of the VPC and not onward to the other network like all other Internet traffic.

Google Cloud VMware Engine

If Google Cloud VMware Engine (GCVE) is configured to use VMware Engine Internet access, then traffic for will flow through the GCVE Internet access service.

If Internet access for GCVE workloads has been disabled and Internet-bound traffic is configured to use another network, then traffic for will flow through the GCVE VPC peering connection to your peered VPC and route based on the routing configuration of your VPC.

The VPC in your project should be advertising a route for for with a priority that overrides the default internet gateway route. Therefore, an additional custom route must be created for the range with a next hop of default-internet-gateway and a priority that is higher than the custom route for

See the previous screenshot for an example.

See Private Google Access: a closer look for more details about PGA for GCVE.


Typically, on-premise clients trying to reach the range for would take the default route out to the internet. But, since this range is not available on the internet, communication will fail.

Supporting Private Google Access with on-premise clients requires hybrid connectivity between the Google Cloud project VPC and the on-premise environment such as through Interconnect or Cloud VPN.

A route for must be advertised by the Cloud Router that is associated with the hybrid connectivity. This way, clients on-premise will have a route to that leads back over the hybrid connectivity, instead of out to the internet.

Additionally, if the VPC associated with the hybrid connectivity (Interconnect or Cloud VPN) has its default internet gateway route overridden by a custom route that directs Internet-bound traffic ( to a firewall appliance, then an additional custom route must be created for the range with a next hop of default-internet-gateway and a priority that is higher than the custom route for

This way, on-premise clients trying to reach the range will be directed over the hybrid connectivity and then out the VPC’s default internet gateway to access PGA.


To test connectivity for any client to the range for once routing has been configured, use the Test-NetConnection PowerShell cmdlet with port 80 or 443 (only HTTP/S is supported, ICMP Ping is not). The TcpTestSucceeded value should return True if the routing was configured successfully:

Test-NetConnection -computername -port 443

ComputerName     :
RemoteAddress    :
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    :
TcpTestSucceeded : True

Verification of connectivity should be completed prior to making any DNS changes to avoid an outage for clients trying to reach Google APIs.


Once routing is in place and tested, changes in DNS must be made. These changes should be done on the DNS server used by clients.

To override the DNS resolution of a Google API fully-qualified domain name (FQDN), we need to create a new zone in DNS along with A- and CNAME-records that resolve the API FQDN to the private IPs. This way, clients will no longer use the publicly-advertised DNS zone and records which resolve to the public IP of the API and will instead use the private IP from the DNS server’s overriding zone.

If a client is configured to check its local hosts file first for DNS resolution prior to using the internal or public DNS, entries in the hosts file can be configured to point a public API FQDN to a PGA IP. This is a safe way to fully test PGA on a single host before affecting all clients by updating the common internal DNS server.

In this example, we override resolution of and point it to one of the IP addresses,

% cat /etc/hosts
# Host Database
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##       localhost broadcasthost
::1             localhost

Any requests on this client to will now go to and should be successful as long as routing is in place.

To enable all clients which use a common DNS server to use PGA IPs instead of the public IP, create a DNS zone for in the private DNS server.

Within the new zone, create A-records for using the four different IP addresses in the range:,,, and

On-premise Active Directory clients

If clients are part of an Active Directory (AD) domain, AD DNS can be used to create the zone and A-records:

Be sure to create A-records for each of the IPs:

Next, create a wildcard CNAME-record for * which points to the A records.

Now, when any client tries to resolve any hostname, it will be given one of the PGA IPs.

Compute Engine with Google Cloud DNS

If clients use Google Cloud DNS, such as Compute Engine instances, this same configuration can be made in Cloud DNS.

Create a new private zone for, and then create a record set for and add the four IP addresses, and then also create a record set for the wildcard CNAME *

Terraform can be used to create zones and record sets. Following is an example for setting up

resource "google_dns_managed_zone" "dns-zone-googleapis-com" {
  name        = "googleapis-com"
  project     = google_project.svpc.project_id
  dns_name    = ""
  description = "Private Google Access"

  visibility = "private"

  private_visibility_config {
    networks {
      network_url =

resource "google_dns_record_set" "private-google-access-a" {
  project      = google_project.svpc.project_id
  name         = "private.${google_dns_managed_zone.dns-zone-googleapis-com.dns_name}"
  managed_zone =
  type         = "A"
  ttl          = 300

  rrdatas = ["", "", "", ""]

resource "google_dns_record_set" "private-google-access-cname" {
  project      = google_project.svpc.project_id
  name         = "*.${google_dns_managed_zone.dns-zone-googleapis-com.dns_name}"
  managed_zone =
  type         = "CNAME"
  ttl          = 300
  rrdatas      = []

Google Cloud VMware Engine

Google Cloud VMware Engine clients will need to use a DNS server such as Active Directory or Google Cloud DNS (through a Cloud DNS inbound server policy) to resolve overriding domain names.

Additional API domains

Additional zones may need to be configured in the DNS server other than depending on what the client is trying to access. This could include and others. See Domain Options for

For example, to override the domain, create A records for the domain itself and then a wildcard CNAME for * which points to the domain A records.

When using any Google Cloud service, be sure to review which API FQDNs are in use and determine if additional overriding zones need to be created in the DNS server.

For further implementation details about Private Google Access, see

2 thoughts on “Configuring Private Google Access

  1. Rob

    For private google access on-prem, Can I send a subset of google apis over the VPN (ex. pubsub/logging) & the rest over the internet (ex. safebrowsing, update)? The only way I can think of is to make a DNS zone for each google API, which is not scalable.

    1. chouse Post author

      Hi Rob, I believe you have the best method for a subset – overriding the DNS for each particular API you want to send over hybrid connectivity. If you only make DNS zones for the APIs you want to send over hybrid connectivity, the rest will go out your regular internet connection. If the subset you want to redirect over Hybrid Connectivity is minimal, it shouldn’t be too bad.

      Make sure you have routing everywhere a client would get the redirected DNS IP or else their connectivity to Google APIs will fail completely for that subset.


Leave a Reply

Your email address will not be published. Required fields are marked *