Egress capacity is more than an internet route
Cloud NAT translates source addresses for supported outbound traffic. A private workload may have a valid route and still fail to establish new connections if the required translation resources are unavailable. This can appear as intermittent dependency timeouts rather than a complete loss of internet connectivity.
Google documents dropped outbound packets with an OUT_OF_RESOURCES reason when translation resources are exhausted. Port allocation can be static or dynamic, and dynamic growth can still involve transient drops. Begin with observed allocation and demand rather than assuming every outbound timeout has the same NAT cause.
Design the initial egress budget
- Identify which workloads and source ranges use the NAT configuration. Record region, network, gateway owner and remote destinations that require a stable egress policy.
- Review the selected allocation mode against expected connection patterns. A bursty worker opening many short-lived connections behaves differently from a steady service reusing a pool.
- Configure relevant metrics and sanitized diagnostic logging, then rehearse a representative ramp-up. Record the rollback and notification requirements for any egress-address change.
For beginners, one successful outbound request is not a capacity test. The important behavior may occur only when several replicas create connections at the same time.
Illustrative incident: a worker rollout creates a connection burst
A release starts many workers together, each creating fresh connections to the same external API. Some requests time out during the burst while existing sessions continue. This is an illustrative scenario. Increasing application retries without controlling concurrency can create even more new connections and make the investigation harder.
Correlate demand with translation evidence
Compare workload rollout time, new-connection behavior and NAT metrics over the same interval. Review whether the affected source actually uses this gateway. NAT logs are useful evidence, but the absence of a matching entry is not proof that no relevant packet was dropped; logging has coverage and rate limitations.
| Observation | Next check | Decision it supports |
|---|---|---|
| Drops show resource exhaustion | Allocation mode and demand per source | Translation capacity review |
| Timeouts align with replica startup | Connection creation and concurrency | Application ramp-up review |
| One destination fails without related drops | Remote endpoint, DNS and route evidence | Investigate another layer |
| Capacity change is proposed | Egress policy and connection behavior | Reviewed network change |
Do not treat packet-drop counts as a direct count of failed business transactions. One request can retry, and one connection can serve multiple operations. Keep network and application measurements linked but distinct.
Correct demand and capacity together
For the illustrative burst, review connection reuse, bounded worker concurrency and controlled ramp-up before selecting an allocation change. If evidence supports more translation capacity, use the documented configuration path and assess effects on existing connections and egress-address expectations. A remote allowlist may need coordinated ownership if public addresses change.
Rehearse the original connection burst outside production. Confirm both lower network failure evidence and successful end-to-end operations within the application's latency budget. Test steady state and recovery after a worker restart. Increasing low-level retry duration can hide failures by turning them into latency, so evaluate response time as well as eventual success.
Monitoring and incident handover
Track connection demand, resource-exhaustion drops, outbound error rate and dependency latency. An illustrative internal objective might require a planned workload ramp to complete with no resource-exhaustion drops and with the agreed transaction latency maintained. This is a capacity acceptance example, not a Cloud NAT SLA or a measured customer result.
The SOP should retain source workload, gateway, allocation mode, observed demand, remote dependency owner and reversal trigger. Escalate changes affecting shared egress or remote allowlists before rollout. Review the budget when replica count or connection-pool behavior changes, even if traffic volume appears similar.
See network management for related cloud egress planning.
Technical reference
Google Cloud: troubleshoot Cloud NAT, ports and addresses and logging and metrics. Reviewed 19 October 2026.