Cloud NAT is a small topic on the Professional Cloud Architect exam, but it shows up reliably enough that I want to walk through it directly. The mental model is straightforward once you connect it to the org policy that usually drives it.
NAT stands for Network Address Translation. It is the general technology that maps private IP addresses to public IP addresses so resources on a private network can talk to external networks.
Cloud NAT is the GCP managed service that does this for you. It lets compute resources without public IP addresses reach the internet for outbound connections. The compute resource is usually a VM, but not always, and that distinction matters for the exam.
The point of all of this is to keep your resources private while still letting them make the outbound calls they need to make. A VM with no external IP cannot be reached from the internet by an unsolicited inbound connection, but it still might need to pull a package, hit an API, or send telemetry somewhere. Cloud NAT closes that gap without putting a public IP on every VM.
The setup looks like this. You have a project containing a VPC network. Inside the VPC, you have a subnet with VM instances in it. Those VMs have internal IPs only. No external IPs.
You configure Cloud NAT at the VPC level. It acts as a central, managed NAT gateway for that VPC, handling outbound traffic for resources in your subnets.
When a VM in the subnet initiates an outbound request, Cloud NAT translates its internal IP to a public IP that belongs to the NAT gateway. The request goes out to the internet under that public IP. When the response comes back, Cloud NAT maps it back to the internal IP of the original VM and delivers it. The VM never needs an external IP of its own.
One configuration detail to remember: as part of setting up Cloud NAT, you select which subnet's instances are eligible for translation. That selection happens in the Cloud NAT Mapping section of the configuration. The exam can ask about that.
A source endpoint, in the Cloud NAT context, is the resource inside the private network that initiates an outbound request and relies on Cloud NAT to get out. There are three you should recognize.
The first is VMs without public IPs. This is the canonical case and the one the architecture diagram above illustrates.
The second is private GKE clusters. These are clusters configured so that nodes only have private IP addresses. The nodes are isolated from the public internet, but the workloads on them often need to pull container images, talk to external APIs, or push telemetry. Cloud NAT lets them do that while keeping the nodes private.
The third is serverless services connected to a VPC subnet. This covers Cloud Run, Cloud Functions, App Engine, and Dataflow. These services do not integrate with Cloud NAT directly. Instead, the VPC subnet they are attached to acts as the source endpoint, and Cloud NAT translates traffic for the subnet. From the exam's perspective, the takeaway is that serverless workloads can use Cloud NAT for outbound connectivity, but they reach it through their VPC subnet rather than as standalone endpoints.
There are four benefits worth knowing.
First, it reduces the attack surface. VMs without external IPs cannot receive unsolicited inbound connections from the internet, which removes a common entry point for attackers. Cloud NAT keeps that posture intact while still allowing outbound traffic.
Second, it scales automatically. As the number of VMs or the volume of outbound traffic grows, Cloud NAT adjusts to handle the load without manual intervention.
Third, it has high availability with no single point of failure. You do not architect around it failing.
Fourth, it lowers cost by reducing the number of external IP addresses you need. External IPs cost money, and assigning one to every VM that occasionally needs outbound access is wasteful when a single NAT gateway can serve the whole subnet.
Here is the exam tip I want you to internalize. Activating Cloud NAT very often goes hand in hand with disallowing external IPs through the org policy constraints/compute.vmExternalIpAccess.
The pattern is: an organization decides that VMs should not have external IPs at all, and enforces that with the org policy constraint. That constraint blocks teams from assigning public IPs to VMs. But the workloads still need outbound internet access, so Cloud NAT gets turned on at the VPC level to give them a way out.
If you see a Professional Cloud Architect exam scenario where an org policy is restricting external IPs and a workload needs to make outbound calls, Cloud NAT is the answer. The two pieces fit together.
That is the full Cloud NAT story for the Professional Cloud Architect exam. It is a narrow topic, but the pieces are well-defined: what it does, the three source endpoint types, the four benefits, and the org policy pairing.
My Professional Cloud Architect course covers Cloud NAT alongside the rest of the networking material.
