Cloud NAT and Private Google Access

Let’s start with a fundamental problem. When you build a virtual private cloud (VPC) on Google Cloud, you create a private network. It’s like a fenced-off plot of land. Inside that plot, you create virtual machines (VMs) — think of them as houses. By default, these houses have no road connecting them to the outside world. They can talk to each other within the VPC, but they cannot reach the public internet. That’s good for security, but terrible for practical tasks like downloading security patches, accessing a public API, or installing software from a public repository.

This is where Cloud NAT (Network Address Translation) comes in. Cloud NAT is a managed service that acts like a shared front door for all the VMs in your VPC. It gives those private VMs a way to talk to the public internet without giving them a public IP address of their own. Think of it like a large apartment building. Each apartment (VM) has a unique internal number (private IP address), but the building only has one street address (the NAT’s public IP address). When someone in Apartment 3B sends a letter to the outside world, the building’s mail room (the NAT) swaps out the return address from “Apartment 3B” to “123 Main Street, Apartment 3B”. The outside world replies to “123 Main Street”, and the mail room knows to deliver the reply to Apartment 3B. The NAT keeps track of all these connections using a stateful table — it remembers who initiated which conversation and where the reply should go.

It is critical to understand that Cloud NAT is an outbound-only service. It allows VMs to initiate connections to the internet, but it does not allow anything from the internet to initiate a connection back to those VMs. That would require a firewall rule or a load balancer. This is a common exam trap. The NAT is a one-way street for outgoing traffic.

Now, Private Google Access (PGA) solves a different but related problem. What if your private VMs need to talk to Google’s own services — things like Cloud Storage, BigQuery, or the Google Cloud APIs — without going over the public internet? You might think, “Why not just use Cloud NAT for that?” You could, but it is less secure and less performant. The traffic would leave your VPC, travel across the public internet, and then hit Google’s front-end servers. That introduces latency and potential exposure.

Private Google Access enables your private VMs to reach Google’s public APIs using a private internal path. When you enable PGA on a subnet, Google’s infrastructure automatically routes traffic destined for Google’s API endpoints through a private, internal network path instead of sending it out to the public internet. The VM still uses its private IP address; it never needs a public IP. The traffic stays inside Google’s backbone network, which is faster and more secure. It is important to note that PGA only covers traffic to Google’s services, not to the general internet. For general internet access, you still need Cloud NAT.

A related concept is Private Service Connect (PSC). While PGA allows VMs to access Google’s APIs, PSC allows VMs to access managed services that you or your partners have published, or to connect to Google’s services in a way that allows you to define the endpoint inside your VPC. For the PCNE exam, focus on the distinction: PGA is for Google’s end-user APIs (like Storage and BigQuery), while PSC is for accessing specific managed service endpoints or publishing your own services.

Let’s break down the types and configurations:

The exam loves to test which configuration is needed for which scenario. A common question: “Your VMs are in a private subnet with no external IP. They need to download a library from a third-party website. What should you configure?” The correct answer is Cloud NAT. “They need to write data to a Cloud Storage bucket. What should you configure?” The correct answer is Private Google Access. “They need to do both?” You need both Cloud NAT and Private Google Access.

Let’s look at a typical scenario for a company called FinTech Analytics. They process financial data and have strict security requirements. They run their workloads in a VPC with no public IP addresses on their VMs at all. They do this to minimise the attack surface. Here is what their network engineer, Priya, actually does.

Priya is responsible for letting her private VMs access the necessary external resources while staying compliant. She has three main requirements:

For requirement one, Priya configures Cloud NAT. She creates a Cloud Router in the us-central1 region and associates it with her VPC. Then she creates a Cloud NAT gateway on that router, specifying the IP ranges of her primary subnet. She allocates two external IP addresses for the NAT to use. This allows the VMs to reach the public Linux repository. The VMs never get a public IP; they always appear to the repository as coming from one of those two NAT IPs. Priya sets the NAT to automatically create firewall rules that allow the return traffic. This is the day-to-day activity of a network engineer: creating and managing NAT gateways to enable outbound connectivity.

For requirement two, Priya could use the same Cloud NAT, but she considers the security implications. The financial API is a known public endpoint. MitM (Man-in-the-Middle) attacks are a theoretical risk. She decides the existing Cloud NAT is sufficient for now because she trusts the TLS encryption on the API connection. If the API were a Google service, she would switch to Private Google Access.

For requirement three, Priya does not use Cloud NAT at all. Instead, she enables Private Google Access on her subnet. She goes to the VPC network section in the Google Cloud Console, selects her subnet, and under “Private Google Access” she clicks “On”. That is it. Now, when any VM in that subnet sends a request to storage.googleapis.com, the traffic is automatically routed through Google’s internal network without touching the public internet. This is faster and more secure. It also reduces her NAT bandwidth usage, saving costs.

When an incident happens — say the VMs cannot reach the financial API — Priya’s troubleshooting steps include:

The key decision for Priya every time she adds a new service is: Is this a Google API, or is it the public internet? This decision determines whether she uses Private Google Access, Cloud NAT, or both.