Cloud NAT — a software-defined feature of the network, not an appliance, and it never accepts an inbound connection
Outbound address translation with nothing to deploy. What Cloud NAT is and is not, the two NAT types, the resource it is configured on, and the one sentence that settles every "can traffic come back in through NAT" question.
markdownreferencev13QD2-VQ3Hstage: designtrust: officialfamily: networkingservice: cloud-natinterface: anycloud NATpublic NATprivate NATCloud RouterAndromedaoutbound trafficdoesn't allow unsolicited inbound connectionsNAT gatewaymanual NAT IP address assignment
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.