Azure NAT Gateway
Does ZopNight manage Azure NAT Gateway?
NAT Gateway bills an hourly base rate from the moment it exists plus a per-GB charge for data processed, and a gateway attached to a subnet with no active workloads pays the base rate 24 hours a day. ZopNight maps subnet associations via Resource Graph so idle gateways surface in orphan review.
Rules that fire on Azure NAT Gateway
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
NAT Gateway provides outbound internet connectivity for subnets, billed hourly plus per GB processed. Gateways attached to subnets with no active workloads bill their base rate continuously.
An always-on base rate plus processed data
A NAT gateway carries an hourly resource charge that starts when the gateway is created and stops only when it is deleted, plus a per-gigabyte charge for the outbound data it translates. The data meter follows real usage; the hourly meter follows nothing but time. Because the gateway is a zonal, fully managed construct with no instances to size and no state to stop, there is no intermediate off position; it bills all 168 hours of every week regardless of whether the subnets behind it originate any connections. The public IPs it uses meter separately on their own hourly charge.
Subnet associations reveal idle NAT gateways
Discovered via Azure Resource Graph with subnet associations. Cost Management billing attributes spend, and idle gateways surface in orphan review. With no stop verb available, ZopNight leans on topology: a gateway whose associated subnets contain no running workloads (or that has no subnets at all) is paying its base rate to translate traffic that cannot exist. Reading associations at discovery time catches this without needing traffic metrics, though billing attribution confirms the data meter is flat.
NAT spend that outlives its subnets
Common leftovers: a gateway created for an environment whose VMs were deleted or moved, leaving the association in place and the hourly meter running; gateways stamped into every VNet by a template when only the production VNet has outbound-heavy workloads; and detached gateways, disassociated from their last subnet during a network redesign but never deleted, the purest form of this waste since they can no longer serve any traffic. Each retains its public IPs, which continue metering alongside.
NAT gateway review in the portal
Azure portal → NAT gateways lists each gateway with its VNet and subnet count. Open Subnets on a candidate: an empty association list, or subnets you know to be dormant, plus a flat data-processed chart under Metrics, makes the deletion case in a minute.