Cloud NAT in Google Cloud
A plain-English guide to Google's managed Network Address Translation service. Learn how private machines reach the internet without a public address, how ports are shared, how to give partners a fixed outbound address, and how to avoid the port exhaustion that surprises many teams.
Imagine a large office building with a thousand employees. The building has only a handful of phone lines to the outside world, yet every employee can call out whenever they like. When an employee dials out, the switchboard quietly swaps the employee’s internal extension for one of the building’s public numbers, remembers who made the call, and connects the reply back to the right desk. Nobody outside ever learns the internal extensions, and nobody can phone a desk directly without going through the switchboard.
Cloud NAT is that switchboard for your virtual machines in Google Cloud. Your servers can stay completely private, with no public address of their own, and still download software updates, call outside services and fetch data from the internet. Google runs the switchboard for you, spread across its network, so there is no machine to patch and no single point to fail. In this guide you will learn what Cloud NAT is, how it works inside, how ports are shared, how to give partners a fixed outbound address, how to watch it, and how to avoid the mistakes that cause mysterious connection failures.
Every new word is explained the first time it appears. You do not need any networking background before you begin. By the end, you will be able to explain Cloud NAT to a teammate, design a clean private network, and diagnose the most common NAT problems on your own.
AWhat Is Cloud NAT?
Start with the big picture: what Cloud NAT does, and just as important, what it does not do.
NAT stands for Network Address Translation. It is a technique in which a device on the edge of a network rewrites the addresses on network traffic as it passes through. In the most common form, a machine with a private address sends a message to the internet, and the NAT device replaces the machine’s private address with a public one. When the reply returns, the NAT device reverses the swap and delivers it to the right machine.
Cloud NAT is Google Cloud’s managed NAT service. It lets virtual machines, container nodes and other resources that have only private IP addresses make outbound connections to the internet. A private IP address is an address that works only inside your own network and cannot be reached from the public internet. Cloud NAT is outbound only. It allows your machines to start conversations with the outside world, and it allows the replies to those conversations, but it does not allow strangers on the internet to start a conversation with your machines.
Think of a hotel with a single public phone number. Guests in rooms can call out at any time, and the hotel’s switchboard shows the hotel’s number on the caller display. Replies are routed back to the right room. But a stranger who dials the hotel number cannot reach a guest room directly, because the switchboard does not know which guest they want. Cloud NAT is that switchboard.
A managed, software-defined service
The word managed means Google runs it for you. The words software-defined mean that the translation is performed by software inside Google’s virtual network, not by a separate machine that you create. There is no NAT virtual machine to size, patch, restart or protect. This matters a great deal, because a traditional NAT machine is a single choke point that every outbound connection must squeeze through. Cloud NAT is spread across Google’s network, so it does not create such a choke point.
What Cloud NAT is not
Cloud NAT is not a firewall. It does not decide which destinations your machines may reach, so on its own it lets any private machine talk to any internet address. It is also not a way to publish a service. If you want people on the internet to reach your application, you use a load balancer, not NAT. And it is not needed for talking to Google’s own services in many cases, because a separate feature called Private Google Access can handle that, as a later chapter explains.
Cloud NAT is configured per region and per network, and it depends on a helper called Cloud Router for its settings. Do not worry about this yet. The architecture chapter explains the relationship step by step.
BThe Problem Cloud NAT Solves
To understand any tool, first feel the pain it was built to remove.
Every computer on the internet needs an address so that replies can find their way back. The older address format, called IPv4, offers only about four billion addresses, and the world ran short of them years ago. Public addresses are therefore scarce and cost money. If every one of your thousand servers needed its own public address, you would pay for a thousand addresses, and you would also expose a thousand machines directly to the internet.
Exposure is the bigger problem. A machine with a public address can be probed by anyone in the world, around the clock. Attackers scan the whole internet constantly, looking for machines with open doors. A machine with only a private address is invisible to these scans, because there is no route from the internet to it. Security teams therefore prefer that back-end machines such as databases, application servers and batch workers have no public address at all.
But private machines still need to reach out. They must download operating system updates, install software packages, call payment services, send emails through outside providers, and fetch data from partners. Without a solution, a private machine would be cut off from the world, which is safe but useless.
It is like a company that wants its staff to be unreachable by cold callers, but still able to make phone calls. The answer is not to give every employee a publicly listed number. The answer is a switchboard that lets people call out while keeping direct dial-in numbers private.
The four big headaches
Public addresses are scarce
Giving every machine its own public address costs money and wastes a limited resource.
Public machines are exposed
Anything with a public address is scanned and attacked all day long, so the safest machines have none.
Private machines still need updates
Without outbound access, machines cannot fetch patches, packages or data from outside services.
Partners want fixed addresses
Banks and partners often allow traffic only from a short list of known addresses, which changing addresses would break.
The old way: a NAT machine you run yourself
Before managed NAT, teams built their own. They created a virtual machine with a public address, configured it to forward traffic for the private machines, and pointed the network routes at it. This worked, but it carried real pain. The machine was a single point of failure. Its network speed limited everything behind it. It needed patching, monitoring and careful high-availability design with several machines and health checks. Many outages were traced to a overloaded or crashed NAT machine.
Cloud NAT removes that whole burden. It scales with your traffic, it is built into Google’s network, and it has no machine for you to maintain. You pay only for what you use and you configure it with a few settings.
Because many machines share a small pool of public addresses and ports, you must understand how those ports are shared. When they run out, connections fail in confusing ways. Much of this guide is about that sharing, because it is the topic that most often surprises beginners.
CCore Concepts You Must Know
A handful of words explain almost everything in Cloud NAT. Learn them well and the rest becomes easy.
Private and public IP addresses
An IP address is the number that identifies a device on a network. A private address belongs to ranges reserved for use inside networks, and it is not valid on the public internet. A public, or external, address is unique across the whole internet. In Google Cloud, a virtual machine always has an internal address, and it may optionally have an external one as well.
Source NAT
Cloud NAT performs what is called source NAT. The source of a message is the sender. When a private machine sends a message out, the NAT service replaces the sender’s private address and port with a public address and port. The destination sees the public one and replies to it. The service then translates the reply back. This is why the technique is sometimes called address and port translation.
Ports and the five-part identity of a connection
An address alone is not enough to tell conversations apart, because a single machine may talk to many places at once. A port is a number between 0 and 65,535 that labels one end of a conversation, like an apartment number within a building. Every connection is identified by five pieces of information: the source address, the source port, the destination address, the destination port and the protocol, such as TCP or UDP. Together they are called the five-tuple.
Think of a courier delivering parcels to a large apartment block. The street address is the IP address, and the flat number is the port. One building can receive thousands of different parcels at the same time, because each parcel carries a different flat number. NAT works by giving each outgoing conversation its own flat number on the shared public address.
NAT gateway, NAT IP and Cloud Router
NAT gateway
The configuration object that you create. It says which machines are covered, which public addresses to use and how ports are shared.
NAT IP address
A public address that outgoing traffic is rewritten to use. A gateway can use one or many.
Cloud Router
A regional helper that holds the NAT gateway’s configuration. It is used for control, and it does not carry your traffic.
VPC network
Your private virtual network in Google Cloud. A NAT gateway serves one region of one network.
Subnet and subnet ranges
A subnet is a slice of your network’s address space located in one region. Each subnet has a primary range for machines, and it can have secondary ranges used for other purposes, such as container pods in Kubernetes. When you configure Cloud NAT, you choose which subnets, and which ranges inside them, are allowed to use the gateway.
Connection tracking
To translate replies correctly, the NAT service must remember every active conversation. This memory is called a connection table or connection tracking. Entries are created when a conversation starts and removed after a period of silence, called a timeout. The size of this memory and the length of the timeouts affect how many conversations can be active at once, which is a recurring theme in later chapters.
A virtual machine that already has its own external address does not use Cloud NAT for that interface. It sends traffic directly using its own public address. NAT is only for machines without one.
DPublic NAT and Private NAT
Cloud NAT comes in more than one flavour. Picking the right one depends on where the traffic is going.
The product names and options evolve, so confirm the current list in the official documentation. At the time of writing, the two main kinds are public NAT and private NAT.
Public NAT
Translates private addresses to public addresses so machines can reach the internet. This is the classic use and the one most people mean when they say Cloud NAT.
Private NAT
Translates between private address ranges, for example between two networks or between a cloud network and an office network whose address ranges overlap. No public addresses are involved.
Public NAT is the switchboard that lets staff call outside numbers. Private NAT is a special internal switchboard between two buildings that happen to use the same extension numbers. It renames extensions so calls between the buildings do not get confused.
Why private NAT exists
When companies merge, or when a company connects its cloud network to an office network, two networks sometimes use the same private address ranges. Ordinary routing cannot connect two networks with overlapping ranges, because an address could mean two different machines. Private NAT solves this by translating one side’s addresses into a different, non-overlapping range, so the two sides can talk without renumbering either network. It is an advanced tool, often used with hybrid connections and with a network connectivity service. This guide spends most of its time on public NAT, and mentions private NAT where it matters.
Choosing between them
| Question | Public NAT | Private NAT |
|---|---|---|
| Where does the traffic go? | To the public internet | To another private network |
| What addresses are used? | Public external addresses | Private ranges chosen for translation |
| Typical reason | Updates, outside APIs, partner access | Overlapping address ranges between networks |
| Complexity | Low | Higher, needs careful planning |
| Common beginner need | Yes, almost always | Rare |
If your goal is “my private machines must reach the internet”, you want public NAT. If your goal is “two private networks with clashing addresses must talk”, look at private NAT, and read the current documentation carefully because the setup involves other networking services too.
EArchitecture and Components
Let us look at the main pieces that sit between a private machine and the internet.
Cloud NAT is unusual because it is not a box in the path. It is a set of rules applied by Google’s virtual network at the point where traffic leaves each machine’s host. The diagram shows the pieces and how they relate.
flowchart LR
VM1["VM A: private IP only"] --> SDN["Google Virtual Network Layer"]
VM2["VM B: private IP only"] --> SDN
GKE["GKE Node and Pods"] --> SDN
SDN --> NAT["Cloud NAT Translation Rules"]
NAT --> NIP["NAT External IP Addresses"]
NIP --> NET["Public Internet"]
CR["Cloud Router: holds NAT config"] -.->|"Control only"| NAT
ADM["Admin via Console, API or Terraform"] --> CR
NAT --> LOG["Cloud Logging and Monitoring"]
Walking through the diagram
Your private machines, whether plain virtual machines or the nodes and pods of a Kubernetes cluster, send their internet-bound traffic into Google’s virtual network layer. This layer is the software that creates your VPC network on top of Google’s physical hardware. When it sees traffic from a covered machine heading to the internet, it applies the Cloud NAT translation rules, swapping the private source address and port for one of the NAT external IP addresses and a port from that address’s pool. The packet then continues to the internet.
The Cloud Router in the diagram is only the place where the NAT settings are stored. It is a regional control object, and your traffic does not flow through it. When you change NAT settings through the console, the programming interface or an infrastructure tool, the change is saved on the router and then applied to the translation layer. Logs and metrics flow out of the NAT layer so you can watch what is happening.
Imagine a large airport where passport desks are built into every gate, instead of one giant checkpoint at the exit. Passengers are processed at their own gate, so there is never a long single queue. The rulebook that tells every gate how to process passengers is kept in one office (the Cloud Router), but passengers never visit that office.
Key components in plain words
Covered machines
Virtual machines, container nodes and other resources without external addresses, in the subnets you selected.
NAT translation layer
Software in the host network that rewrites addresses and ports for outgoing traffic and reverses it for replies.
NAT IP addresses
Public addresses reserved by you or allocated automatically, which the world sees as your source.
Cloud Router
Regional object that stores the gateway configuration. It is not in the data path.
Connection table
Tracks active conversations so replies return to the right machine.
Logging and metrics
Records of translations and errors, plus numbers about ports, traffic and dropped packets.
Scope: one region, one network
A NAT gateway covers a single region of a single VPC network. If you have machines in three regions, you need a gateway in each region. The gateways are independent of each other. This regional design is why high availability is built in: a failure in one zone of a region does not remove the gateway, because the gateway is not tied to any single machine or zone.
A team creates a NAT gateway in one region, then deploys machines in another region and wonders why they have no internet access. Always create a gateway in every region that has private machines needing outbound access.
FInternal Working: The Life of an Outbound Connection
Follow one single connection from a private machine to an internet server and back.
Let us trace what happens when a private virtual machine downloads a software package from a server on the internet. The goal is to see exactly where the address swap happens and what the NAT service remembers.
sequenceDiagram
participant V as Private VM
participant N as Cloud NAT Layer
participant S as Internet Server
V->>N: Packet from 10.0.0.5 port 40000 to server port 443
N->>N: Pick NAT IP 203.0.113.7 and a free port 1500
N->>N: Record mapping in connection table
N->>S: Packet from 203.0.113.7 port 1500 to server port 443
S-->>N: Reply to 203.0.113.7 port 1500
N->>N: Look up mapping and reverse the swap
N-->>V: Reply to 10.0.0.5 port 40000
Step by step
The machine sends a packet
The private machine opens a connection to an internet server. Its packet carries the machine’s private address and a source port chosen by its operating system.
The network layer applies NAT
Google’s virtual network sees that the destination is outside the VPC, that the machine has no external address and that its subnet is covered by a gateway, so it hands the packet to the NAT rules.
A public address and port are chosen
The NAT rules pick one of the NAT external addresses and a free port from the range reserved for this machine, then write down the mapping in the connection table.
The packet leaves with a public source
The packet now shows the public address and port as its sender. The internet server sees only these, never the private address.
The reply returns and is translated back
The server replies to the public address and port. The NAT rules look up the mapping, swap the destination back to the private address and port, and deliver the packet to the machine.
The mapping expires after silence
When the conversation ends, or has been silent for longer than the timeout, the mapping is removed and the port becomes available again.
Why unsolicited traffic is blocked
The connection table is also what keeps your machines safe. An incoming packet is accepted only if it matches an existing mapping, which means it must be a reply to something your machine started. A packet from a stranger, aimed at your NAT address, matches nothing and is dropped. This is called stateful behaviour, because the service keeps a state for each conversation. It is why Cloud NAT cannot be used to host a public service: there is nothing for an outside visitor’s first packet to match.
The switchboard operator keeps a notebook of every outgoing call: “Room 12 called the bakery on line 3.” When a call arrives on line 3 from the bakery, the operator checks the notebook and connects it to room 12. A call on line 3 from a stranger finds no entry in the notebook and is politely refused.
Where the time goes
Because the translation happens in the host’s virtual network, the extra delay is tiny. There is no extra hop to a separate NAT machine and no queue to wait in. For most applications, you will not notice any difference between a machine using Cloud NAT and one using its own public address. The more important cost is not speed. It is the finite supply of ports, which the next chapters explain.
Cloud NAT allows replies to connections your machines started. If a partner needs to start a connection toward your private machine, NAT is the wrong tool. Use a load balancer or a private connection instead.
GWho Gets to Use the Gateway?
A NAT gateway does not automatically cover every machine. Several rules decide whether a given machine will use it.
When a private machine cannot reach the internet, the first question is always whether the gateway really covers it. The decision depends on a short chain of checks. Understanding the chain turns many mysteries into quick fixes.
flowchart TD
S["Packet leaves a VM for an internet address"] --> E{"Does the VM interface have an external IP?"}
E -- "Yes" --> D1["Sent directly with the VM's own external IP, NAT not used"]
E -- "No" --> G{"Is there a NAT gateway for this network and region?"}
G -- "No" --> X1["No route to the internet, packet is dropped"]
G -- "Yes" --> R{"Is the source subnet range covered by the gateway?"}
R -- "No" --> X2["Not translated, traffic fails"]
R -- "Yes" --> RT{"Does a route to the internet gateway exist?"}
RT -- "No" --> X3["Default route missing or replaced, traffic fails"]
RT -- "Yes" --> OK["Translated by Cloud NAT and sent out"]
The four checks explained
No external address on the interface
A machine with its own external address bypasses NAT. For private machines, make sure no external address was attached by accident. Some deployment templates attach one by default.
A gateway in the same region and network
The gateway must exist in the same region as the machine and in the same VPC network. A gateway in another region or network does not help.
The subnet range is covered
You choose whether the gateway covers all subnets, or only chosen ones, and whether it covers only primary ranges or also secondary ranges. A machine in an uncovered range gets no translation.
A route to the internet exists
Your network needs a route whose next hop is the default internet gateway. If a custom route sends all traffic elsewhere, for example to a firewall appliance, the traffic never reaches the NAT rules.
Choosing which subnet ranges to cover
All subnets, all ranges
The simplest option. Every machine in the region without an external address is covered, including future subnets. It is convenient but broad.
All primary ranges
Covers the main machine ranges of every subnet, but not secondary ranges such as those used by container pods.
Custom list of subnets and ranges
You name exactly which subnets and ranges are covered. This gives the tightest control and is best for security-minded designs.
The gateway is like a door that opens only for people on a guest list. You can say “everyone in the building may use it”, or “only the second floor”, or “only these named people”. The shorter the list, the safer the door, but the more often you must update the list.
The easily forgotten secondary ranges
In Kubernetes clusters, each pod gets an address from a secondary range of the subnet. If your gateway covers only primary ranges, the nodes will reach the internet, but the pods will not, because their traffic carries pod addresses that the gateway does not cover. Either include the secondary ranges in the gateway, or configure the cluster so that pod traffic is rewritten to the node’s address before it leaves. The Kubernetes chapter returns to this.
If you force all internet traffic through a firewall appliance or a proxy using a custom default route, Cloud NAT is bypassed for that traffic. NAT needs the standard route to the default internet gateway to be present for the traffic you want translated.
HPorts, IP Addresses and Port Allocation
This is the most important chapter in the guide. Almost every Cloud NAT surprise comes from how ports are shared.
Each public NAT address offers a fixed supply of ports. Roughly sixty-four thousand of them are usable for translation, because the lowest numbers are reserved for special purposes. Every active outbound connection to a particular destination needs its own port on a NAT address. When many machines share a small number of addresses, the ports are divided among them, and each machine is given its own slice.
Picture a hotel with a limited number of outside phone lines. The hotel divides the lines among rooms in advance, so that each room has, say, sixty-four lines reserved. A busy room can make sixty-four calls at once, and not one more, even if other rooms are sitting idle. Cloud NAT hands out port slices in just this way.
Why destination matters
A port is only unique together with the destination. Because the five-part identity includes the destination address, destination port and protocol, the same NAT address and port can be reused for connections to different destinations. So the limit is not “sixty-four thousand connections in total”. It is closer to “sixty-four thousand connections to the same destination address, port and protocol, per NAT address”. A machine talking to a thousand different servers can use far more connections than one talking to a single server. This is the reason that heavy traffic to one popular endpoint, such as a single API address, is the classic cause of trouble.
Static and dynamic port allocation
Static allocation
Every machine receives the same fixed number of ports, set by the minimum-ports-per-VM setting. Simple and predictable, but wasteful for idle machines and too small for busy ones.
Dynamic allocation
A machine starts with a small number and receives more when it needs them, up to a maximum you set. Ports return to the pool when no longer needed. Far better use of a limited supply.
flowchart TD
A["New outbound connection from a VM"] --> B{"Does the VM have a free port in its slice?"}
B -- "Yes" --> C["Use that port and translate"]
B -- "No" --> D{"Is dynamic allocation on and below the maximum?"}
D -- "Yes" --> E["Allocate more ports to this VM"]
E --> C
D -- "No" --> F["Connection fails: OUT_OF_RESOURCES"]
F --> G["Logged and counted as a dropped packet"]
Reading the diagram
A new connection first looks in its machine’s existing slice. If a port is free, it is used immediately. If the slice is full, behaviour depends on the allocation mode. With dynamic allocation, the gateway enlarges the slice, provided the machine is below its configured maximum and the address pool still has room. If neither is possible, the connection fails and the event is recorded as an out-of-resources drop. This failure is called port exhaustion.
How many machines can one address serve?
Divide the usable ports by the ports each machine gets. If each machine receives sixty-four ports, one address supports roughly a thousand machines. If each receives a thousand, one address supports only about sixty-four machines. The right setting depends on how many simultaneous connections your busiest machines need, and how many machines you have. Adding more NAT addresses enlarges the pool, so both numbers can grow.
| Setting | What it controls | Effect of raising it |
|---|---|---|
| Minimum ports per VM | Guaranteed starting slice | More headroom per machine, fewer machines per address |
| Maximum ports per VM | Ceiling when dynamic allocation is on | Busy machines can grow further |
| Number of NAT addresses | Total pool size | Supports more machines or more ports each |
| Endpoint-independent mapping | Whether one port is reused across destinations | Helps some protocols but uses ports less efficiently |
A machine running many short-lived connections can use up its ports even if it never has many connections open at one moment, because closed connections keep their port reserved for a short while before it is reused. Fast, bursty traffic is the usual culprit.
Automatic versus manual NAT addresses
With automatic addressing, Google allocates public addresses as your port needs grow, and may add or release them over time. This is convenient, but your outbound addresses can change, which is bad if a partner has allowlisted them. With manual addressing, you reserve specific static external addresses and assign them to the gateway. They never change, and you control the pool size. If anyone must recognise your addresses, choose manual.
ITimeouts, Protocols and Connection Behaviour
How long does the switchboard remember a call that has gone quiet? The answer shapes both reliability and port usage.
A NAT gateway cannot keep conversation records forever, so it forgets those that have been idle for a set time. Separate timeouts exist for different protocol states. The exact defaults and ranges change over time, so check the current documentation before relying on any number. The ideas, however, are stable.
Established TCP
For live, healthy TCP conversations. Long timeouts avoid dropping quiet but valid connections such as database sessions.
Transitory TCP
For connections that are opening or closing. Short values return ports quickly to the pool.
Time-wait
How long a closed connection’s port stays reserved to catch stray late packets.
UDP and ICMP
These protocols have no connection concept, so the gateway uses a quiet-time limit instead.
The trade-off in timeout lengths
Short timeouts free ports sooner, which reduces exhaustion, but they risk cutting off conversations that are merely quiet. A long-lived connection that sits idle for a few minutes, for example a pooled database connection, may find its mapping gone, and the next message on it will fail. Long timeouts protect such connections but hold ports longer. The usual remedy is to keep connections alive with periodic small messages, called keepalives, which reset the idle timer. Setting application keepalives shorter than the NAT timeout is a quietly powerful habit.
It is like a restaurant holding a table for a party that has not arrived. Hold it too long and other guests wait outside. Release it too quickly and the party returns to find their table gone. A quick text to say “we are on our way” is the keepalive.
Endpoint-independent mapping
By default, each connection gets its own port mapping, tied to its destination. Some applications, such as certain peer-to-peer and real-time communication protocols, expect the same public address and port to be used no matter where the traffic goes. Endpoint-independent mapping provides this. It helps those protocols, but it makes ports less reusable, so it increases exhaustion risk. Enable it only when an application demonstrably needs it.
Supported traffic
Cloud NAT handles the common protocols of TCP, UDP and ICMP for outbound use. It translates IPv4 traffic. Details such as IPv6 handling and fragmented packets have specific rules in the documentation, so confirm anything unusual before designing around it.
Whenever an application complains about connections dropping after a few quiet minutes, check the NAT idle timeout first, then set the application’s keepalive interval below it.
A worked example: counting ports for a small shop
Imagine a small shop with forty application machines in one region. Each machine is given a minimum of sixty-four ports. That reserves two thousand five hundred sixty ports, which is a small fraction of one address. Most of the day, this is plenty. But the nightly report job runs on four of those machines, and each opens about two thousand connections to the same analytics provider. With the minimum slice, the report job would fail after sixty-four connections. With dynamic allocation and a maximum of four thousand ports, the four machines can grow to what they need, using eight thousand ports at the peak. The total is still well below the capacity of a single address, so the shop needs only one address for ports, and a second one purely for resilience and to be safe during growth. This small calculation shows the real power of dynamic allocation: busy machines borrow from the idle majority, and everything is returned when the job finishes.
What happens when the pool is nearly full
As the pool fills, new connections start to fail one machine at a time, usually the busiest ones first. Because the failures are intermittent, applications often retry, and each retry opens another connection, which makes the shortage worse. Teams call this a retry storm. Good clients use gradual back-off, waiting a little longer after each failed attempt, so they do not pile onto an already stressed pool. Pair back-off with alerts on port usage, and a near-miss becomes a calm ticket rather than a night-time incident.
JCloud NAT with GKE and Serverless Services
Containers and serverless platforms bring their own twists, because many small workloads share few addresses.
Google Kubernetes Engine
GKE is Google’s managed Kubernetes service. A cluster consists of nodes, which are virtual machines, and pods, which are small groups of containers running on the nodes. In a private cluster, nodes have no external addresses, so they rely on Cloud NAT to pull container images from outside registries and call outside services.
Pods usually receive addresses from a secondary subnet range. If the gateway covers only primary ranges, pod traffic may fail to translate. Pods are also numerous, so they can consume ports quickly: a node running a hundred pods shares one slice of ports among all of them. Dynamic port allocation and a sensible maximum are strongly recommended on GKE, and the node count and pod density should be part of your port planning.
flowchart LR
P1["Pod 1"] --> N1["Node A: shared port slice"]
P2["Pod 2"] --> N1
P3["Pod 3"] --> N2["Node B: shared port slice"]
N1 --> NAT["Cloud NAT Gateway"]
N2 --> NAT
NAT --> IP["Static NAT IPs"]
IP --> EXT["External API or Registry"]
Each node is an apartment, and its pods are the residents sharing one allotment of phone lines. A crowded apartment with one heavy phone user can leave everyone else with a busy signal, even though the building has lines to spare.
Serverless platforms
Serverless services such as Cloud Run, Cloud Functions and App Engine run your code without visible servers. They do not live in your VPC by default, so their outbound traffic does not use your NAT gateway at all. To give them a fixed outbound address, you connect them to your network, using a connector or a direct network egress option, and route all their outbound traffic through the VPC. Then Cloud NAT can translate it, giving a stable source address. The exact feature names and settings change, so verify the current method before building.
Connecting a serverless service to the VPC is not enough. You must also tell it to send all outbound traffic, not just private-range traffic, through the VPC. Otherwise internet-bound traffic still leaves directly with changing Google addresses.
Autoscaling surprises
When a service scales from five instances to five hundred, port demand jumps with it. Each new instance needs its own slice. If the pool is sized for steady state, a sudden scale-out can exhaust it. Plan for the peak instance count, not the average.
KStatic Egress IPs and Partner Allowlisting
Many businesses send requests to partners who accept traffic only from known addresses. Cloud NAT is the standard way to provide them.
Egress means traffic leaving your network. Many banks, payment providers and partner firms keep an allowlist, a short list of source addresses permitted to call their systems. If your outbound addresses change, your calls are rejected until the partner updates the list, which can take days. With manual NAT addresses, you reserve a few static addresses, share them once, and every machine behind the gateway appears to come from exactly those.
Use case: paying through a bank API
A shop’s private order service must call a bank. The bank accepts only two addresses. The team reserves two static addresses, assigns them to the regional gateway, and sends them to the bank. Thousands of private machines now share those two addresses with no other change. If the shop adds a second region, it adds a second gateway with its own reserved addresses, and tells the bank about them in advance.
Sizing the address pool for allowlists
Partners prefer short lists, but short lists mean few ports. Work out your peak simultaneous connections to the partner, divide by the usable ports per address, and round up with generous headroom. Because ports are counted per destination, calls to one partner endpoint concentrate pressure on this arithmetic. If the partner is the main destination, size for it specifically.
Estimate peak connections
Count your busiest machines and the connections each opens to the partner at the same moment.
Reserve static addresses
Reserve more than you need today, because adding addresses later means asking the partner to update their list again.
Share and confirm
Send the addresses to the partner and wait for confirmation before switching traffic.
Cut over and watch
Move the gateway to manual mode with those addresses and monitor drops closely for the first days.
Reserve a spare address or two that are not yet attached. They cost little and save an urgent partner request during growth.
LPrivate Google Access Versus Cloud NAT
Two different features let private machines reach things outside the VPC. Confusing them leads to wasted money and wrong designs.
Private Google Access lets machines without external addresses reach Google APIs and services, such as Cloud Storage and BigQuery, using Google’s internal path. It is enabled per subnet, it needs no NAT gateway and it carries no per-gigabyte NAT processing fee. Cloud NAT is for reaching the rest of the internet. Many private machines need both: Private Google Access for Google services, Cloud NAT for everything else.
| Question | Private Google Access | Cloud NAT |
|---|---|---|
| Reaches | Google APIs and services | Any internet destination |
| Enabled at | Subnet level | Region and network, via gateway |
| Uses NAT ports? | No | Yes |
| Source seen by destination | Not a fixed public address | Your NAT address |
| Typical example | Reading from a storage bucket | Downloading an OS package |
Private Google Access is a private staff corridor to the company’s own warehouse next door. Cloud NAT is the front door and public road for everything else. Using the road to reach the warehouse works, but is slower, costs more and wastes road capacity.
The design lesson
Turn on Private Google Access for subnets whose machines talk to Google services. That keeps a large share of traffic away from your NAT ports and your NAT bill, and it reduces exhaustion risk. Many costly NAT surprises turn out to be Google API traffic that should never have used NAT. Whether Google API calls can be seen sharing NAT depends on how the machine is configured, so confirm the current behaviour in the documentation.
MSecurity with Cloud NAT
NAT hides your machines, but hiding is not the same as protecting. Here is what security you get and what you must add.
What NAT gives you
Cloud NAT keeps machines without public addresses unreachable from outside, since unsolicited inbound traffic matches no mapping. It gives a small, known set of outbound addresses that can be monitored and allowlisted. It reduces the attack surface: you expose fewer machines, so there are fewer doors to guard.
What NAT does not give you
NAT does not filter destinations. A compromised machine can still send data to any internet address, including an attacker’s server. This outbound path, called data exfiltration, is a core risk. Cloud NAT is not a firewall, not an intrusion detector and not a content filter.
Egress firewall rules
Use VPC firewall rules to allow outbound traffic only to needed destinations and deny the rest.
Secure web proxy
A managed proxy can allow only chosen websites and inspect web traffic, which NAT alone cannot do.
DNS controls
Control and log DNS lookups, because most malware must resolve a name before calling home.
Least privilege
Give machines only the permissions they need, so a breach cannot spread through your cloud account.
Log and alert
Record translations and flows, and alert on unusual destinations or volumes.
Narrow gateway scope
Cover only the subnets that truly need internet access, instead of every range.
NAT is the building’s mail room that stamps the company address on outgoing letters. It stops strangers walking in, but it does not read the letters. If an employee mails secrets to a rival, the mail room happily sends them. Reading and filtering mail needs separate guards.
Defence in depth for egress
Default deny outbound
Start with a rule blocking all outbound traffic, then allow only what is needed.
Route web traffic through a proxy
Allow only approved sites and keep records of what was requested.
Use NAT for approved destinations
Let the gateway translate what the earlier layers approved.
Watch the logs
Flag new destinations, big uploads and odd hours.
“Our machines have no public address” is a good start, not a security plan. Treat private machines as reachable by a determined attacker through your own supply chain, stolen credentials or vulnerable software.
Five myths worth busting
| Myth | Reality |
|---|---|
| “Cloud NAT is a firewall.” | It translates addresses. It does not decide which destinations are allowed, so firewall rules and proxies are still required. |
| “Cloud NAT lets me host a website privately.” | It is outbound only. Visitors need a load balancer or another inbound path. |
| “One NAT address means only sixty-four thousand connections in total.” | Ports are counted per destination, so the real limit depends on how many different places you talk to. |
| “The Cloud Router carries my traffic.” | It only stores configuration. Translation happens in the virtual network layer. |
| “Private machines cannot be attacked.” | They can be reached through stolen credentials, vulnerable software and infected downloads that your own machines fetch. |
A short security story
A small company runs a private reporting server. One day, a developer installs a helpful-looking library from a public package site, and the library quietly contains code that gathers the server’s secrets and sends them to an unknown address. Because the server can reach any internet address through Cloud NAT, the upload succeeds. Nothing is wrong with NAT; it did exactly what it was told. The missing piece was an outbound rule saying “this server may talk only to the package mirror and the database”. With that single rule, the stolen data would have gone nowhere, and the blocked attempt would have shown up in the logs as an alert. The lesson is simple: private does not mean harmless, and open outbound access is a risk in its own right.
For every workload, write one sentence that says where it is allowed to talk. If you cannot write that sentence, you do not yet know which outbound rules to create.
NMonitoring, Logging and Metrics
You cannot fix what you cannot see. Cloud NAT offers logs and metrics that reveal ports, drops and destinations.
Metrics: the numbers over time
A metric is a number measured repeatedly, such as once a minute, and plotted on a graph. Cloud NAT publishes metrics to Google’s monitoring service. The ones you should know are described in the cards below. Exact metric names are listed in the official documentation, so use these descriptions as a guide to what to look for.
Port usage
How many ports each machine is using compared with what it has been given. The earliest warning of trouble.
Dropped packets
Packets the gateway refused to send, with a reason such as running out of resources. Any sustained value deserves attention.
Sent and received bytes
How much data passes through, useful for cost estimates and spotting unusual spikes.
Allocated addresses and ports
How much of the shared supply is already handed out across the gateway.
Logs: the story of single events
Logs record individual events. Cloud NAT can log two kinds of events: translations, meaning that a connection was set up and a port was assigned, and errors, meaning that a packet was dropped because no port was available. You can log errors only, translations only, or both. Logging everything on a busy gateway generates large volumes and cost, so many teams log errors always and translations only when investigating or when compliance demands it.
| Logging choice | What you see | Best for |
|---|---|---|
| Errors only | Dropped connections and why | Everyday operations, low cost |
| Translations only | Who used which NAT address and port | Auditing and answering “which machine called that address?” |
| All | Both | Investigations, short periods |
| Off | Nothing | Not recommended in production |
Metrics are the fuel gauge on a dashboard, always showing the level. Logs are the trip diary, noting every stop. You glance at the gauge all the time, and open the diary when something odd has happened.
The audit question
A frequent security question is: “An outside company says our address 203.0.113.7 attacked them at ten past three. Which machine was it?” Because many machines share one address, the address alone cannot answer. Translation logs record the private source, the NAT address and the port at that time, letting you trace the traffic back. If you might ever need to answer such questions, keep translation logs for the period your policy requires.
Alerts worth having
Port usage above a threshold
Alert when a machine uses most of its ports for several minutes, so you can raise limits before connections fail.
Any out-of-resources drops
This means customers or jobs are already failing, so treat it as an incident.
Unusual traffic volume
A sudden jump in outbound bytes can mean a runaway job, or data being stolen.
Configuration changes
Alert on edits to the gateway, because a small change can cut off many machines.
VPC Flow Logs record traffic between machines and destinations at the network level. Used with NAT logs, they give you the full picture of who talked to whom, before and after translation.
OTroubleshooting Like a Detective
When a private machine cannot reach the internet, work through the possible causes in a sensible order.
Most NAT problems fall into two families. In the first, traffic never reaches the gateway: the machine has no route, the subnet is not covered, a firewall blocks it or a custom route diverts it. In the second, traffic reaches the gateway but cannot get a port: the machine has exhausted its slice, or the whole pool is full. Knowing which family you are in halves the search.
| Symptom | Likely cause | First thing to check |
|---|---|---|
| No outbound access at all from a new machine | Gateway missing or range not covered | Is there a gateway in this region and network, and does it cover this subnet range? |
| Nodes reach the internet but pods do not | Secondary ranges not covered | Gateway subnet range selection |
| Works most of the time, fails in bursts | Port exhaustion | Port usage metric and drop logs |
| Long-lived connections break after quiet periods | Idle timeout | Timeout settings and application keepalives |
| Partner rejects requests | Source address not allowlisted or changed | Automatic versus manual addresses |
| Traffic bypasses the gateway | Machine has external IP or custom default route | Interface settings and route table |
| Serverless service shows changing source addresses | Not routing all egress through the VPC | Egress setting of the service |
A calm step-by-step method
Confirm the machine truly has no external IP
If it has one, NAT is not involved and the problem lies elsewhere.
Check the gateway exists for this region and network
Compare the machine’s region and network with the gateway’s.
Check the subnet range selection
Make sure the exact range used by the machine or the pod is included.
Check routes and firewall rules
Look for a custom default route, and for outbound deny rules.
Look at drops and port metrics
If drops show out-of-resources, move to capacity tuning rather than configuration fixes.
Test from the destination’s point of view
Ask the partner which source address they received, and compare it with your NAT addresses.
It is like finding why a letter never arrived. First check it left the building (route and coverage). Then check the post office stamped it (translation). Then check the recipient did not refuse it (firewall and allowlist). Skipping ahead wastes time.
Worked example: the Monday morning failures
Every Monday at nine, a company’s reporting jobs start, and about a fifth of them fail with “connection timed out”. The rest of the week is quiet. The team sees out-of-resources drops in the logs, precisely at nine. Each job opens hundreds of parallel connections to the same data provider, and a hundred jobs start together. The static slice per machine is too small for that burst, and the provider’s single address concentrates all the connections on the same destination. The fix is a combination: turn on dynamic port allocation with a higher maximum, add two more NAT addresses, and limit each job’s parallelism. The Monday failures disappear, and the port usage alert now warns them long before trouble if the pattern grows.
Resist the urge to change many settings at once. Change one, observe, and record the result. Otherwise you will not know which change helped, and you may introduce a second problem.
PPerformance and Capacity Planning
Because Cloud NAT is not a machine, performance questions are about ports and fairness, not about processors.
Throughput, the amount of data per second, is generally not limited by Cloud NAT in the way a NAT machine would limit it, since translation is distributed. The limits that matter are the per-machine network limits and the port supply. So capacity planning is mainly a port planning exercise.
A simple planning recipe
List your machines and their peaks
For each group of machines, estimate the highest number of simultaneous outbound connections they will open.
Group by destination
Note which destinations receive the most connections, because those are the bottleneck cases.
Choose minimum and maximum ports
Set the minimum for a typical machine and the maximum for your busiest, with dynamic allocation on.
Compute addresses needed
Multiply machines by ports each, divide by usable ports per address, and add safety margin.
Test with a burst
Run a load test that mimics your worst moment, and watch the metrics.
Worked arithmetic
Suppose two hundred machines, each guaranteed one hundred twenty-eight ports. That is twenty-five thousand six hundred ports in total. One address offers about sixty-four thousand, so one address would cover the guarantees. But if a dozen busy machines may grow to four thousand ports each, add forty-eight thousand. The total demand is now near seventy-four thousand, which needs at least two addresses, and three gives comfortable margin. Always round up and keep headroom.
Fairness and noisy neighbours
One machine with a bug that opens endless connections can consume its whole allowance, and with dynamic allocation can grow to its maximum. That is why the maximum should not be set unreasonably high: a runaway process then has limited reach. The maximum is both a convenience for busy machines and a safety fence for the pool.
Reducing port demand
Connection pooling
Reuse a small number of long-lived connections instead of opening a new one per request.
HTTP keep-alive
Let one connection carry many requests, saving ports and time.
Private Google Access
Send Google API traffic around NAT entirely.
Local mirrors and caches
Serve package downloads from an internal mirror rather than fetching them from the internet on every build.
Reducing demand through pooling and reuse is almost always cheaper and more reliable than buying more addresses.
QUnderstanding Cost
NAT is cheap to start and surprisingly easy to overspend on at scale. Know what you are charged for.
Exact prices change, so always read the current pricing page. The shape of the bill, however, is stable. Typically you are charged for the gateway’s existence (often scaled by the number of machines using it), for the volume of data processed through it, and for any static external addresses you reserve. Standard internet egress charges also apply on top, because data leaving Google to the internet costs money no matter how it gets there.
Gateway and machine charges
A recurring cost tied to the number of machines served, so large fleets pay more.
Data processing
A per-gigabyte fee on traffic translated, which grows with downloads and uploads.
Static addresses
Reserved addresses may be charged, particularly when they are not attached to anything.
Internet egress
Normal outbound network charges apply separately and often dominate.
Think of a toll bridge with three charges: a yearly pass for using the bridge, a small fee for every kilogram of cargo, and a separate road tax for the highway beyond. The bridge is not expensive, but a company hauling heavy cargo all day pays a lot in total.
Common sources of surprise bills
Google API traffic through NAT
Large transfers to storage or analytics services that should have used Private Google Access.
Container images pulled repeatedly
Large images downloaded from outside registries on every node start, multiplied by autoscaling.
Verbose translation logging
Logging every translation on a busy gateway produces huge log volumes with their own cost.
Cross-region traffic
Machines in one region using a gateway path that crosses regions, adding more charges.
Ways to keep the bill sensible
Enable Private Google Access wherever Google services are used. Mirror container images and packages in a registry inside Google Cloud. Log errors always, and translations only when needed. Release static addresses that are no longer used. Review the billing breakdown monthly, and tie it to labels or projects so that a team can see its own share.
Prices and billing rules change over time. Use Google’s pricing calculator with your real numbers before committing to a budget.
A small cost experiment
To see where your money goes, run a simple experiment in a test project. Start a few private machines behind a gateway, and download a large file from the internet to one machine and a similar large file from a storage bucket to another. Then look at the billing breakdown and the NAT metrics a day later. You will see the first download counted as translated data, while the second, if Private Google Access is on, never touches the gateway. Repeat the test with a different region for the bucket and note how cross-region movement adds its own charge. A single afternoon of this kind of testing teaches more about NAT billing than hours of reading price tables, and it gives you real numbers to put in front of finance teams.
Questions finance teams ask
What will it cost next quarter?
Multiply expected machine counts and data volumes by current prices, then add a margin for growth and for unexpected retries.
Which team is responsible?
Use separate projects or labels so each team sees only its own traffic and its own share of the bill.
What could we stop paying for?
Unused reserved addresses, forgotten test gateways and Google traffic that still travels through NAT.
How do we avoid shocks?
Set budget alerts on the project, so a runaway job triggers a message within hours, not at month end.
RAdvantages, Disadvantages and Trade-offs
An honest look at what you gain and what you accept when you choose Cloud NAT.
Advantages
- Fully managed, with no NAT machines to patch or restart
- Built-in high availability within a region
- Scales with traffic without a single choke point
- Keeps back-end machines free of public addresses
- Provides a small set of known outbound addresses
- Simple configuration and good logging
- Works for virtual machines, GKE nodes and VPC-connected serverless
Disadvantages
- Outbound only, so it cannot publish services
- Shared ports can run out under heavy or bursty load
- No filtering of destinations or content by itself
- Regional, so each region needs its own gateway
- Costs grow with data volume and fleet size
- Idle timeouts can silently break quiet connections
- Bypassed by custom default routes and external IPs
Trade-offs to weigh consciously
| Decision | Option one | Option two |
|---|---|---|
| Address mode | Automatic: easy growth, changing addresses | Manual: stable allowlisting, you manage capacity |
| Port allocation | Static: predictable | Dynamic: efficient, needs sensible maximums |
| Coverage | All ranges: convenient | Custom ranges: tighter security, more upkeep |
| Logging | Errors only: cheap | Translations too: auditable, costly |
| Timeouts | Short: frees ports | Long: protects quiet connections |
Choosing a NAT setup is like choosing how a company shares its phone lines. Equal fixed lines for everyone are fair and simple, but waste capacity. Flexible lines use capacity well but need rules so one person cannot hog them. Neither is perfect, so you choose based on your office.
SAlternatives and When Not to Use Cloud NAT
Cloud NAT is one of several ways for machines to reach the internet. The right choice depends on what you need besides reachability.
flowchart TD
Q["Private workload needs outbound access"] --> A{"Only Google APIs?"}
A -- "Yes" --> PGA["Use Private Google Access"]
A -- "No" --> B{"Need to inspect or restrict websites?"}
B -- "Yes" --> SWP["Use Secure Web Proxy plus NAT"]
B -- "No" --> C{"Need fixed source IPs?"}
C -- "Yes" --> NATM["Cloud NAT with manual static IPs"]
C -- "No" --> NATA["Cloud NAT with automatic IPs"]
Q --> D{"Need advanced filtering or custom appliance?"}
D -- "Yes" --> NVA["Network virtual appliance or firewall"]
The alternatives explained
External IPs on machines
Simplest, but exposes machines directly and uses many public addresses. Fine for a few test machines, rarely for production back ends.
Secure Web Proxy
Lets you allow only chosen websites and inspect web traffic. Often used together with NAT rather than instead of it.
Self-managed NAT machine or firewall
Offers deep inspection and custom features, but you must operate it and build high availability yourself.
Private Google Access
Perfect when workloads only talk to Google services.
Load balancers
For traffic coming in from the internet. NAT cannot do this.
Private connectivity to partners
When a partner offers a private connection, traffic need not cross the public internet at all.
When not to use Cloud NAT
Do not use it when you need inbound connections to private machines. Do not rely on it alone when regulations demand inspection or filtering of outbound content. Do not use it for Google API traffic that Private Google Access can carry. And do not assume it will cover machines that have their own external addresses or traffic that custom routes divert elsewhere.
In mature designs, these tools are layered: Private Google Access for Google services, a proxy or firewall for control, and Cloud NAT as the final translator for approved traffic.
Choosing between alternatives: a short story
Two teams in the same company faced similar needs. The first team ran a handful of internal tools that fetched updates once a day. They chose plain Cloud NAT with automatic addresses, and never thought about it again. The second team ran a payment service that called three banks, each with its own allowlist. They chose Cloud NAT with manual static addresses, added a secure web proxy for every other website, and wrote firewall rules that named each bank’s address range. Both teams were right. The first valued simplicity because the risk was small. The second valued control because the risk was large. The skill is not memorising one best answer, but matching the amount of protection to the amount of danger and the cost of mistakes.
When you are unsure, begin with the simplest design that meets your security rules, add monitoring, and tighten it as you learn what your traffic really looks like. It is much easier to add a layer later than to remove a complicated one that nobody understands.
TDesign Patterns
Proven ways to arrange Cloud NAT in real systems.
Regional gateways per environment
Create one gateway per region and per environment, such as production and testing, each in its own network. This isolates failures and lets you set different capacity and logging for each. A mistake in the test gateway then cannot disturb production.
Static addresses for partner traffic
Use manual addresses whenever a partner allowlists you. Reserve a pool with room to grow, label the addresses with their purpose, and document who was told about them.
Egress control in front of NAT
Place firewall rules and a web proxy ahead of the gateway, so that NAT only translates traffic that has already been approved. NAT handles address sharing, other layers handle policy.
Separate gateways by workload class
Use different gateways, or different subnet coverage, for workloads with very different traffic. A heavy batch system with bursty connections should not compete for ports with a customer-facing service.
Internal mirrors for packages and images
Host copies of frequently used packages and container images inside your own cloud registry. Builds and node starts then avoid the internet entirely, saving ports, time and cost, and they keep working when an outside site is down.
These patterns are like good office habits: separate phone systems for separate departments, a reception desk that screens visitors before the switchboard, and a company library so that nobody has to keep calling the public library for the same book.
UAnti-patterns to Avoid
Mistakes seen again and again in real projects. Learn them cheaply here, rather than in an outage.
Treating NAT as a firewall
Believing that private machines are safe because they sit behind NAT, and skipping egress rules, logging and least privilege. A compromised machine can still send data anywhere.
Automatic addresses with partner allowlists
Giving a partner today’s automatically allocated addresses. When the pool changes, calls fail and nobody knows why. Use manual static addresses.
Sizing for the average
Planning ports for typical traffic and ignoring bursts, autoscaling and scheduled batch peaks. Failures then appear exactly when the business is busiest.
Sending Google traffic through NAT
Skipping Private Google Access, so that large storage and analytics transfers consume ports and money for no reason.
No monitoring until it breaks
Leaving logging off and defining no alerts, then trying to diagnose port exhaustion with no evidence.
Unlimited maximum ports
Setting very large per-machine maximums “to be safe”, which lets one runaway process drain the pool for everyone.
Forgetting a region or a range
Deploying machines or clusters into a new region or secondary range without a gateway or coverage, then spending hours debugging “no internet”.
Nearly every anti-pattern comes from assuming NAT is magic and unlimited. It is a shared, finite resource that needs planning, watching and layering with other controls.
VBest Practices and Common Mistakes
A checklist of habits that keep Cloud NAT boring, which is exactly what you want from network plumbing.
Design practices
Size ports before launch
Do the arithmetic for peak machines and busiest destinations, then add generous margin.
Prefer dynamic allocation
It shares a limited supply fairly and rescues busy machines, with a sensible maximum as a fence.
Use manual addresses where identity matters
Partners and compliance teams need addresses that never change unexpectedly.
Enable Private Google Access
Take Google service traffic off the NAT path from day one.
Cover only what needs covering
Narrow subnet selection reduces both risk and surprise.
One gateway per region you use
Remember that coverage is regional, and add a gateway wherever private machines will live.
Operational practices
Turn on error logging from the start
It is cheap, and it is the first evidence you will want during an incident.
Alert on port usage and drops
Be warned at seventy or eighty percent use, not at one hundred.
Manage configuration as code
Describe gateways in an infrastructure tool, review changes like any other change, and avoid hand edits in the console.
Document addresses and owners
Record which static addresses were shared with which partners, and who to ask before changing them.
Set application keepalives
Keep them shorter than NAT idle timeouts so quiet connections survive.
Rehearse failure
Run a burst test in a non-production network to see what exhaustion looks like before your customers do.
Common mistakes, restated as questions
| Ask yourself | Why it matters |
|---|---|
| Does any machine have an external IP by accident? | It would bypass the gateway and its protections. |
| Are secondary ranges included for my clusters? | Otherwise pods will not reach the internet. |
| Did I check for custom default routes? | They divert traffic away from NAT. |
| Do I know my busiest destination? | Port limits are counted per destination. |
| Who was told our outbound addresses? | Changing them blindly breaks partners. |
| Is outbound traffic filtered anywhere? | NAT alone does not stop data theft. |
Review NAT metrics together with your regular capacity review. A ten-minute glance each month catches slow growth long before it becomes an outage.
WReal-World and Industry Examples
Concrete stories show how the ideas fit together. The companies below are imaginary, but their situations are very common.
Online retail: private back ends, one clean outbound identity
An online shop runs its order, inventory and recommendation services on private machines. They contact a payment provider, a delivery-tracking service and an email sender. The payment provider requires fixed source addresses. The team deploys manual NAT addresses in each region, shares them once, and relies on Private Google Access for storage and analytics. During a holiday sale, traffic triples. Because they sized the pool for peak, with dynamic allocation and monitoring, checkout stays smooth.
Banking and finance: control over every outbound path
A fintech firm must prove where data can go. Its machines have no external addresses. All web traffic passes through a secure web proxy that permits only approved sites. Remaining traffic is allowed by narrow firewall rules and translated by Cloud NAT using static addresses. Translation logs are kept for the retention period required by regulation, so any outside query about a source address can be traced to a single machine and time.
Data analytics: heavy downloads and a hidden bill
A research group runs thousands of short batch jobs that download public datasets, then store results in cloud storage. At first all traffic used NAT, and the monthly bill alarmed them. After enabling Private Google Access, storage traffic bypassed NAT. They also cached the public datasets inside a bucket in the same region. Cost fell sharply, and the port exhaustion that plagued their start-of-day rush disappeared.
Software company: private build farm
A software company builds products on private build machines. Each build pulls hundreds of packages. When all developers push code before lunch, the build farm hits port limits and builds time out. The team sets up an internal package mirror and a registry. Builds fetch from inside the cloud network, which is faster, cheaper and immune to outside outages.
Healthcare: private by default
A clinic software provider keeps patient systems on private networks with no public addresses. The only outbound needs are software updates and a lab-results partner. Cloud NAT covers just the one subnet that needs updates, a separate narrow rule allows the lab partner, and everything else is denied. Auditors find the design easy to explain, because the allowed paths are few and written down.
All five stories follow the same recipe, much like a good kitchen. Prepare ingredients locally to avoid trips to the shop (mirrors and caches), use the staff corridor for the warehouse next door (Private Google Access), and send only approved orders out through one well-watched front door (Cloud NAT).
What the stories share
Each team knew its busiest destinations, planned ports for peaks, took avoidable traffic off the NAT path, and watched the metrics. None of them treated NAT as a security product. They added layers for policy, and used NAT for the one thing it does well: letting private machines talk outwards through shared, stable addresses.
XSetting Up, Migrating and Keeping Current
A calm approach to introducing Cloud NAT, and to keeping your knowledge fresh as the product evolves.
A safe rollout plan
Inventory what needs outbound access
List private workloads, their destinations and their peak connection counts.
Choose scope and addresses
Decide coverage, manual or automatic addresses, and port settings from your planning arithmetic.
Create the router and gateway in a test network
Use the same settings you plan for production and run realistic traffic through them.
Turn on logging and alerts
Have dashboards ready before real traffic arrives.
Roll out region by region
Start with a low-risk region, watch for a few days, and then proceed.
Remove external IPs last
Only after the gateway is proven should you strip public addresses from machines, one group at a time.
Migrating from self-managed NAT machines
If you currently run your own NAT machines, plan the move carefully. Reserve the same external addresses for the new gateway if partners have allowlisted them, which may require releasing them from the old machines at the right moment. Run both paths side by side where possible, using route priorities to switch traffic, and keep the old route ready for quick rollback. Watch for applications that relied on features of your old machine, such as custom filtering, which Cloud NAT does not provide.
Switching outbound paths changes your visible source address for a moment. Warn partners and schedule the change in a quiet period, so any hiccup is small.
Keeping up with changes
Cloud services evolve quickly. Names of features, default values, limits and prices can change, and new options, such as additional private NAT capabilities, can appear. Treat this guide as a map of ideas, and treat Google’s official documentation and release notes as the source of truth for numbers. A short list of things to confirm before any production decision is below.
Port and address limits
Usable ports per address, maximum addresses per gateway, and per-machine limits.
Default timeouts
Defaults and allowed ranges for each protocol state.
Pricing
Gateway, data processing, address and egress charges for your regions.
Serverless connection methods
Current ways to route Cloud Run, Functions or App Engine egress through your VPC.
Private NAT availability
Supported scenarios and prerequisites for private NAT.
IPv6 behaviour
How IPv6 traffic is handled for your design.
YFrequently Asked Questions
Short, direct answers to the questions people ask most often.
No. It is a managed, software-defined feature of Google’s network. There is no machine to patch, resize or restart. You only configure the gateway settings.
No. It supports outbound connections and their replies only. To receive inbound traffic from the internet, use a load balancer or another inbound path.
Most likely the gateway covers only primary subnet ranges, while pods use a secondary range. Include the secondary range, or review how the cluster handles pod traffic.
A machine needed a new port for an outbound connection, but none was available within its allowance or the pool. Raise limits, add addresses, enable dynamic allocation or reduce connection churn.
Usually not. Private Google Access lets machines without external addresses reach Google services directly. Use NAT for the rest of the internet.
Reserve static external addresses, attach them to the gateway in manual mode, and share them with the partner. Make sure the traffic really goes through the gateway.
No. A gateway serves a single region of a single network. Create one per region where you have private machines.
Rarely in a noticeable way, because translation happens in the host network without an extra hop. The more common issue is port supply, not speed.
The mapping probably expired after being idle longer than the NAT timeout. Add application keepalives that fire more often than the timeout, or adjust the timeout if appropriate.
No. It does not filter destinations or content. Combine it with egress firewall rules, a web proxy, DNS controls, least privilege and monitoring.
Enable translation logging. The logs record the private source, the NAT address and the port at the time, so you can trace the traffic back.
Public NAT translates private addresses to public ones for the internet. Private NAT translates between private ranges, often to connect networks with overlapping addresses.
It is probably not routing all outbound traffic through the VPC. Connect it to the network and set it to send all egress through the VPC so the gateway can translate it.
Choose automatic when nobody depends on your outbound addresses and you want easy growth. Choose manual whenever allowlists or audits require addresses that do not change.
Enable Private Google Access, mirror packages and images internally, log errors rather than everything, release unused addresses and review the billing breakdown regularly.
ZSummary and Key Takeaways
Let us gather the story in one place.
Cloud NAT is Google Cloud’s managed switchboard for outbound traffic. It lets machines with only private addresses start conversations with the internet, by swapping their private addresses and ports for shared public ones and swapping them back for the replies. It runs inside Google’s network, is configured per region and network through a Cloud Router, and needs no machines of your own. Its power is simplicity and scale. Its limits are the finite supply of ports, the lack of any filtering and the fact that it is outbound only.
The ideas that matter most are few. Ports are shared, counted per destination, and can run out. Dynamic allocation, enough addresses and fewer, longer-lived connections keep them healthy. Static addresses give partners something stable to trust. Private Google Access removes Google traffic from the NAT path. Security comes from layers around NAT, not from NAT itself. And monitoring turns surprises into early warnings.
Key Takeaways
- Cloud NAT is a managed, outbound-only, software-defined translator: private machines can reach out, but strangers cannot reach in.
- A gateway serves one region of one network, and covers only the subnet ranges you select, so check regions, secondary ranges and custom routes first when “there is no internet”.
- Ports are the scarce resource: they are shared per NAT address and counted per destination, so size for peaks and use dynamic allocation with a sensible maximum.
- Use manual static addresses whenever partners allowlist you, and keep Google API traffic off NAT with Private Google Access.
- NAT is not a firewall: add egress rules, a web proxy, DNS controls and least privilege to prevent data exfiltration.
- Watch port usage and drops, log errors from day one, and use translation logs when you must trace a shared address back to one machine.
- Verify limits, timeouts, pricing and serverless connection methods against Google’s current documentation before production decisions.