Cloud NAT Outbound Access for Private Workloads

Architecting Cloud NAT (opens in a new tab) solutions for secure outbound connectivity means designing managed egress so private workloads reach the internet without public addresses. Traffic flows from a private virtual machine (VM) or Kubernetes Pod endpoint to a Cloud NAT gateway, which translates the private source address to a selected outgoing address and forwards the traffic to the external network. Because private endpoints never appear directly on the internet, the gateway becomes a central point for controlling which workloads can egress and which identity they present externally. This design supports zero-trust and defense-in-depth by limiting egress to explicitly selected sources with predictable external identities.

1.1Cloud NAT Gateway Scope and Traffic Flow

Cloud NAT gateway scope and traffic flow define a project-scoped and zone-scoped control for external North-South traffic, not for internal East-West traffic. The gateway configuration selects its outgoing identity by specifying leaf subnets that contain the outgoing Internet Protocol (IP) addresses to use. The same configuration selects its allowed sources by specifying label selectors that match specific Pod or VM endpoints, and the subnets, endpoints, and outgoing traffic must all reside in the same zone and project as the gateway.

Egress through the gateway follows an ordered path:

1. Private endpoint initiates egress: A VM or Pod with only a private internal IP address sends traffic destined for an external network.
2. Gateway matches and translates: Traffic flows from the matched endpoint to the Cloud NAT gateway, which translates the private source to one of the outgoing IP addresses from the configured leaf subnets.
3. Gateway forwards externally: Translated traffic flows from the gateway to the external destination, while return traffic flows back through the same gateway to the originating endpoint.

This order enforces least privilege because only endpoints matched by the gateway label selectors can obtain outbound translation, and all other private endpoints remain isolated from the internet.

1.2Project Default Egress NAT Versus Cloud NAT

Project default egress NAT versus Cloud NAT is a choice between a deprecated automatic model and the current gateway model in Google Distributed Cloud air-gapped deployments. Projects were created with a default egress configuration that allowed VM or Pod endpoints carrying the label egress.networking.gke.io/enabled:true to egress using an egress IP automatically assigned to the project. Cloud NAT is now the main Network Address Translation (NAT) solution, and workloads in standard clusters must use Cloud NAT.

The two implementations cannot be used together, so architecture must choose one egress model per endpoint:

A Pod or VM endpoint cannot be connected to a Cloud NAT gateway through label selectors while also carrying the egress.networking.gke.io/enabled:true label. Migration therefore requires removing the default-egress label from endpoints and assigning them to a Cloud NAT gateway in the same project and zone.

1.3Controlling Egress Identity with Subnets and Label Selectors

Controlling egress identity with subnets and label selectors means combining which outgoing addresses the gateway may use with which endpoints may use the gateway. The leaf subnets named in the gateway configuration define the pool of outgoing IP addresses, so external allowlists, logging, and compliance checks see a predictable, project-owned source. The label selectors named in the same gateway define the eligible Pod and VM endpoints, so different applications, teams, or sensitivity levels can be assigned to different gateways with different outgoing addresses. Because gateways have project and zonal scope, a gateway in one project and zone cannot translate traffic for subnets or endpoints in another project or zone, which enforces blast-radius boundaries and requires explicit per-project, per-zone egress design rather than shared internet paths.

1.4Layering Cloud NAT with Network Security Controls

Layering Cloud NAT with network security controls means surrounding outbound translation with Virtual Private Cloud (VPC) (opens in a new tab) controls that limit who needs egress at all. Private resources should keep only internal IP addresses and reach Google APIs and services through Private Service Connect or Private Google Access while remaining isolated from the public internet. Organizational policies further restrict which resources are allowed to use external IP addresses, and the stateful VPC firewall applies distributed rules to each VM.

The layered controls that combine with Cloud NAT include:

• VPC firewall rules: Traffic is filtered from the private endpoint to the gateway and from the workload to other internal destinations, starting with broad VPC-wide rules and narrowing to subnet, group, and individual VM targets.
• Service-account and tag isolation: Firewall targets use service accounts or tags to limit rules to only the VMs in a subnet or application tier that require egress.
• VPC Service Controls: Service perimeters are configured around VPC resources and Google-managed services to control movement of sensitive data across the perimeter boundary.
• Private Service Connect and Private Google Access: Internal-only endpoints reach key Google and Google Cloud services without traversing the internet or consuming gateway translation.
• Secure Web Proxy: Outbound web traffic is proxied when HTTP(S) inspection and identity controls are required instead of raw address translation.

Integrating Cloud NAT (opens in a new tab) with broader network security and observability frameworks means combining managed translation with firewall, private-access, and monitoring controls. A Cloud Router holds the gateway configuration as the control plane, while Andromeda software in the Virtual Private Cloud (VPC) network performs source network address translation (SNAT) on outbound packets and destination network address translation (DNAT) on established inbound responses. Cloud NAT never allows unsolicited inbound connections and does not replace firewall, identity, or private-access controls.

2.1How Firewall Rules Govern Cloud NAT Egress

How firewall rules govern Cloud NAT egress is that VPC firewall rules still govern traffic that uses Cloud NAT, so a private VM can reach the internet only when egress firewall rules allow it. A Cloud NAT configuration is tied to a VPC network and serves the subnets and IP ranges selected in its mapping, and it cannot select individual VMs. When a Cloud NAT gateway for Public NAT uses manual NAT IP address assignment, the gateway shares a fixed set of common external source IP addresses that a destination party can allowlist.

Outbound traffic moves through an ordered path where each stage depends on the previous one:

1. Egress firewall evaluation: Traffic flows from the VM internal IP address to the VPC firewall rule evaluation.
2. Source translation: Allowed traffic flows from the VPC network to the Cloud NAT gateway, which translates the internal source to a shared external IP address and source port.
3. Return translation: Response traffic flows from the internet back to the Cloud NAT gateway, which performs DNAT to the original internal IP address only for established connections.

Private NAT performs the same outbound function for private-to-private traffic between VPC networks or between VPC and on-premises or other cloud networks, but the Cloud NAT gateway translates sources by using IP addresses from the Private NAT subnet range.

2.2How Private Google Access Bypasses Public NAT

How Private Google Access bypasses Public NAT is that traffic sent to Google APIs and services is routed through Private Google Access even if the VM that initiates the connection uses Public NAT. Private Google Access is the path for private VPC subnets to reach Google APIs and services without external IP addresses, and it takes precedence over Public NAT for that traffic. Use Private Google Access with custom DNS zones to allow connectivity from private subnets to Google APIs, which lets nodes and Pods pull container images and call APIs without sending that traffic through NAT external addresses. This separation creates a clear trust boundary where internet egress flows through the Cloud NAT gateway and its external addresses, while Google API traffic stays on private paths controlled by Private Google Access.

2.3Defense-in-Depth Controls Around GKE Egress

Defense-in-depth controls around Google Kubernetes Engine (GKE) egress mean Cloud NAT provides address translation while other controls decide which workloads can send traffic and where that traffic can go. Traffic leaving Pods within a service mesh is directed through dedicated egress gateway proxies (opens in a new tab) running on dedicated nodes, and the egress gateways scale with a horizontal Pod autoscaler so replica count grows and shrinks with traffic. The Cloud NAT gateway must provide enough simultaneous connections for those egress gateways, so setting an appropriate minimum number of ports per VM avoids port exhaustion and connection-reuse delays, and adding egress gateway replicas reduces endpoint-independent mapping conflicts.

The surrounding controls divide by network layer and scope:

Namespaces provide isolation and delegated administrative control, with a dedicated namespace for network administrators to deploy the egress gateway and configure routing to external hosts. Sidecar resources control the configuration scope of sidecar proxies in each workload Pod by defining which namespaces, Pods, and external services are visible to a workload. Workload Identity grants Google Cloud API permissions to specific workloads through Identity and Access Management (IAM) following least privilege without handling secrets.

2.4Logging, Monitoring, and Alerting for Anomalous Outbound Traffic

Logging, monitoring, and alerting for anomalous outbound traffic combine Cloud Logging for connection detail with Cloud Monitoring and Network Analyzer for fleet health and anomaly detection. Logging is disabled by default and, when enabled, traces NAT connections and bandwidth for distinct purposes:

• Compliance recording: Outbound connections and address use are recorded for audit and compliance review.
• Debugging: Failed or dropped outbound flows are traced to identify firewall, port, or address causes.
• Analytics: Destination and volume patterns are analyzed to understand normal egress behavior.
• Accounting: Bandwidth use is accounted by workload or subnet for chargeback and capacity planning.

Cloud NAT exposes key gateway metrics to Cloud Monitoring automatically, where the metrics flow from the NAT gateway to Cloud Monitoring for custom dashboards, metric queries, and alerting policies. Alerts can watch for port exhaustion, dropped packets from insufficient NAT IP addresses, sudden growth in simultaneous connections, or outbound volume spikes that suggest data exfiltration or compromised update behavior. Network Analyzer automatically monitors the Cloud NAT configuration and publishes Cloud NAT insights, so the insight flows from Network Analyzer to the operator as a complement to manually built alerts.

Configuring and optimizing NAT gateway parameters and routing means tuning how a distributed translation service assigns addresses and ports without exposing private subnets. Cloud NAT (opens in a new tab) is a distributed, software-defined service that provides source network address translation (SNAT) for outbound traffic from private Google Cloud resources and destination translation (DNAT) only for established inbound responses. A Cloud Router (opens in a new tab) holds the gateway configuration as the control plane, while Andromeda software on the physical hosts enforces the translation. A Public NAT gateway is bound to one Virtual Private Cloud (VPC) network in one region and serves only the subnet IP ranges selected in its mapping, so private VM instances, GKE nodes, and serverless endpoints in those ranges can reach the internet without external IP addresses.

3.1Static and Dynamic Port Allocation

Static and dynamic port allocation control how the Cloud NAT gateway divides its pool of NAT IP addresses and source ports among endpoints. Static port allocation is the default and reserves the same fixed number of ports for every VM that uses the gateway. Dynamic port allocation lets the gateway allocate ports to each VM based on actual usage, between a configured minimum and maximum, which improves utilization of a fixed IP pool and helps prevent port exhaustion. Dynamic port allocation works with either automatic or manual NAT IP address allocation.

The allocation modes compare as follows:

With manual allocation, the operator must still reserve enough external addresses for expected load, because an undersized pool causes dropped packets and, for proxy-based load balancer endpoints, HTTP 5xx errors. For managed proxy load balancers serving regional internet network endpoint groups (NEGs), the recommended tuning is 2048 minimum ports and 4096 maximum ports per VM. For operating system update workloads, specify at least 160 as the minimum ports per instance to handle concurrent update processes.

3.2Minimum and Maximum Ports per VM

Minimum and maximum ports per VM define the lower reservation and the upper growth limit for each endpoint behind a Cloud NAT gateway. In static mode only the minimum applies, so raising the minimum increases per-VM capacity but consumes the shared NAT IP and port pool faster. In dynamic mode the gateway starts each VM at the minimum and adds ports on demand up to the maximum, then reclaims idle ports for reuse by other VMs. Tuning is a tradeoff between compatibility and efficiency because a value that is too low causes port exhaustion, connection failures, and dropped packets during bursts, while a value that is too high wastes ports on idle VMs and reduces the number of VMs a fixed set of NAT IP addresses can serve. Monitor allocation failures with the nat_allocation_failed metric and add NAT IP addresses or adjust the minimum and maximum before exhaustion affects production traffic.

3.3Endpoint-Independent Mapping and Application Compatibility

Endpoint-independent mapping (EIM) is a NAT behavior defined in RFC 5128 that reuses the same external NAT IP address and port for a private endpoint regardless of the internet destination it contacts. Public NAT also supports endpoint-dependent filtering, and EIM is disabled by default when a gateway is created. When EIM is enabled, outbound traffic from one internal source maps consistently, which helps protocols and applications that expect a stable external identity across multiple destinations. EIM has strict compatibility limits that affect security and design choices because a Cloud NAT gateway with EIM enabled cannot use dynamic port allocation and cannot use NAT rules for custom source matching. Choose EIM when application compatibility requires a consistent external mapping, and choose dynamic port allocation or NAT rules when efficient scaling or fine-grained source control matters more.

3.4Gateway Routing Scope and Change Safety

Gateway routing scope determines which private sources can use outbound NAT within the bound network and region. The gateway applies to the VPC network and region selected with its Cloud Router, and to the configured source ranges including primary and secondary ranges for IPv4, or internal and external ranges for IPv6 NAT64. A configuration cannot select individual VMs, so every eligible endpoint in the chosen subnets or ranges shares the gateway, and multiple gateways in the same region and VPC network must use unique subnets or unique ranges within a subnet.

Several parameter changes immediately disrupt established flows because the gateway releases IP addresses or resets port assignments:

• Changing the network tier of automatically allocated NAT IP addresses: All connections on the old addresses close and a new set allocates from the new tier.
• Changing manually allocated NAT IP addresses: All connections on the removed addresses close.
• Reducing minimum ports per VM with static allocation: Established connections can break.
• Making any configuration change with dynamic allocation enabled: Each VM can temporarily reset to its configured minimum and break connections.
• Turning off dynamic port allocation: All VM connections that use the gateway close.

To maintain security posture while tuning, keep logging intent explicit because NAT logging is disabled by default, retain egress firewall controls on private VMs, and use manual NAT IP addresses only when an external allowlist requires stable, known source addresses.

Key Facts

• Cloud NAT translates private VM or Pod source addresses to selected outgoing addresses for internet egress and never allows unsolicited inbound connections.
• A Cloud NAT gateway in one project and zone cannot translate traffic for subnets or endpoints in another project or zone.
• Traffic to Google APIs and services uses Private Google Access even when Public NAT covers the originating subnet.
• Static port allocation defaults to 64 minimum ports per VM, while dynamic port allocation defaults to 32 minimum and 65536 maximum ports per VM.
• A Cloud NAT gateway with endpoint-independent mapping enabled cannot use dynamic port allocation or NAT rules.