A few simple ideas make Cloud NAT easy to understand.

IP addresses: public and private

Every device on a network has an address, called an IP address, that lets others send data to it. A public address can be reached by anyone on the internet. A private address is meant only for use inside an organization’s own network, and the internet does not know how to deliver traffic to it directly. Your home devices use private addresses, and your home router uses one public address for all of them together.

Why not give everything a public address?

There are two big reasons. First, public addresses are limited and cost money. Second, a machine with a public address is a machine that attackers can try to reach. Automated scanners across the internet constantly probe public addresses looking for weak spots. Keeping machines private removes that exposure completely.

The catch: private machines still need the outside world

Even a locked-down private server often needs to reach out. It may need to download security updates, fetch software packages, call a payment provider’s service, send an email through an external service, or talk to a partner’s application. A private address alone cannot do this, because replies need somewhere public to come back to.

What NAT does

NAT stands for Network Address Translation. A NAT device sits between your private machines and the internet. When a private machine sends a request out, NAT swaps the private source address for one of its own public addresses, remembers who asked, and sends the request on. When the reply comes back, NAT looks up its memory, swaps the address back, and hands the reply to the right private machine.

A fully managed, software-defined NAT service built into Google Cloud’s network.

Cloud NAT is Google Cloud’s managed network address translation service. It lets virtual machines, container clusters and certain serverless workloads that have no external IP address make outbound connections to the internet, and receive the responses to those connections. It does not let the internet start new connections to those machines. That one-way-in-spirit behavior is what makes it a strong security tool.

The most important design point is that Cloud NAT is not a virtual machine that you run. In many traditional setups, teams create a special NAT server, which becomes a bottleneck, a single point of failure and a machine that must be patched and monitored. Cloud NAT is instead built into Google’s software-defined networking layer. Translation happens as traffic leaves the host machine, so there is no middle machine to slow things down or break, and it scales along with your workloads.

A short dictionary of Cloud NAT words.

Following one connection from start to finish.

Suppose a private virtual machine wants to download a software update from a public website. The machine has only an internal address. It sends its request toward the internet. Because there is no external address on the machine, the request is handled by the network layer, which sees that a Cloud NAT gateway applies to this machine’s subnet. The network then translates the source address from the machine’s private address to one of the gateway’s public addresses, and assigns a source port from the block of ports reserved for this machine. The request travels to the website, which sees only the public address.

The website replies to that public address and port. Google’s network recognizes the reply as belonging to an existing mapping, translates the destination back to the machine’s private address, and delivers it. If someone on the internet instead tries to start a brand-new connection to the public NAT address, there is no matching mapping, so the traffic is dropped. That is the security benefit.

sequenceDiagram
    participant VM as Private VM
    participant NAT as Cloud NAT
    participant WEB as Public Website
    VM->>NAT: Request from private address, source port 40001
    NAT->>NAT: Swap to public NAT address and an allocated port, store mapping
    NAT->>WEB: Request from public address
    WEB-->>NAT: Reply to public address and port
    NAT->>NAT: Find mapping, swap back to private address
    NAT-->>VM: Reply delivered
    WEB-xNAT: Unsolicited new connection attempt is dropped
        

One address, many connections: the role of ports

A single public address has tens of thousands of usable ports, and each active connection to a particular destination needs its own. Cloud NAT divides the available ports among the machines it serves, so that many private machines can safely share a small number of public addresses. More addresses mean more total ports, and therefore more simultaneous connections.

The kinds of workloads that benefit from private outbound access.

Beginners often mix these up, so let us separate them clearly.

Private Google Access lets resources without external addresses reach Google APIs and services, such as storage and data tools, using Google’s internal paths. Cloud NAT lets those same resources reach the general internet, such as public websites and third-party services. They solve different problems and are often used together.

The public faces your private machines wear when they go out.

Automatic allocation

With automatic allocation, Google picks and manages public addresses for the gateway and adds more when more ports are needed. This is the simplest option, and it scales without attention. The downside is that the specific addresses can change over time, so you cannot reliably give them to partners for allow-listing.

Manual allocation

With manual allocation, you reserve static external addresses in advance and assign them to the gateway. The outside world always sees the same, known addresses. This is the right choice whenever a partner, bank or software vendor requires you to supply fixed addresses to allow your traffic through their firewall. You must plan how many addresses you need, because the gateway can only use what you gave it.

The most common technical issue with any NAT service, explained gently.

Each connection from a private machine to a particular destination uses one source port on a NAT address. If a machine opens many connections to the same destination at the same time, it can use up its share of ports. When that happens, new connections fail until some free up, a situation called port exhaustion. Users may see timeouts or intermittent errors even though the network looks perfectly healthy.

How ports are shared

Cloud NAT reserves a block of ports for each machine that uses the gateway. You can set a minimum number of ports per machine. A higher minimum gives each machine more room, but means a given public address can serve fewer machines. Cloud NAT also offers dynamic port allocation, which starts each machine with a small number of ports and automatically increases it when the machine needs more, up to a limit you choose, and returns ports when demand falls. This balances efficiency with headroom.

Why destinations matter

Ports are tracked in combination with the destination. A machine can reuse the same source port for connections to different destinations, which means the real demand depends on how many simultaneous connections go to the same place. Chatty applications that talk heavily to a single external service are the most likely to exhaust their ports.

flowchart TD
    A[Machine opens many connections] --> B{Free ports left in its block?}
    B -->|Yes| C[Connection succeeds]
    B -->|No, dynamic allocation on| D[Gateway grants more ports up to the maximum]
    D --> C
    B -->|No, limit reached| E[New connections dropped - port exhaustion]
    E --> F[Fix: more ports per machine, more NAT addresses, or fewer simultaneous connections]
        

NAT forgets connections after a while, and that forgetting matters.

Cloud NAT keeps a mapping for each active connection, and releases it when the connection ends or sits idle too long. Different kinds of traffic have different idle timeouts, which you can tune within allowed limits. Long-lived established TCP connections are remembered for a long time, while idle UDP traffic is forgotten much faster. After a connection closes, a short waiting period prevents confusion between old and new connections that reuse the same port.

Why does this matter? If an application opens a connection, then stays silent for longer than the timeout, the mapping disappears. When the application finally sends data, the connection appears broken. The fix is usually for the application to send small keep-alive messages regularly, or to tune the timeout where allowed. Shorter timeouts free ports faster, which helps with exhaustion, while longer timeouts protect slow, quiet connections.

Cloud NAT is applied selectively, not blindly.

When you create a gateway, you choose which parts of the network it serves. You can apply it to all subnets in the region, to only the primary address ranges of all subnets, or to a custom list of specific subnets and ranges. This lets you give outbound access only to the tiers that truly need it, such as application servers that call outside services, while keeping a database tier completely isolated with no internet path at all.

Two flavors for two different problems.

Public NAT

Public NAT is what most people mean by Cloud NAT. It translates private addresses to public, internet-routable addresses so private resources can reach the internet.

Private NAT

Private NAT translates between private address spaces rather than to the internet. It solves a classic headache: two networks that must be connected but use overlapping address ranges, for example after a company merger or when connecting to a partner who uses the same private ranges. Instead of renumbering whole networks, which can take months, Private NAT presents resources to the other side using non-overlapping translated addresses, so the two sides can communicate. It is used with hybrid and multi-network connectivity features, and its availability and supported combinations should be confirmed in current documentation.

What you decide, in order, when adding Cloud NAT to a network.

flowchart LR
    subgraph VPC[Your VPC Network - one region]
        subgraph S1[Private Subnet]
            VM1[VM]
            VM2[VM]
            GKE[GKE Nodes and Pods]
        end
        CR[Cloud Router with NAT Gateway]
    end
    VM1 --> CR
    VM2 --> CR
    GKE --> CR
    CR -->|Translated to NAT IP addresses| INET[Internet]
    S1 -->|Private Google Access| GAPI[Google APIs]
        

NAT is simple to start but deserves thought as systems grow.

Because a Cloud NAT gateway is a regional configuration with no single machine behind it, it does not have a traditional single point of failure. Even so, good design matters. Each region of your network that has private workloads needs its own gateway, since a gateway serves only its own region. If your application runs in three regions, expect three gateways, each with its own addresses.

When partners allow-list your addresses, remember that they must allow the addresses of every region you use, and that traffic from a region leaves through that region’s gateway. Document the full list and keep it current as you add regions. Also consider that a very large fleet may need many addresses to have enough ports, so plan address capacity as part of regular capacity reviews.

What Cloud NAT protects, and what it does not.

What it gives you

Cloud NAT lets machines stay without public addresses, which removes them from the reach of internet scanners and direct attacks. It hides the real internal addresses from outside observers. It also provides a small, known set of outgoing addresses, which helps when you need to restrict or monitor where traffic is coming from.

What it does not do

Cloud NAT does not inspect or filter traffic. A compromised private machine can still call out to malicious servers through NAT unless other controls stop it. It is not a replacement for firewall rules, proxy or secure web gateway services, or monitoring. It also does not protect Google service traffic, which is governed by other controls.

flowchart TD
    A[Private addresses only - no direct internet exposure] --> B[Cloud NAT - outbound only translation]
    B --> C[Egress firewall rules - restrict destinations and ports]
    C --> D[Optional secure web gateway or proxy - inspect and filter]
    D --> E[Flow logs and NAT logs - detect and investigate]
        

Because NAT problems often look like random application errors.

A calm troubleshooting order

Small per unit, but worth watching at scale.

Cloud NAT pricing generally has a few parts: a charge related to the gateway and the number of machines it serves, a charge for the amount of data processed, and charges for the external IP addresses that the gateway uses. Regular internet egress charges for data leaving Google Cloud also apply. Exact rates change, so always use Google Cloud’s pricing page and calculator.

A balanced view of Cloud NAT.

Habits that save you from late-night surprises.

Best practices at a glance

Anti-patterns to avoid

No. It is a managed, software-defined service built into Google’s network. There is no NAT machine for you to run, patch or scale.

No. Cloud NAT handles connections your resources start and their replies. Unsolicited inbound connections are dropped. To publish a service, use a load balancer or another inbound design.

Not usually. Private Google Access lets resources without external addresses reach Google APIs. Cloud NAT is for the wider internet.

Regional. Each gateway serves resources in one region of one VPC network, so multi-region designs need a gateway in each region.

It happens when a machine has used all the NAT ports allocated to it, so new connections to the same destination fail. Fix it by enabling dynamic port allocation, raising port limits, adding NAT addresses, or making the application reuse connections.

Reserve static external addresses and configure the gateway for manual address allocation. Share those addresses, for every region you use, with the partner.

No. A machine with its own external address uses it directly for internet traffic. Cloud NAT serves machines without external addresses.

Yes, when their outbound traffic is routed through a VPC network, using a connector or direct network egress. They then share the NAT addresses, which gives them stable outbound addresses.

It translates between private networks, most commonly to connect networks whose address ranges overlap, without renumbering either one. Check current documentation for supported scenarios.

No. It translates addresses only. Use firewall rules, secure web gateway or proxy services, and logging for filtering and inspection.

Cloud NAT solves a simple but important problem: private resources need to reach the outside world without becoming reachable from it. As a managed, software-defined service, it removes the need for NAT servers, scales with your workloads, and keeps machines hidden behind a small set of public addresses. Using it well means choosing automatic or manual addresses based on whether partners must allow-list you, understanding that ports are a shared and limited resource, tuning timeouts, enabling logs and alerts, and pairing NAT with Private Google Access and egress controls. Treat it as one dependable layer in a larger security and networking design, and it will quietly do its job.