Cloud NAT Calculator
Size Cloud NAT ports and addresses from VM count and price gateway uptime plus per-GB data processing.
Inputs
Cloud NAT reserves 64 ports per VM by default, which limits concurrent connections to one destination.
Each NAT IP offers 64,512 usable source ports.
Cloud NAT bills gateway uptime by VM count; confirm the tier that applies to your fleet size.
Monthly Cost
$224.53
NAT Addresses Required
1addresses
Gateway Uptime Charge
$40.88
Data Processing Charge
$180.00
External Address Charge
$3.65
Total Ports Allocated
2,560ports
Port Headroom per VM
25.0%
Port Exhaustion Risk
Low — comfortable port headroom for the observed peak
Step by step
Values used
VMs behind the gateway = 40 VMs; Ports reserved per VM = 64 ports; Usable ports per NAT address = 64,512 ports; Gateway uptime price per VM-hour = 0.0014 USD/VM-hour; Data processed through NAT = 4,000 GB; Data processing price per GB = 0.0450 USD/GB; In-use external address price per hour = 0.0050 USD/hour; Hours in the billing month = 730 hours; Peak connections per VM to one destination = 48 connections
Cloud NAT
NAT addresses = ceil(VMs × ports per VM ÷ 64,512); cost = VMs × uptime price × hours + GB processed × data price + addresses × address price × hours.
Monthly Cost
= 224.53
NAT Addresses Required
= 1 addresses
Gateway Uptime Charge
= 40.88
Data Processing Charge
= 180.00
External Address Charge
= 3.65
Total Ports Allocated
= 2,560 ports
How it works
Cloud NAT reserves a fixed block of source ports per VM up front rather than allocating them on demand, so the address requirement is purely arithmetic: total reserved ports divided by the 64,512 ports each NAT IP provides. The billing is separate again — gateway uptime scales with VM count and data processing is charged per GB in both directions. The default 64 ports per VM is fine for a web server and hopeless for a crawler or a service that opens hundreds of connections to one API endpoint, and exhaustion shows up as intermittent connection timeouts rather than a clear error. Confirm the current uptime tier and per-GB processing price in the Google Cloud pricing calculator.
Formula
Cloud NAT
NAT addresses = ceil(VMs × ports per VM ÷ 64,512); cost = VMs × uptime price × hours + GB processed × data price + addresses × address price × hours.
- ports per VM
- Source ports Cloud NAT reserves per VM, 64 by default
- 64,512
- Usable source ports each NAT IP address provides
- port headroom
- Gap between reserved ports and the observed peak connections to one destination
Frequently Asked Questions
How is Cloud NAT calculated?
NAT addresses = ceil(VMs × ports per VM ÷ 64,512); cost = VMs × uptime price × hours + GB processed × data price + addresses × address price × hours. Cloud NAT reserves a fixed block of source ports per VM up front rather than allocating them on demand, so the address requirement is purely arithmetic: total reserved ports divided by the 64,512 ports each NAT IP provides. The billing is separate again — gateway uptime scales with VM count and data processing is charged per GB in both directions.
Why does Cloud NAT matter?
The default 64 ports per VM is fine for a web server and hopeless for a crawler or a service that opens hundreds of connections to one API endpoint, and exhaustion shows up as intermittent connection timeouts rather than a clear error. Confirm the current uptime tier and per-GB processing price in the Google Cloud pricing calculator.
What values do I need to enter?
This calculator takes 9 inputs: VMs behind the gateway, Ports reserved per VM, Usable ports per NAT address, Gateway uptime price per VM-hour, Data processed through NAT, Data processing price per GB, In-use external address price per hour, Hours in the billing month, Peak connections per VM to one destination. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why do ports run out when the VM has plenty of sockets?
Cloud NAT ports are consumed per unique destination tuple, so 64 ports means 64 simultaneous connections to the same destination address and port — not 64 connections in total. Raising the minimum ports per VM, or enabling dynamic port allocation, is the fix.