NAT Gateway is a fully managed service that securely routes internet traffic from a private virtual network with enterprise-grade performance and low latency.
Hi, NAT Gateway charges even when “idle.” You pay a fixed hourly fee per NAT GW (partial hours bill as full) plus data processed (outbound + return); if the NAT GW still exists and is attached to a subnet, the meter keeps running, also, any background egress (VM updates, AKS image pulls, agents) will add data charges. And once a NAT GW is on a subnet it takes precedence over LB outbound/IPs, so all egress in that subnet flows (and bills) through it.
What to do (cheapest first):
-Delete the NAT Gateway (and its Public IPs/prefix) when you don’t need internet egress; there’s no “stop” state, only deletion stops the hourly meter. Recreate later via IaC. Then put workloads that must egress on a separate subnet you can attach a NAT GW to only when needed.
-For small/dev workloads, use Standard Load Balancer outbound rules or an instance public IP on just the VM(s) that need egress; both are usually cheaper at low volume (you’ll still pay bandwidth, but no NAT GW hourly).
-Right-size & limit traffic: keep only the needed number of Public IPs on the NAT GW, move chatty services off that subnet, and reduce background egress (AKS pulls from ACR in-region/private link, OS updates via WSUS/repo mirror).
-Verify what’s driving cost: in Cost analysis filter by NAT Gateway meters (Hours vs Data processed); in Metrics check SNAT Connection Count / Total SNAT Connection Count and bytes to see if something kept talking while you were away; for deeper visibility turn on VNet flow logs for the subnet.
Rule of thumb: keep NAT Gateway for scale/stable egress; otherwise prefer LB outbound or per-VM public IP and only enable NAT GW on subnets that truly need it.