Cloud NAT in GCP Explained: Outbound Internet for Private VMs

Simple explanation

Cloud NAT sits between your private VM and the internet. When your VM sends a packet to an external destination, Cloud NAT catches it at the VPC edge, swaps the source IP from the VM’s private IP to a public NAT IP, and forwards it on. The external server replies to that NAT IP. Cloud NAT catches the response, translates the destination back to the VM’s private IP, and delivers it.

The VM can start connections. Responses can come back. But no one on the internet can initiate a connection through Cloud NAT to your VM. There is no inbound path.

How Cloud NAT works

Cloud NAT is configured per region per VPC network. A single NAT gateway can cover all subnets in a region, or you can restrict it to specific subnets.

Here is the full packet flow:

1. A VM with no external IP sends a packet to an internet destination (for example, a package server at 185.x.x.x).
2. GCP consults the VPC’s route table. The default route (0.0.0.0/0 via the default internet gateway) matches.
3. Cloud NAT intercepts the packet before it leaves the VPC boundary. It replaces the private source IP with one of the gateway’s public NAT IP addresses, and assigns a source port from the pool allocated for that VM.
4. The packet is forwarded to the internet. The external server sees the NAT IP as the sender and replies to it.
5. The reply packet arrives at the NAT gateway. Cloud NAT looks up the original session using IP and port, reverses the translation, and delivers the response to the VM’s private IP.

This entire translation happens without any configuration on the VM itself. The VM only knows its private IP. Cloud NAT handles everything at the network edge.

Regional scope

A Cloud NAT gateway covers one region within one VPC. If you have private VMs in europe-west1 and us-central1, you need a Cloud NAT gateway in each region. A gateway in europe-west1 does nothing for VMs in us-central1.

Cloud Router dependency

Cloud NAT requires a Cloud Router in the same region and VPC. Cloud Router is a managed BGP speaker. Cloud NAT uses it as a regional control-plane component. You do not need to configure BGP sessions for this use case; just create the Cloud Router and attach the NAT gateway to it.

NAT IP addresses

Your NAT gateway can use:

• Auto-allocated IPs: GCP assigns public IPs automatically and adds more as demand grows. Simpler to manage, but the IPs can change over time.
• Reserved static IPs: you reserve specific external IP addresses and assign them explicitly. The outbound IP stays constant, which is required when external systems need to allowlist your traffic by IP.

When to use Cloud NAT

Use Cloud NAT when private VMs need to reach destinations on the public internet:

• OS and software updates: apt, yum, and similar package managers pull from public repositories. Private VMs without Cloud NAT cannot run updates.
• Container image pulls: pulling from Docker Hub, GitHub Container Registry, or other public registries requires outbound internet access.
• Third-party API calls: sending data to payment processors, analytics endpoints, external monitoring services, or other partner APIs.
• IP allowlisting requirements: when external services require a fixed source IP from you, use Cloud NAT with reserved static IPs. You control exactly which IP appears in outbound traffic.
• Private GKE nodes: nodes in private GKE clusters have no external IPs. Cloud NAT is how those nodes pull images from the internet and reach external endpoints during workload execution.
• Serverless egress to the internet: Cloud Run and Cloud Functions can reach the internet directly by default, but if your workloads are attached to a VPC via Serverless VPC Access, all their traffic routes through the VPC. Add Cloud NAT to that VPC to give those workloads outbound internet access.

When not to use Cloud NAT

Cloud NAT solves one specific problem: outbound internet from private VMs. For other connectivity needs, different services are a better fit:

• Reaching Google APIs privately: use Private Google Access. Traffic to Cloud Storage, BigQuery, Pub/Sub, and other Google services should stay on Google’s internal network, not go through Cloud NAT to the public internet.
• Accepting inbound traffic from the internet: Cloud NAT does not support this at all. Assign an external IP directly to the VM, or put a load balancer in front of it. See Private vs Public IP Addresses for guidance on when each approach fits.
• Private connectivity to on-premises or another cloud: use Cloud VPN, Cloud Interconnect, or VPC Peering depending on the topology. Cloud NAT has nothing to do with private network paths between environments.
• Internal VPC-to-VPC traffic: traffic between VMs in the same VPC, or across VPCs via peering, stays on Google’s private network. Cloud NAT is not involved and not needed for this.
• Shared VPC outbound: in a Shared VPC setup, Cloud NAT is configured in the host project. Service projects use the host project’s NAT gateway. Do not create duplicate gateways in service projects.

Cloud NAT vs Private Google Access

These two services are frequently confused because both allow private VMs to reach external destinations. They are complementary, not competing. Most production environments use both.

If your VMs need to call both Google APIs and external internet services, enable Private Google Access on the subnet and configure Cloud NAT on the Cloud Router. They do not conflict.

Cloud NAT vs external IPs

Both approaches give a VM outbound internet access, but they have different security and operational characteristics.

For most backend workloads, Cloud NAT is the right default. Use external IPs only where inbound reachability is actually required. See Private vs Public IP Addresses and Network Security Best Practices for the broader context.

Setting up Cloud NAT

Cloud NAT requires a Cloud Router in the same region and VPC. Create that first, then attach the NAT gateway to it.

# Create a Cloud Router (required by Cloud NAT)
gcloud compute routers create my-nat-router \
  --network=my-vpc \
  --region=europe-west1

# Create a Cloud NAT gateway covering all subnets, with auto-allocated IPs
gcloud compute routers nats create my-nat-gateway \
  --router=my-nat-router \
  --region=europe-west1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

# Verify the gateway was created
gcloud compute routers nats describe my-nat-gateway \
  --router=my-nat-router \
  --region=europe-west1

The —nat-all-subnet-ip-ranges flag applies Cloud NAT to all subnets in that region within the VPC. To restrict coverage to specific subnets, use —nat-custom-subnet-ip-ranges=my-subnet instead.

You can also create Cloud NAT through the GCP Console under Network services > Cloud NAT, which walks through the same choices in a guided form.

Using static NAT IPs

If external systems need to allowlist your outbound IP (common for third-party APIs and partner firewall policies), reserve a static external IP and assign it explicitly to the gateway.

# Reserve a static external IP for NAT use
gcloud compute addresses create my-nat-ip \
  --region=europe-west1

# Create Cloud NAT using the reserved static IP
gcloud compute routers nats create my-nat-gateway \
  --router=my-nat-router \
  --region=europe-west1 \
  --nat-all-subnet-ip-ranges \
  --nat-external-ip-pool=my-nat-ip

Your outbound traffic will consistently appear from my-nat-ip. Give that IP to the external system for allowlisting. It will not change unless you replace the reserved address.

Logging, ports, and scaling

NAT logging

Cloud NAT can log translation events to Cloud Logging, which is useful for auditing and diagnosing connectivity issues.

# Enable logging on an existing Cloud NAT gateway
gcloud compute routers nats update my-nat-gateway \
  --router=my-nat-router \
  --region=europe-west1 \
  --enable-logging \
  --log-filter=ALL

# Query Cloud NAT logs in Cloud Logging
gcloud logging read \
  'resource.type="nat_gateway" AND resource.labels.router_id="my-nat-router"' \
  --project=my-project \
  --limit=20

Port allocation and exhaustion

Each NAT IP address provides 64,512 usable ports. Cloud NAT allocates a minimum number of ports per VM when the gateway starts. The default is 64 ports per VM.

For most background workloads (periodic updates, occasional API calls), 64 ports is enough. For VMs making many simultaneous outbound connections (high-throughput data pipelines, parallel HTTP clients, batch jobs with hundreds of threads), 64 ports can run out. When port exhaustion hits, new outbound connections fail intermittently in ways that are hard to diagnose without metrics.

Watch the nat/allocated_ports metric in Cloud Monitoring. If VMs are approaching their port ceiling, increase the minimum before you see failures.

# Increase minimum ports per VM
gcloud compute routers nats update my-nat-gateway \
  --router=my-nat-router \
  --region=europe-west1 \
  --min-ports-per-vm=256

See Troubleshooting Network Issues for a broader packet-path validation approach when port metrics alone are not enough.

Troubleshooting Cloud NAT

If a private VM cannot reach the internet, work through this checklist in order:

1. Same region check. Confirm the VM is in the same region as the Cloud NAT gateway. A gateway in europe-west1 does not serve VMs in us-central1.
2. Correct VPC and Cloud Router. Verify the Cloud Router and NAT gateway exist in the same VPC as the VM. Check with gcloud compute routers list and gcloud compute routers nats list —router=my-nat-router —region=europe-west1.
3. Default route exists. Confirm that 0.0.0.0/0 via the default internet gateway is present in the VPC. See Routes in GCP. Cloud NAT depends on this route being in place.
4. Firewall egress rules. If your VPC has deny-all egress, confirm there is an allow rule covering the destination port and IP range. See Firewall Rules Explained.
5. Subnet coverage. Check whether the VM’s subnet is included in the NAT gateway’s coverage. If you used —nat-custom-subnet-ip-ranges at creation time, the VM’s subnet may have been excluded.
6. NAT logging. Enable ERRORS_ONLY logging on the gateway and check Cloud Logging for translation errors. Error logs often point directly at the cause.
7. Port exhaustion. Check the nat/allocated_ports metric in Cloud Monitoring. If VMs are hitting their port ceiling, new connections will fail intermittently. Increase —min-ports-per-vm.
8. Serverless connector validation. If this is a Cloud Run or Cloud Functions workload, verify that a Serverless VPC Access connector is correctly attached. See Serverless VPC Access.

For packet-level validation and more advanced network diagnosis, see Troubleshooting Network Issues.

Frequently asked questions

What is Cloud NAT in GCP?

Cloud NAT is a managed, software-defined Network Address Translation service. It lets VM instances that have no external IP address initiate outbound connections to the internet. The VM sends traffic with its private IP; Cloud NAT replaces the source with a public NAT IP, forwards the packet, and delivers the response back to the VM. No inbound sessions can be started through Cloud NAT — only connections initiated by the VM are possible.

Does Cloud NAT allow inbound internet traffic?

No. Cloud NAT is strictly outbound. Your VMs can initiate connections and receive responses, but no external host can start a new connection to a VM through Cloud NAT. If you need a VM to receive inbound internet traffic, assign it an external IP, place it behind a load balancer, or use a reverse proxy. Cloud NAT provides no inbound path.

What is the difference between Cloud NAT and Private Google Access?

Cloud NAT routes traffic from private VMs out to the public internet for any destination. Private Google Access is a subnet-level flag that opens a private path from VMs to Google-managed APIs (Cloud Storage, BigQuery, Pub/Sub), without any internet traversal. For reaching Google APIs, Private Google Access is faster and cheaper. For reaching anything outside of Google — third-party APIs, package repos, public registries — use Cloud NAT. Most environments need both. See Private Google Access for the full comparison.

Do I need one Cloud NAT gateway per region?

Yes. Cloud NAT is regional. Each gateway covers VMs in one region of one VPC. If you have private VMs spread across multiple regions, create a Cloud NAT gateway in each region. Each one needs its own Cloud Router in the same region and VPC.

When should I use static NAT IPs?

Use static NAT IPs when external systems need to allowlist your outbound IP addresses. Third-party APIs, SaaS platforms, and partner firewalls often require a known, stable source IP before they will accept your traffic. Reserve a static external IP, then assign it to your Cloud NAT gateway. Your outbound traffic will always appear from that IP. Without static assignment, Cloud NAT uses auto-allocated IPs that can change over time.