Understand Cloud NAT and network egress charges
On this page
Decide whether the material charge is Public NAT gateway uptime, external IP usage, or data processing; Private NAT gateway uptime or processing; an applicable connectivity or data-transfer charge; or logging, then assign the relevant path for review.
Why this is worth a look
Cloud NAT pricing separates gateway uptime, data processing, and path-specific charges. Public NAT can also charge for external IP addresses and data transfer out, while Private NAT can add Cloud Interconnect, Cloud VPN, or Network Connectivity Center service costs. Metrics and available log fields provide operational context, but sampled or rate-limited logs should not be treated as billing totals.
Run this check
CHECKLISTA read-only inspection checklist for a consistent project and time window. It classifies the actual billing lines, identifies the Public NAT or Private NAT path, and uses documented metrics and available log fields for context.
CLOUD NAT CHARGE ATTRIBUTION
Assume one consistent set of projects and one billing time window.
[ ] Inspect billing data for that project and time scope. Record each material service and SKU line, its cost, usage amount, usage unit, and billing time window. Keep hours, external-IP hours, and GiB as separate units.
[ ] Identify the NAT variant from the SKU or gateway context: Public NAT or Private NAT. For Public NAT, distinguish gateway uptime, external IP usage, data processing, and data transfer out. For Private NAT, distinguish gateway uptime, data processing, and applicable Cloud Interconnect, Cloud VPN, or Network Connectivity Center service costs. Keep Cloud Logging, BigQuery, or Pub/Sub charges separate when NAT logging is exported or stored there.
[ ] For the same time window, inspect Cloud NAT metrics for the relevant gateway or VM. Use documented metrics such as sent and received bytes and packets, allocated ports, sent or received packets dropped, and maximum connections from a VM to one destination endpoint. Note the metric sampling delay and do not convert these observations into billed usage.
[ ] If NAT logging was enabled, inspect the available fields before grouping records. Use documented fields where present, including destination IP and port, NAT port, region, project ID, and subnetwork name. Separate connection-created records from outbound TCP or UDP packets dropped because no NAT port was available.
[ ] If existing VPC Flow Logs are in scope, record their reporting project and aggregation interval, note that primary sampling is dynamic, and record the configured secondary sampling rate and metadata settings. Use the flows to explain traffic patterns, not to recreate the invoice.
[ ] Route gateway uptime, IP usage, or NAT processing findings to the NAT owner. Route Public NAT data-transfer-out or Private NAT connectivity-service findings to the workload and network-path owners. Track logging charges separately.How to confirm it
- 01
Set one evidence window
Choose one consistent set of projects and one billing time window. Inspect the billing data in that scope and retain each material service and SKU line with its cost, usage amount, usage unit, and time window. Keep hours, external-IP hours, and GiB separate.
- 02
Identify the NAT variant
Use the billing line or gateway context to distinguish Public NAT from Private NAT. Classify Public NAT gateway uptime, external IP usage, data processing, and data transfer out separately. For Private NAT, classify gateway uptime, data processing, and applicable Cloud Interconnect, Cloud VPN, or Network Connectivity Center service costs separately.
- 03
Compare operational evidence
For the same window, inspect Cloud NAT metrics for the relevant gateway or VM. Review sent and received bytes and packets, allocated ports, dropped packets, and maximum connections from a VM to one destination endpoint. Treat metrics as context, not billed usage.
- 04
Inspect available records
If NAT logging was enabled, inspect its available fields before grouping records. Documented fields include destination IP and port, NAT port, region, project ID, and subnetwork name. Separate connection-created records from outbound TCP or UDP packets dropped because no NAT port was available. If VPC Flow Logs are in scope, note their reporting project and aggregation interval, dynamic primary sampling, configured secondary sampling rate, and metadata settings.
- 05
Assign the review owner
Use the classified charge and supporting traffic evidence to route gateway uptime, IP usage, or NAT processing to the NAT owner. Route data-transfer-out or Private NAT connectivity-service findings to the workload and network-path owners, and keep logging costs separate.
Before making changes
Assumptions: the billing data covers the same projects and time window as the metrics and records, and the relevant NAT variant can be identified. Cloud NAT logs are optional, handle TCP and UDP, and have a per-VM vCPU-based rate threshold. They log connection creation or outbound TCP and UDP drops caused by no available NAT port, depending on configuration. VPC Flow Logs use dynamic primary sampling, aggregate sampled packets, and apply configurable secondary sampling, so neither log source is a billing ledger.