Cloud NAT is a managed network address translation service that allows resources without public IP addresses, such as virtual machines and containers in private subnets, to open outbound connections to the internet or other external networks while remaining unreachable from outside. In cloud networking, it is the standard way to give private workloads access to software updates, external APIs and package repositories.
The provider operates the translation as a scalable, highly available function rather than as a server the customer maintains. Major platforms offer it under different names, including the NAT gateway in AWS, Azure NAT Gateway and Cloud NAT in Google Cloud, but the core behavior is the same: source addresses are rewritten to one or more public addresses, and only return traffic for established connections is allowed back.
How Cloud NAT translates outbound traffic
Cloud NAT performs source network address translation, usually called SNAT, combined with port translation. When a private instance with the address 10.0.2.15 opens a connection, the NAT service replaces the source address with a public egress IP and assigns a source port from its pool. It records the mapping, and when the response arrives it reverses the translation and forwards the packet to the original instance.
Because many private instances share a few public addresses, the source port becomes the scarce resource. A single IPv4 address offers roughly 64,000 usable ports, and each concurrent connection to the same destination address, port and protocol needs a distinct port. The table below summarizes the parameters that shape this behavior.
| Parameter | Typical range or default | What it affects |
|---|---|---|
| Public IPs attached | One to a few dozen per gateway | Total available ports and allowlisting |
| Ports per IP | About 64,000 | Upper bound of concurrent translations |
| Ports per instance | Fixed minimum or dynamic allocation | How many parallel connections one VM can open |
| TCP idle timeout | From about 4 minutes to 20 minutes, provider dependent | How long silent connections keep their port |
| Throughput | Several Gbps, scaling to tens of Gbps | Maximum egress bandwidth per gateway |
Where Cloud NAT fits in a VPC
Cloud NAT sits at the edge of a VPC or virtual network and is referenced by the routing configuration of private subnets. A route sends internet-bound traffic, the default route 0.0.0.0/0, to the NAT service. On some platforms the gateway is placed in a public subnet and itself uses an internet gateway; on others it is configured on a regional router without a visible appliance.
The service works alongside other network controls rather than replacing them. Security groups and firewall rules still decide which instances may send traffic, while the NAT service decides how that traffic appears externally. The comparison below places Cloud NAT among its neighbors in cloud networking.
| Component | Direction of traffic | Main purpose |
|---|---|---|
| Cloud NAT | Outbound only, replies allowed back | Internet access for private resources |
| Internet gateway | Inbound and outbound | Connectivity for resources with public IPs |
| Private endpoint | Private access to a specific service | Reach managed services without the internet |
| Cloud load balancer | Inbound | Distribute client traffic to backends |
| Self-managed NAT instance | Outbound | Custom control at the cost of maintenance |
Design choices and configuration
The most important design decision is availability scope. Some providers implement the NAT gateway per availability zone, so a resilient design deploys one gateway per zone and routes each zone’s private subnets to its local gateway. Routing all zones through one gateway saves money but creates a single point of failure and adds cross-zone data charges.
The second decision concerns static egress addresses. Many partners and SaaS providers accept traffic only from allowlisted IPs, and Cloud NAT gives a small, predictable set of public addresses for an entire fleet. Reserving those addresses explicitly prevents them from changing when the gateway is recreated.
| Situation | Recommended approach | Reason |
|---|---|---|
| Private VMs need updates and APIs | Cloud NAT | Outbound access without public exposure |
| Heavy traffic to cloud storage or databases | Private endpoint or service endpoint | Avoids NAT processing charges and port use |
| Partner requires fixed source IPs | Cloud NAT with reserved addresses | Stable allowlist entries |
| Deep packet inspection required | Firewall appliance or managed firewall | NAT does not inspect content |
| IPv6-only workloads | Egress-only internet gateway or NAT64 | IPv6 does not need address sharing |
Limitations and common problems
The classic failure is port exhaustion. A workload that opens many short-lived connections to the same external endpoint, for example a crawler or a service without connection pooling, can consume all ports assigned to an instance. New connections then fail or time out while existing ones keep working, which makes the problem look intermittent.
- Port exhaustion: reuse connections, enable dynamic port allocation or add public IPs.
- Silent connection drops: long idle TCP sessions exceed the NAT idle timeout; use keepalives shorter than the timeout.
- Unexpected cost: NAT services usually charge per hour and per gigabyte processed, so bulk transfers to cloud services should use private endpoints.
- No inbound access: Cloud NAT never forwards unsolicited inbound traffic, so it cannot publish a service; a load balancer is needed for that.
- Logging gaps: translation logs are often off by default, which complicates troubleshooting and audits.
A related misconception is that Cloud NAT is a security boundary in its own right. It hides private addresses and blocks unsolicited inbound connections, but it does not filter outbound destinations or inspect payloads. Egress control still requires firewall rules or a dedicated filtering service.
A plain-language summary
Picture an office where employees have internal phone extensions but no direct outside lines. When someone calls a supplier, the call goes out through the company’s main number. The supplier can call back on that line, but strangers cannot dial a private extension directly.
Cloud NAT is that shared outside line for cloud servers. Private machines can reach the internet for updates and services, while the outside world sees only a few company addresses and cannot start a conversation with the machines themselves.
An example from practice
A payments company runs forty application servers in private subnets across three availability zones. The servers must call a card network API that accepts traffic only from pre-registered IP addresses. The network team deploys a Cloud NAT gateway in each zone, each with two reserved public addresses, and registers those six addresses with the partner.
During a sales peak, monitoring reports connection errors from a few servers. The NAT logs show port allocation failures caused by a client library that opened a new connection for every request. After enabling connection pooling and dynamic port allocation, errors disappear. The team also routes nightly backups to object storage through a private endpoint, which noticeably reduces NAT data processing charges.