Cloud NAT

Cloud NAT is the managed Network Address Translation service for VMs without public IPs. It is the keystone of the "no public IPs anywhere" pattern: VMs live on private subnets, all outbound internet traffic exits through Cloud NAT, and the public IP attack surface drops to zero. The mechanism sounds simple; the nuances are in port allocation, the choice of static versus dynamic IPs, and knowing when Cloud NAT is the wrong tool entirely.

Cloud NAT is a regional service. Each region of a VPC needs its own NAT gateway, or its outbound traffic has no way out without a public IP on the VM itself.

Outbound Connectivity Without Public IPs

A VM on a Cloud NAT-enabled subnet can initiate outbound connections to the internet (and to managed services that require public IPs to reach), even though it has no external IP itself. Inbound connections from the internet remain impossible — Cloud NAT is one-way, by design. The net effect: workloads stay invisible from the outside, while still able to call public APIs, fetch packages, and ping third-party services. Cloud NAT works seamlessly with private workloads in Compute Engine, GKE, Cloud Run, App Engine, and any other compute layer that runs on top of a VPC subnet.

Port Allocation

Every outbound NAT connection consumes a source port. Cloud NAT allocates port ranges per VM from the gateway's IP pool. The defaults — typically 64 ports per VM — are fine for low-traffic workloads. A workload that opens many concurrent connections (a scraper, a CI runner pulling from many registries, a microservice fanning out to many third-party APIs) can exhaust its port allocation and start dropping connections. The symptom is intermittent connection failures that correlate with traffic volume but do not match any application-level error. Raise min_ports_per_vm and verify the gateway has enough total port capacity (NAT IPs × 64,512 ports per IP minus reserved ports).

Static vs Dynamic NAT IPs

By default, Cloud NAT allocates external IPs from a Google-managed pool — fast to set up, no IP management on your side, but the IPs can change. When a third-party API requires source-IP allowlisting (banks, government APIs, regulated partners), the dynamic pool will not work: you cannot give the partner an allowlist that drifts. Reserve static external IPs and configure Cloud NAT to use them. Capacity planning matters more in this mode — with fixed IPs, scaling beyond their port budget means adding more IPs.

NAT Logging

Cloud NAT logs record connection translations: source VM, destination, allocated port, timestamp. Logging is off by default — but in any security investigation involving "what did this VM talk to," NAT logs are the only source of truth, and they cannot be enabled retroactively. Turn them on in production. Translation logs only (not errors-only or no logging) is the right setting for security-relevant subnets.

Single Gateway in a Shared VPC

In a Shared VPC, one Cloud NAT gateway per region serves all service projects attached to that VPC — you do not deploy a gateway per project. This is the operationally correct pattern: the networking team manages a small number of gateways with appropriate capacity, while product teams just attach their workloads. Duplicating gateways per project wastes IP budget and complicates the allowlist story with third parties.