GETTING STARTED WITH PRIVATE GOOGLE ACCESS
PRIVATE GOOGLE ACCESS
PRIVATE GOOGLE ACCESS FOR ON-PREM HOSTS
OTHER TYPES OF PRIVATE ACCESS
In this Course, we look at configuring Private Google access starting with an overview of what it is, before moving on to networking and DNS configuration as well as routing and firewalls. We'll then walk you through a guided demonstration of how to enable Private Google Access so that you get a practical understanding of the service.
We'll also look at Private Google Access for on-premises hosts, covering domain names, virtual IPs, networking and DNS configuration, and permissions. We'll wrap with Private Services Access and Serverless VPC Access.
- Learn about Private Google Access, its networking and DNS requirements, and how to configure routing and firewalls to use it
- Learn about Private Google Access for on-premises hosts, its requirements, its permissions, and how to use it
- Get a high-level overview of Private Services Access and Serverless VPC Access
This Course is intended for those who wish to learn how to configure private Google access on the GCP platform.
To get the most out of this Course, you should have a basic knowledge of GCP.
Welcome to Serverless VPC Access. Let’s take a look at what it is and what it offers.
Serverless VPC Access is a private access option in GCP that allows you to connect from a serverless environment in Google Cloud directly to your VPC network via an internal IP address.
To make this happen, what you do is create a connector and attach it to a VPC network within your Google Cloud project. Once you have the connector configured and attached to the VPC network, you configure whatever serverless services that you are using to use the connector for internal network traffic. The Google services that support Serverless VPC Access include Cloud Run, App Engine standard environment, and Cloud Functions. Serverless VPC Access does NOT support legacy networks.
I should also mention that Serverless VPC Access will only allow requests to be initiated by the serverless environment. If a request is initiated by a virtual machine, that request must use the external address of the serverless service being requested.
The image on your screen depicts a typical Serverless VPC Access implementation.
In this implementation here, we can see that Cloud Functions, Cloud Run, and App Engine all use a single Serverless VPC Access connector to communicate with the resources deployed on the VPC network.
Looking at the diagram, you can see that the Serverless VPC Access connector is deployed in the same project and region as the App Engine, Cloud Functions, and Cloud Run deployments. This connector attaches to the VPC network so it can facilitate communications between the serverless services and the GCP resources on the VPC network.
Because the connector is assigned the range of 10.8.0.0/28, when requests get sent from the connector to the destination, those requests will come from a source address that sits within that 10.8.0.0/28 range.
The internal IPs for the GCP resources in the VPC network are 10.0.0.4 and 10.1.0.2. These are the addresses that App Engine, Cloud Functions, and Cloud Run will use when sending requests to those resources. If you look closely at the diagram, you can also see that these requests can be sent to resources in any region. We aren’t relegated to just one region.
Now, since the requests that are sent from the serverless services are going to internal IP addresses, those requests remain internal to Google Cloud. They leave the serverless services, travel through the Serverless VPC Access connector, and then arrive at the destination resource on the VPC network.
Any requests that are sent directly to an external IP address will go out through the public internet.
For more details on configuring Serverless VPC Access, visit the URL that you see on your screen:
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.