IPv4 address leasing is a line item that quietly grows. When we started evaluating cost reduction opportunities, the per-IP charges for our development and staging VMs were a meaningful chunk of the networking bill. Moving to IPv6 with NAT64/NAT44 solved it.
The Problem with IPv4-first
Every VM that needs internet access — whether for pulling container images, reaching cloud APIs, or serving outbound webhooks — traditionally required a public IPv4 address or a separate NAT gateway with a reserved IPv4. At scale, this adds up.
The IPv6 Model
The shift is conceptually simple:
- Assign IPv6 addresses to VMs instead of public IPv4
- Let a Cloud NAT instance handle translation — NAT64 for IPv6-to-IPv4 (reaching IPv4-only destinations), NAT44 for standard outbound IPv4 traffic where needed
On GCP, this maps to a Cloud NAT gateway configured on a subnet with IPv6 ranges. VMs get global IPv6 addresses at no per-address cost, and outbound IPv4 reachability is handled transparently by the NAT layer.
What Changes Operationally
Connectivity for most workloads is unchanged — containers pull images, services reach external APIs, nothing breaks. The exceptions are scenarios that assume a predictable public IPv4 for allowlisting. For those, a single shared NAT IP (or a small pool) still covers the requirement, just shared rather than per-VM.
DNS also needs attention. Internal services should resolve to IPv6 addresses. Applications that hardcode ::1 or assume IPv4 loopback need review. In practice, most modern container images and Go/Python services handle dual-stack or IPv6-only transparently.
The Hurricane Electric IPv6 Certification
Running production IPv6 infrastructure is also a useful forcing function for understanding the protocol deeply. I completed the Hurricane Electric IPv6 Professional certification as part of getting fluent with the operational side — PTR records, 6in4 tunnels, prefix delegation, and the rest.
Takeaway
IPv6 + Cloud NAT is not a theoretical optimization. It is a practical, production-tested approach to reducing networking costs while maintaining full internet reachability. The main investment is the initial planning — subnetting in /48s and /64s, configuring Cloud NAT correctly, and verifying that internal services resolve to IPv6 — but the ongoing maintenance burden is lower than managing per-VM IPv4 addresses.