Hello and welcome to private Google access. In this lesson, we will take an overview look at what private Google access is, along with the supported services, and an example implementation of private Google access. 

Organizations will often use private Google access when they need to allow VM instances with no external IP addresses to reach the external IP addresses of Google APIs and services. When using private Google access to reach the external IP of a Google API or service, the source IP address can be either a primary internal IP address of a network interface, or it can be an IP address that’s part of an alias IP range that’s assigned to an interface. Without private Google access, VM’s with only internal IP addresses can only send traffic within the VPC network.

Since instances with external IP addresses can already access the internet, private Google access will have no effect on those instances.

I should mention that private Google access is enabled on a subnet by subnet basis and supports most Google cloud services except for App Engine Memcache, Filestore, and Memorystore.

The image that you see on your screen shows what a typical implementation of private Google access might look like.

In this example, egress firewall rules for the VPC network itself would typically be configured to allow access to 0.0.0.0/0. The A1 virtual machine in this example is able to access Google APIs and services, despite having only an internal IP address, because private Google access is turned on for subnet-a, which is the subnet that the A1 VM is attached to. Private Google access doesn’t apply to the A2 virtual machine because the A2 virtual machine has a public IP associated with it. Remember, private Google access has no effect on instances with public IPs.

Now, with that being said, the A2 virtual machine can still access Google APIs and services because it has that public IP.

As far as the instances on subnet-b go, the B1 virtual machine cannot access Google APIs and services because as you can see here, not only does B1 not have a public IP, but private Google access is turned off for subnet-b, which is the subnet that B1 is attached to. The B2 virtual machine, like A2, can in fact access Google APIs and services because of the public IP assigned to the instance.

Because private Google access can be enabled on a subnet by subnet basis, you can enable it during the creation of a subnet, or you can enable it for subnet after the subnet has been created. Assuming a VPC network meets the network requirements for Google APIs and services, once you enable private Google access for subnet on that VPC network, Google cloud will allow any virtual machines that are attached to that subnet to send traffic to the external IP addresses of Google APIs and services. 

More specifically, traffic to Google APIs and services is allowed from the primary internal IP address of a virtual machine’s network interface, as long as it’s attached to a subnet enabled for private google access AND as long as it doesn’t have an external IP address assigned to it. Traffic to Google APIs and services is also allowed from an internal IP address that is part of an alias IP range of a virtual machine’s network interface that’s attached to a subnet that’s been enabled for private google access.

Now, I should point out that there are several network requirements that need to be met in order to leverage private Google access. For example, legacy networks are not supported by private Google access because they do not support subnets. Since private Google access is enabled on a per subnet basis, this is obviously a problem. So, for private Google access, you need to use VPC networks. 

I should also mention that enabling private Google access doesn’t automatically enable any APIs. The APIs that you want to use need to be separately enabled through the APIs and services page in the Google cloud console.

It’s also important to keep in mind that if you plan to use the private.googleapis.com or restricted.googleapis.com domain names to access APIs, you’re going to have to create DNS records that resolve those domain names to the IP addresses of the APIs you are trying to access. In addition, you need to ensure that routes defined in your network, allow traffic to reach the destination IP ranges that are used by Google APIs and services. Essentially, this means that your defined routes must be configured with the default Internet gateway as the next hop.

And lastly, and this is pretty much a no-brainer, any defined egress firewalls must allow traffic to the IP ranges for Google APIs and services. The implied allowed egress firewall rule that Google cloud sets up automatically is sufficient to allow this traffic.

Join me in the next lesson, where we will dive into a more detailed discussion of networking and DNS configuration requirements.