Azure-GCP Private Google Access — Part 1

I have always been curious to know the configurations required for Private Google Access for on-premises host, and recently I got a chance to prototype it with Azure. It is actually quite straightforward, and in the upcoming articles, we would discuss how restricted vs private Google APIs make a difference and the deployment steps.

TL;DR — Follow the below architecture to implement components with its configuration to build private google access connectivity using restricted Google APIs between Azure, and GCP

Private Google Access — By default, when a Compute Engine VM lacks an external IP address assigned to its network interface, it can only send packets to other internal IP address destinations. You can allow these VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface.

Private Google Access for On-prem hosts — Private Google Access for on-premises hosts provides a way for on-premises systems to connect to Google APIs and services by routing traffic through a Cloud VPN tunnel or a Cloud Interconnect attachment (VLAN). Private Google Access for on-premises hosts is an alternative to connecting to Google APIs and services over the internet.

Basically, Google APIs(like Cloud Storage) are hosted over Internet, and in order to work with these APIs the virtual machines ideally would require internet connectivity to access APIs(in this case storage.googleapis.com).

This means private google access can be used with scenarios such as:

1. You don’t want to expose your VM to the Internet
2. You want to communicate to Google APIs using a private channel rather over the Internet
3. Migrations that you want to carry over an encrypted channel with Cloud VPN or with faster network bandwidth using Interconnect

The Private Google Access is a per subnet basis feature, and below is what happens:

1. The two options, i.e restricted or private google apis have their own CIDR range which is 199.36.153.4/30 and 199.36.153.8/30 respectively
2. Google doesn’t publish the route for these two ranges over the Internet, and it requires us to create the DNS resolution for *.googelapis.com to either of the options(private or restricted)
3. Along with the resolution it also requires us to create routes from either of the options(private or restricted) to next-hop as Internet Gateway, however, even though the next hop is to the Internet, the packet itself remains within Google premises and never leaves it

(Azure-GCP Private Google Access over HA Cloud VPN active-active configuration)

(Request Flow Description)

Note: The above architecture is with HA Cloud VPN(Active-Active) configuration, and restricted.googleapis.com(199.36.153.4/30), however, a similar step applies for Active-Passive configuration and private.googleapis.com(199.36.153.8/30) with minor updates.

This architecture consists of a VM in each Cloud environment to test the VM-to-VM connectivity, as well as to validate or lookup at the GCP APIs from the Azure environment.

Important or troubleshooting steps:

1. Make sure the right IP address for Private(199.36.153.8/30) or Restricted(199.36.153.4/30) Google APIs are provided in both environments private DNS, and GCP Routes advertised over BGP session
2. Private Google Access only gets applied to resources with no Internet connectivity
3. Make sure in Azure you associate subnet, and link vpc in Route table, and Private DNS respectively
4. VPN in Azure can take up to 45 minutes to get deployed
5. Make sure Private Google Access is enabled for the GCP Subnetwork

Upcoming articles on —

1. Differences between restricted vs private google apis from a VPC SC perspective
2. Deployment configurations
3. Using Cloud DNS Response Policy Zones

I hope it helps understand the overall gist, and actually how easy it is to configure the private google access for on-premises host. Feel free to provide feedback or questions that I can help with.

Cheers!