Cloud NAT
What does zop.dev create for Cloud NAT?
zop.dev creates 1 Cloud Router and 1 Cloud NAT inside every new VPC it provisions, covering all subnets with automatically allocated NAT IPs. It adds no NAT to a VPC you already have, so an existing VPC needs its own egress. NAT bills per hour per gateway plus per GB processed, and every private egress byte crosses it.
| Field | Value |
|---|---|
| Cloud | gcp |
Cloud NAT gives private workloads outbound internet access without public IPs. zop.dev creates a Cloud Router and Cloud NAT alongside every new VPC it provisions.
A router and NAT inside every new VPC
A Cloud Router plus a Cloud NAT that covers all subnets, with NAT IPs allocated automatically.
Created with the VPC
No separate inputs: the router and NAT are named after the cluster and created in its region.Existing VPCs bring their own egress
When a cluster uses an existing VPC, zop.dev creates no router or NAT, so the VPC needs egress already.
Check egress before you pick an existing VPC
In the common path the NAT arrives with the new VPC and nothing else is needed. A cluster landing in a VPC that predates zop.dev still needs outbound internet for its private nodes (image pulls, package mirrors, external APIs) without public IPs, and zop.dev will not add it. Check what the VPC already has before provisioning: without a NAT or another egress route, nodes cannot pull images.
The per-GB meter on egress
Cloud NAT bills two ways: per hour per gateway, and per GB of data processed. The hourly part is predictable; the per-GB part scales with behaviour. Every byte a private workload sends out crosses the NAT: a nightly job pushing large exports, a service streaming to an external API, a misconfigured pod pulling images in a crash loop. All of it lands on the processing meter. When the NAT line grows, the question is which workload’s egress changed, and VPC flow logs answer it faster than guessing.
Ports are the invisible limit
NAT works by lending each VM source ports for its outbound connections, and the port pool is finite. At scale, with many pods, many concurrent connections, and connection churn, port exhaustion appears as intermittently dropped or timed-out outbound connections while everything else looks healthy. The condition is diagnosable in NAT monitoring and tunable (ports per VM, additional NAT IPs), but only if someone knows to look; it is one of the classic invisible-until-production GCP failure modes, and worth checking early on any cluster running high-fanout workloads behind this router.