---
cuppy_hub: gcp
cuppy_path: reference/networking/cloud-nat.md
cuppy_section: docs
cuppy_doc: 3QD2-VQ3H
cuppy_doc_uuid: de56da51-7868-4050-8da4-5447e490dbf4
cuppy_permalink: https://cuppy.io/gcp/d/3QD2-VQ3H
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/networking/cloud-nat
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: e17321ac341fbe6f29deda91fa0caccee133816d1cbd1b9450871ec1d148979f
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Cloud NAT

## 1. What it is

> "Cloud NAT provides network address translation (NAT) for outbound traffic to the internet, Virtual Private
> Cloud (VPC) networks, on-premises networks, and other cloud provider networks."

And, crucially, what it is **not**: not a proxy, not an appliance, not a VM. It is "a distributed,
software-defined managed service" that configures the **Andromeda** software underneath your VPC network.

**There is nothing to size, patch, scale or pay an instance fee for.** For an engineer arriving from a cloud
where the NAT gateway is a billed, zonal, throughput-bounded resource, this is the most important line on the
page — and it changes both the architecture diagram and the availability story
(`guides/parity/networking.md` §4).

## 2. Two NAT types

| Type | For |
|---|---|
| **Public NAT** | outbound internet connectivity for resources with **no external IP address** |
| **Private NAT** | private-to-private translation between VPC networks, or to on-premises systems |

Private NAT is the one most people do not know exists, and it is the answer to overlapping RFC 1918 ranges
between two networks you must connect — a situation almost every merger-driven migration contains.

## 3. The sentence that settles the inbound question

> "Cloud NAT supports address translation for **established inbound response packets only**. It **doesn't allow
> unsolicited inbound connections**."

So Cloud NAT is not a path in. Anything that must be reachable needs a load balancer
(`reference/networking/cloud-load-balancing.md`), **Private Service Connect**
(`reference/networking/private-service-connect.md`), or an external address on the instance itself. No NAT
configuration makes an inbound connection possible, and time spent looking for one is wasted.

## 4. It is configured on a Cloud Router

The **Cloud Router** "provides the control plane for NAT, holding configuration parameters". So:

- the NAT configuration is **per region**, because that is where a Cloud Router lives;
- the same Cloud Router object also carries BGP for Cloud Interconnect and Cloud VPN, which is why it appears
  in designs that have nothing to do with NAT;
- in IaC terms, a NAT is a child of a router, not of a subnet. Getting that wrong is the commonest
  Terraform-side mistake here.

**Manual NAT IP address assignment** is named as an option — it is what you use when an external system must
allowlist your egress addresses. *Recorded as an absence:* the overview page does **not** name specific
port-allocation modes, so none are stated here; read the port-allocation page before sizing a high-connection
workload.

## 5. For a migration

Three line items disappear when NAT moves to Google Cloud: the NAT gateway resource, its per-zone redundancy,
and its hourly charge as a separate billed appliance. What remains is the **egress data** charge, which is the
dimension that actually matters at scale and which is the same shape on all three clouds.

What appears, in the other direction, is all three of those as new line items — plus a throughput ceiling to
design around.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->
