Cloud NAT lets resources that have only private addresses start connections to the outside world, while keeping the outside world from starting connections to them.

The problem: private machines still need to reach out

Good security practice says most servers should not have a public internet address. A machine without a public address cannot be reached directly from the internet, which removes a huge category of attacks. But those same machines still have errands to run. They download operating system updates, call payment providers, fetch software packages, talk to third-party APIs, and send data to partner companies. Without a public address, none of these outbound requests can leave the network, because nobody on the internet knows how to send the answer back to a private address.

The traditional fix is to give every machine a public address, which brings back the exposure you wanted to avoid. The better fix is Network Address Translation, usually shortened to NAT. A NAT service rewrites the sender address on outgoing packets to a shared public address, remembers who asked, and delivers the answers back to the right private machine.

What Cloud NAT is, in one paragraph

Cloud NAT is Google Cloud’s managed network address translation service. According to Google’s documentation, it provides translation for outbound traffic to the internet, to other VPC networks, to on-premises networks, and to other cloud providers’ networks. It works for Compute Engine virtual machines, Google Kubernetes Engine clusters, Cloud Run, Cloud Run functions, App Engine standard instances, and regional internet network endpoint groups. You create a Cloud NAT gateway in a region, tell it which subnets it should serve, and the translation starts applying automatically to matching resources.

A key idea: it is not a virtual machine

Many beginners picture Cloud NAT as a special server sitting in the middle, like a router appliance that traffic must squeeze through. It is not. Google describes it as a distributed, software-defined managed service that does not depend on proxy virtual machines or a single physical gateway. It programs Google’s Andromeda network virtualization software, so the translation happens at the edge of each virtual machine’s own network path. There is no central box to size, patch, or crash, and it does not reduce the network bandwidth available to each machine.

Where Cloud NAT fits among Google Cloud networking tools

Google Cloud offers several networking building blocks, and beginners often confuse them because they all move packets. A load balancer receives traffic that outsiders send toward your services and spreads it across healthy backends. A firewall rule decides whether a packet is allowed to pass at all. A Cloud VPN or Cloud Interconnect link connects your cloud network to another network, such as an office or a data center. Cloud DNS turns names into addresses. Cloud NAT does one narrow job: it changes the sender address of outbound traffic so private resources can start conversations without owning public addresses.

Seeing these tools as a team makes design easier. For a typical web application, the load balancer handles visitors coming in, the firewall limits what is allowed, Cloud DNS provides names, and Cloud NAT lets servers call out. Each tool can be changed on its own without breaking the others, as long as you understand which direction of traffic each one owns.

A few small ideas about addresses and ports explain nearly everything about Cloud NAT.

Networking vocabulary can feel like alphabet soup, so let us build it slowly. Each term below appears again and again in Cloud NAT documents, and once you understand them the rest becomes natural.

Addresses and ports work as a pair

A connection is identified by more than just an address. It is identified by the source address, source port, destination address, destination port, and protocol, together called the connection tuple. When your virtual machine opens a connection to a website, it picks a random source port for that conversation. If a hundred machines share one public address, the NAT service must keep their conversations apart. It does this by giving each conversation its own public address and port combination and remembering the mapping.

Why ports are a limited resource

There are only about 64,000 usable ports on a single address, and ports below 1024 are reserved. Every active outbound conversation uses one of them. That limit is the root of the most common Cloud NAT problem, port exhaustion, which later chapters cover in depth. If you remember only one idea from this chapter, remember that Cloud NAT shares a limited pool of address and port pairs among many machines.

Inbound and outbound are different worlds

Most NAT confusion comes from mixing up direction. An outbound connection starts inside your network and goes out, such as a server downloading a file. An inbound connection starts outside and comes in, such as a visitor opening your website. Cloud NAT is built for the first kind. For the second kind, a different product receives the traffic first. Keeping this direction clear in your head, and in your diagrams, prevents a whole class of design errors and wasted troubleshooting.

Cloud NAT comes in two flavors, one for reaching the internet and one for reaching other private networks.

Public NAT: private machines reaching the internet

Public NAT lets resources that have no external IPv4 address reach IPv4 destinations on the internet. It uses a set of shared external IP addresses, and it allocates external addresses and source ports to each virtual machine that uses the gateway. This is the version most people mean when they say Cloud NAT. It is how a locked-down application server downloads a software package or calls a payment provider.

Google’s documentation points out one subtle exception. Traffic to Google APIs and services travels through Private Google Access, even when Public NAT exists. Those requests do not consume your NAT addresses and ports, because Google’s own services are reachable over Google’s internal network.

Private NAT: private to private translation

Private NAT solves a different problem. Sometimes two private networks need to talk, but their address ranges overlap, which is like two cities that both have a “Main Street 10”. Private NAT translates the source addresses into unique ones taken from a dedicated Private NAT subnet range, so the two sides can communicate without renumbering either network. According to the documentation, Private NAT supports translation toward other VPC networks attached to a Network Connectivity Center hub, translation for IPv6 traffic within the same VPC network (known as NAT64), and translation toward on-premises or other cloud networks through hybrid spokes, Cloud Interconnect, or Cloud VPN, often called Hybrid NAT.

flowchart LR
  VM1["VM with private IP only"] --> PUB["Public NAT gateway"]
  PUB --> NET["Internet destinations"]
  VM2["VM in VPC A"] --> PRIV["Private NAT gateway"]
  PRIV --> OVER["Network with overlapping ranges, on-premises or another VPC"]
        

Read the diagram as two separate roads. The top road carries outbound internet traffic through a Public NAT gateway. The bottom road carries traffic to other private networks through a Private NAT gateway. A single gateway is one type or the other, but two gateways, one of each type, can serve the same subnet.

IPv6 and NAT64

Much of the internet still speaks IPv4, while new networks increasingly use IPv6. Google’s release notes show that IPv6-to-IPv4 translation, called NAT64, became generally available for Public NAT in August 2025, and for Private NAT in October 2026. This lets IPv6-only workloads reach IPv4-only destinations through the gateway. If your organization is moving toward IPv6, it is worth knowing this bridge exists.

Choosing between the two

A simple question decides most cases: where is the destination? If the destination is a public service on the internet, such as a software repository, a payment provider, or a public API, you want Public NAT. If the destination is another private network, such as an on-premises data center, another company’s network, or another VPC network connected through Network Connectivity Center, you want Private NAT, especially when address ranges overlap. If both kinds of destinations exist, you can run one gateway of each type on the same subnet.

Do not choose Private NAT just because your destination sits on a private address. If ranges do not overlap and routing already works, plain routing needs no translation at all. Translation adds a mapping to manage and a layer to debug, so use it only when it solves a real problem such as overlapping ranges, controlled address exposure, or an IPv6-to-IPv4 bridge.

A gateway lives on a Cloud Router, applies to chosen subnets in one region, and uses a pool of addresses.

The pieces and how they connect

Start with your VPC network, which contains regional subnets. In a given region you create a Cloud Router, a managed control-plane service that stores configuration. On that router you create a NAT gateway. The gateway lists which subnets, or which address ranges inside them, it should translate. It also lists where its public addresses come from: either addresses that Google allocates automatically, or addresses you reserve yourself.

flowchart TD
  VPC["VPC network"] --> SUB["Regional subnet"]
  SUB --> VM["VMs, GKE nodes, serverless egress"]
  CR["Cloud Router in the same region"] --> GW["Cloud NAT gateway"]
  GW --> IPS["External IP pool, automatic or manual"]
  VM -->|"Outbound packets"| GW
  GW -->|"Translated packets"| NET["Internet"]
        

Notice that the Cloud Router is not in the data path. It only carries the configuration. The real translation is performed by Google’s Andromeda software, which Google says is configured to perform source NAT for outgoing traffic and destination NAT for established inbound responses. This is why Cloud NAT scales without you adding machines.

Regional by design

A Cloud NAT gateway is created in the region of the subnets that need NAT. If your application runs in two regions, you need a gateway in each. This regional design matches the way Google Cloud networks are built, and it keeps traffic from needing to travel across regions just to be translated.

What the gateway applies to

You do not attach NAT to individual machines. You choose subnets or ranges, and any matching resource without its own external address is covered. Because of that, a machine added later by autoscaling is covered automatically. Google notes that Cloud NAT supports managed instance groups, including autoscaling groups, with no extra steps.

What Cloud NAT needs from the rest of the network

A gateway cannot work alone. It needs a Cloud Router in the right region and network, subnets that contain the workloads, a route toward the internet gateway for public traffic, and firewall rules that allow the outbound connections. It also needs external addresses, either supplied automatically or reserved by you. When all of these line up, translation is invisible. When one is missing, the symptom is usually a timeout, which is why walking through each requirement is such a reliable debugging habit.

Every outbound conversation gets an entry in a mapping table that links a private address and port to a public address and port.

The translation, step by step

When a virtual machine sends a packet to an internet destination, the packet leaves with the machine’s private address as its sender. Cloud NAT notices that the packet matches a configured subnet, picks an external address and source port from those reserved for that machine, rewrites the sender fields, and forwards the packet. It records the mapping. When the destination replies, the reply arrives at the public address and port, Cloud NAT finds the mapping, rewrites the destination back to the private address and port, and delivers the packet to the original machine.

sequenceDiagram
  participant VM as VM private IP
  participant NAT as Cloud NAT
  participant WEB as Internet server
  VM->>NAT: Request from private IP and port
  NAT->>NAT: Pick public IP and port, record mapping
  NAT->>WEB: Request from public IP and port
  WEB-->>NAT: Reply to public IP and port
  NAT->>NAT: Look up mapping
  NAT-->>VM: Reply to private IP and port
        

Why unsolicited inbound traffic is dropped

Google states that Cloud NAT supports address translation for established inbound response packets only. If a stranger on the internet sends a packet to your NAT address, there is no mapping for it, so there is nothing to translate and nowhere to deliver it. The packet is simply dropped. This is what keeps NAT-only machines unreachable from outside. If you want to receive inbound connections, you need a different tool, such as a load balancer.

Ports are assigned to each machine

Cloud NAT does not let every machine grab ports from one big shared pool at random. It reserves blocks of ports for each machine that uses the gateway. This gives each machine a predictable share and prevents one noisy machine from silently taking everything. The number of ports reserved per machine is a setting you can tune, and getting it right is one of the most important Cloud NAT skills. The next chapters explain how.

Reusing ports for different destinations

A port is not permanently consumed by one connection. The same public address and port pair can be used for connections to different destinations, because the full connection tuple, which includes the destination, remains unique. This reuse is the reason a machine can hold far more active connections than it has reserved ports, as long as they go to many different destinations. It is also why connecting thousands of times to one single destination address and port is the most demanding pattern for NAT.

What a mapping actually contains

Each entry in the translation table records the private source address and port, the public address and port chosen for it, the destination address and port, and the protocol. The protocol matters because TCP, UDP, and ICMP behave differently. TCP connections have a clear beginning and end, so the gateway can watch them open and close. UDP has no such lifecycle, so the gateway relies on idle timers to know when a conversation is over. ICMP, used by tools such as ping, also relies on timers and is supported by Public NAT.

Because the mapping includes the destination, two different conversations from the same machine can share a public address and port as long as they go to different destinations. When people say a machine “used up its ports”, they usually mean it used up distinct combinations toward one particular destination, not that it spoke to the internet too much overall.

It helps to know which traffic passes through the gateway, which traffic skips it, and how a gateway lives from creation to retirement.

Which traffic uses Cloud NAT

flowchart TD
  S["Packet leaves a VM"] --> Q1{"VM has its own external IP?"}
  Q1 -- "Yes" --> D1["Uses its own external IP, no NAT ports used"]
  Q1 -- "No" --> Q2{"Destination is a Google API?"}
  Q2 -- "Yes" --> D2["Private Google Access path, no NAT ports used"]
  Q2 -- "No" --> Q3{"Subnet covered by a NAT gateway?"}
  Q3 -- "Yes" --> D3["Source NAT applied, packet leaves"]
  Q3 -- "No" --> D4["No route out, connection fails"]
        

This flow explains several support tickets before they happen. If a private machine cannot reach a website, the cause is often that no gateway covers its subnet. If a machine has an external address and you expected NAT logs, the logs will be empty because it never used NAT. Remember also that firewall rules apply to the traffic before translation, so an egress rule that blocks the destination will stop the packet even when NAT is perfect.

The life of a gateway

Routes still matter

Cloud NAT does not replace routing. For internet-bound traffic from a private machine to leave the network, the VPC needs a route that points toward the default internet gateway, which is normally provided by the default route that new networks receive. If someone deletes that route, or replaces it with a custom route that sends everything to an appliance, traffic may never reach the NAT gateway. This surprises teams who remove the default route as part of a security hardening project and then wonder why NAT stopped working.

The lesson is that NAT is one stage in a chain. A packet must first be allowed by egress firewall rules, then matched to a route, and only then translated. When troubleshooting, walk the chain in order instead of looking only at the NAT page.

The public addresses your gateway uses decide what the outside world sees, so this choice affects partners, allowlists, and scaling.

Automatic allocation

In automatic mode, Google Cloud assigns and manages the external addresses for the gateway. Google’s documentation says Cloud NAT can automatically scale the number of NAT addresses it uses as more machines or more connections need them. This is the easiest option. You do not reserve anything, you do not watch for running out of addresses, and the gateway grows with the workload. The cost of that convenience is that the addresses are not under your control and can change as the gateway scales.

Manual allocation

In manual mode, you reserve specific static external addresses and give them to the gateway. Google notes that with manual assignment you can share a fixed set of external addresses with a destination party that allows only known addresses. This is common when your application calls a bank, a government service, a partner company, or a software vendor that protects its endpoints with an allowlist, which is a list of approved source addresses.

How many addresses do you need?

Each address offers roughly 64,000 usable ports. If your machines need many simultaneous connections to the same destination, you will need more addresses to supply enough distinct address and port pairs. A useful rule of thumb is to estimate peak concurrent connections per destination, multiply by the number of machines, and compare the result with the ports your gateway can offer. Add comfortable headroom, because running out causes dropped connections rather than slow ones.

Naming and documenting your addresses

Reserved addresses should carry clear names that say what they are for and which environment they belong to. A name such as “prod-eu-nat-1” tells a future engineer far more than an auto-generated label. Keep a simple record of which partners have allowlisted which addresses and when. When someone later wants to release an address, the record shows immediately whether doing so would break a partner connection.

Ports are the currency of NAT. Running out of them is the most common production problem, and it is very preventable.

Static and dynamic port allocation

Cloud NAT can hand out ports to each machine in two ways. With static port allocation, every machine gets the same fixed number of ports, set by a minimum-ports-per-VM value. It is simple and predictable, but wasteful if some machines are busy and others are idle, because every machine holds its full share whether it uses it or not.

With dynamic port allocation, each machine starts with a smaller minimum and can receive more ports as its need grows, up to a maximum. Google’s tuning documentation states that the dynamic minimum must be a power of two between 32 and 32,768, and the maximum must be a power of two between 64 and 65,536, greater than the minimum, with 65,536 as the default maximum. This lets busy machines borrow capacity while quiet machines keep only a little.

Endpoint-independent mapping

Endpoint-independent mapping, often shortened to EIM, is a setting that changes how mappings are shared across destinations. Google’s documentation says it must be disabled before you can switch to dynamic port allocation. Some applications that depend on certain peer-to-peer or real-time behaviors want EIM, while most ordinary web workloads do not. Check what your applications really need before changing this setting.

What port exhaustion looks like

When a machine uses up all the ports assigned to it for a given destination, new connections to that destination cannot be created. Applications see failed connections, timeouts, or intermittent errors, often only at busy moments and often only toward one popular destination. Because other traffic keeps working, the problem is easy to misdiagnose as a flaky remote server.

flowchart TD
  A["Spike in outbound connections"] --> B{"Ports left for this VM and destination?"}
  B -- "Yes" --> C["New connection works"]
  B -- "No" --> D["Connection fails or is dropped"]
  D --> E["Application errors and retries"]
  E --> F["More connection attempts, worse shortage"]
        

Notice the last two boxes. Applications that retry aggressively can make the shortage worse, because each retry tries to open yet another connection. Good clients reuse connections and slow down their retries.

How to fix it

• Check the per-machine port usage metric over a representative period, such as the past thirty days, to find the true peak.
• With static allocation, raise the minimum ports per machine to your measured peak.
• With dynamic allocation, keep the minimum below the peak and the maximum above it.
• Reduce the demand itself: reuse connections with keep-alive and connection pools, and avoid opening a new connection for every small request.
• Add more external addresses when the total pool, not the per-machine share, is the limit.

A worked example of port math

Suppose a fleet of one hundred application servers sits behind a gateway. Each server needs about sixty-four simultaneous connections toward the busiest external service during normal hours, and about one thousand during the daily peak. With a static minimum of sixty-four, the fleet needs about six thousand four hundred ports in total, which fits easily within the roughly sixty-four thousand ports of a single address. At the peak, with one thousand per server, the same fleet needs one hundred thousand ports, which is more than one address can supply, so at least two addresses are required.

Now consider dynamic allocation with a low minimum and a high maximum. Servers start with a small share and grow only while they are busy. Because not every server peaks at the same moment, the total in use at any instant is lower than the sum of the individual maximums. The fleet may then get by with fewer addresses, but only if monitoring confirms the peaks really are staggered. Never assume. Measure the real usage across several busy periods before shrinking anything.

NAT remembers every mapping for a limited time, and those timers decide how quickly ports come back and how long idle connections survive.

Why timers exist

A NAT table cannot remember every connection forever, or ports would never be freed. Each kind of mapping has an idle timeout. When a connection stays silent for longer than its timeout, the mapping disappears and the port returns to the pool. A longer timeout keeps quiet connections alive but holds ports for longer. A shorter timeout frees ports faster but may cut off connections that are only pausing.

The timers and their defaults

Google’s release notes announced that the default TCP TIME_WAIT timeout is decreasing from 120 seconds to 30 seconds, and the tuning page says gateways created after September 30, 2026 use 30 seconds by default. Older gateways may still have 120, so check the effective value on your own gateway. The documentation also advises setting at least 15 seconds to avoid dropped packets, and says timers can vary by up to five seconds, so it suggests adding five seconds to the value you intend.

Long-lived idle connections

The twenty-minute established timeout surprises many teams. A database connection pool that sits idle overnight, or a long-polling client, may be silently cut after twenty minutes of silence. The next use then fails with a confusing reset error. The cure is either to raise the timeout, or better, to enable keep-alive messages in the application so the connection never looks idle.

Choosing timers with evidence

Timer changes should follow evidence, not hunches. If connections to a database fail after long quiet periods, confirm that the quiet time exceeds the established timeout, and prefer keep-alive messages from the application. If ports are scarce, look at whether many connections are sitting in a closing state and consider the transitory and TIME_WAIT timers. If UDP-based services such as DNS or real-time media lose mappings, consider the UDP idle timeout. Change one timer at a time, observe the effect for a full business cycle, and write down the result.

NAT rules let one gateway behave differently for different traffic, for example by using particular addresses for particular destinations.

Why rules exist

A default gateway treats all matching traffic the same way. Real organizations have more specific needs. One partner may require traffic to come from a particular address. A compliance team may want regulated workloads to use a separate set of addresses so they can be audited. A rule lets you say “when traffic matches this condition, use these addresses instead”. Without rules you would need to build separate networks or gateways for each special case.

Destination and source based rules

NAT rules traditionally match on the destination of the traffic. Google’s release notes also describe source-based NAT rules for IPv4. These became generally available for Public NAT in April 2026, after a preview that began in September 2025, and entered preview for Private NAT in September 2026. Source-based rules help when different workloads inside the same subnet should use different outbound addresses.

Testing rules safely

Because a rule changes which addresses outsiders see, a mistake can cut off a partner or leak traffic from an unexpected address. Test rules first in a non-production environment that mimics the real layout. Send test connections from workloads that should match, and from workloads that should not, and confirm that each uses the intended addresses. Then roll the rule out gradually, starting with a small, low-risk workload, and keep the old behavior ready to restore.

Cloud NAT serves virtual machines, containers, and several serverless products, each connecting in its own way.

flowchart LR
  VM["Compute Engine VMs"] --> NAT["Cloud NAT gateway"]
  GKE["GKE private nodes and pods"] --> NAT
  RUN["Cloud Run with Direct VPC egress"] --> NAT
  GAE["App Engine with Serverless VPC Access"] --> NAT
  NAT --> NET["Internet or private destinations"]
        

Special notes for container and serverless workloads

Containers and serverless platforms start and stop quickly, which makes their NAT usage spiky. A cluster that scales from ten to a hundred nodes in minutes can suddenly need many more ports and addresses. Plan for the largest scale the autoscaler allows, not today’s size. For serverless services, remember that every instance that starts may open fresh connections, so connection reuse inside each instance and sensible limits on concurrency help protect the shared pool.

Cloud NAT supports a secure design, but it is only one layer. Firewalls, identity, and egress controls do the real policing.

What NAT does for security

Cloud NAT helps security by making it possible to run machines without public addresses. Those machines cannot be reached directly from the internet, which shrinks the attack surface. Because Cloud NAT accepts only replies to connections that started inside, scanning the NAT address from outside finds nothing to attack on your private machines.

What NAT does not do

NAT does not inspect content, does not block malware, and does not stop a compromised machine from sending data out. If an attacker controls a private machine, NAT happily carries their outbound traffic to the internet like any other. That is why egress control matters just as much as ingress control.

Auditing who talked to whom

Because many machines share a few public addresses, the outside world cannot tell them apart. If a partner reports suspicious activity from your address, you need your own records to find the exact machine. NAT logs include the private source, the translated address and port, and the destination, which lets security teams trace an event back to one workload. Without logs, the shared address is a dead end.

Who owns the gateway?

In larger companies, a central network team often owns gateways and address pools, while application teams own the workloads that use them. This split works well when it is written down. The network team promises a stable set of outbound addresses and healthy capacity. Application teams promise to reuse connections, tell the network team about new destinations, and respond to port alerts. Without a clear agreement, each side assumes the other is watching, and a shortage is discovered only by customers.

A shared responsibility note should say who can change settings, who is paged for alerts, how partners are informed about address changes, and how long advance notice is needed. A one-page document like this prevents more outages than any technical tweak.

Good visibility turns a mysterious outage into a five-minute diagnosis.

Logs

Google says Cloud NAT logs can trace connections and bandwidth, which supports compliance, debugging, analytics, and accounting. Logging can usually be set to record only errors, only successful translations, or everything. Recording everything is the most informative but also the most voluminous, and it adds logging cost on busy gateways. Many teams record errors permanently and turn on full logging temporarily during investigations.

Metrics

Metrics flow automatically into Cloud Monitoring, so you can build dashboards and alerts without installing anything. The documentation also mentions that Network Analyzer publishes Cloud NAT insights, which can point out configuration problems. The metrics below deserve a place on every NAT dashboard.

A simple troubleshooting routine

Building a useful dashboard

A good NAT dashboard answers four questions at a glance. Are any machines close to their port limits? Are packets being dropped? Is traffic volume normal compared with the same hour last week? Which destinations receive the most connections? Put these four views on one page, label thresholds clearly, and link the page from the alert messages so the person on call lands in the right place immediately.

A handful of tried and tested layouts solve most NAT needs in the real world.

flowchart TD
  USER["Internet users"] --> LB["Load balancer"]
  LB --> APP["App servers in private subnet"]
  APP --> DB["Database in private subnet"]
  APP --> NAT["Cloud NAT gateway"]
  NAT --> EXT["External APIs and update servers"]
  APP --> PGA["Google APIs through Private Google Access"]
        

This layout separates the two directions of traffic cleanly. Inbound user requests use the load balancer. Outbound calls use Cloud NAT. Calls to Google services use Private Google Access. Each road has its own owner, and each can be monitored on its own.

Multi-region and shared-network designs

Many organizations run several regions for resilience or to be near customers. Each region needs its own Cloud Router and gateway, and each gateway has its own addresses. A partner that allowlists addresses must therefore receive the lists for every region you operate in. If a region fails and traffic moves to another, the partner will see a different set of source addresses, so plan allowlists for failover regions in advance rather than during an emergency.

In shared network designs, where many projects use one central network, it is usual for the central team to own the NAT configuration. This keeps outbound addresses consistent across all teams and makes auditing simpler. In designs with many separate networks, standardizing the gateway settings through infrastructure code keeps behavior consistent and reduces surprises when engineers move between teams.

Most Cloud NAT incidents come from a short list of repeated design mistakes.

Why these mistakes are so common

These anti-patterns spread because they work in small environments. With a handful of machines and a few connections, default settings never run out of ports, automatic addresses never cause allowlist problems, and unlogged traffic never needs an audit. The trouble appears only when the system grows, and by then the habits are everywhere. Reviewing designs early, while they are small, is much cheaper than fixing them at scale.

A short checklist of habits separates calm Cloud NAT operations from stressful ones.

Habits that pay off

Mistakes that appear again and again

A small runbook for on-call engineers

When an alert fires at night, people think poorly and need a short, clear guide. A good Cloud NAT runbook lists the symptom, the first three things to check, and the safe actions. For a port usage alert, the guide might say: identify the busiest machines, identify the busiest destination, check whether a recent release changed connection behavior, and consider raising the minimum ports or adding an address if the pool is the limit. It should also list actions that are not safe, such as lowering port settings during peak traffic, because those can drop live connections.

Keep the runbook near the alert itself, update it after each incident, and rehearse it occasionally. Teams that practice recover faster, and new engineers gain confidence sooner.

Cloud NAT removes a lot of operational work, but it comes with limits and costs worth understanding.

Cloud NAT compared with the alternatives

How the bill is built

Google prices Cloud NAT using a few components. There is a charge related to gateway usage per machine over time, a charge for the amount of data processed through the gateway, and separate charges for any external IP addresses you reserve and for logging volume. The details and rates change, so always read the current pricing page. What matters for design is the shape of the cost: it grows with the number of machines using the gateway, with outbound data volume, and with the number of reserved addresses.

Budgeting a gateway sensibly

Cost planning for Cloud NAT is easier when you separate the fixed and the variable parts. Reserved addresses and the number of machines using the gateway are mostly predictable. Data processed and log volume vary with traffic. A healthy habit is to review the data processed each month, identify the biggest senders, and ask whether their traffic could take a cheaper path, such as Private Google Access for Google services, a regional cache for downloads, or a smaller log setting for chatty gateways.

Also remember the hidden cost of outages. A few extra reserved addresses and some monitoring are cheap compared with an hour of failed calls to a payment provider. Spend on prevention where the business impact is highest, and be frugal where traffic is harmless.

Walking through realistic situations shows how the ideas fit together.

Quick answers to the questions that come up most often.

Neither. It is a distributed, software-defined managed service built on Google’s Andromeda network virtualization. You configure it, but you never size, patch, or restart a machine for it.

No. Cloud NAT translates only established inbound response packets. For inbound traffic, use a load balancer or another appropriate entry point.

The usual causes are no gateway covering its subnet, a firewall egress rule blocking the traffic, a missing route, or exhausted ports. Check coverage first, then firewall rules, then port metrics.

Those machines use their own external address for internet traffic, so their connections do not use NAT ports.

Not when Private Google Access is in use. Google’s documentation says traffic to Google APIs and services goes through Private Google Access even when Public NAT exists.

It happens when a machine uses all the ports assigned to it, so new connections to a destination fail. Prevent it by monitoring port usage, using dynamic port allocation or higher minimums, reusing connections, and adding addresses when needed.

Use automatic for simplicity when nobody depends on your addresses. Use manual when a partner or system uses an allowlist, because the addresses stay fixed.

The default established TCP idle timeout is 1,200 seconds. Enable keep-alive in your application or raise the timeout if long idle periods are normal.

Public NAT lets private resources reach internet destinations using shared external addresses. Private NAT translates traffic between private networks, which helps with overlapping ranges, hybrid connections, and NAT64.

No. Gateways are regional, so you create one in each region that has private workloads needing outbound access.

Google states that Cloud NAT does not reduce the network bandwidth per machine, because the translation is distributed rather than funneled through one device.

Yes. NAT64 translates IPv6 traffic to IPv4 destinations. Google’s release notes list it as generally available for Public NAT since August 2025 and for Private NAT since October 2026.

Use Cloud NAT logs. They record the private source, the translated address and port, and the destination, so you can trace shared-address traffic back to one workload.

Cloud NAT is the quiet mailroom of your Google Cloud network. It lets private workloads reach the internet and other networks without public addresses, shares a limited pool of addresses and ports among many machines, and refuses to deliver anything nobody asked for. Success with it depends less on clever settings than on good habits: private workloads by default, deliberate address choices, port monitoring, connection reuse, sensible timers, and egress controls that decide what may leave.