NAT gateways processing under 1 KB of traffic in a month
What does ZopNight detect here?
Azure bills a NAT gateway a flat ~$0.045/hr, about $32 a month, before any byte crosses it. ZopNight reads the ByteCount metric over 30 days and recommends deletion only when both average and maximum stay under 1,024 bytes, a bar that admits probe noise and nothing else.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1383 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | nat_gateway_idle.go |
Where it applies
The provisioning fee is the whole story
Azure NAT Gateway pricing has two parts: a flat ~$0.045 hourly provisioning fee and a per-GB charge on processed data. An idle gateway generates no data charge by definition, so what this rule recovers is the fixed fee, roughly $32 a month for a resource routing nothing. Because the fee is flat, the entire monthly cost becomes the savings figure when the gateway proves idle.
Under a kilobyte, in raw bytes
The gating metric is ByteCount on the NAT gateway, reported as a total per sampling window:
raw bytes, not bytes per second. Both the series average and the maximum must stay below 1,024
bytes across the window. A month of monitoring-probe noise fits under 1 KB; a single genuine
outbound flow does not. Any datapoint at or above the bar counts as real use and the rule
abstains.
Guard rails before an irreversible delete
Three additional gates protect against false positives. The gateway must be in a succeeded provisioning state. A resource mid-deploy or mid-delete never receives a destructive recommendation. The ByteCount series must span the full 30 days, so a two-week-old gateway that simply has not been exercised yet abstains rather than being deleted before its first workload arrives. And an absent metric (collector outage, permission gap) is treated as unknown traffic state, never as zero.
Measure it yourself
az monitor metrics list \ --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/natGateways/<name>" \ --metric ByteCount \ --interval PT1H --offset 30d --aggregation Average MaximumUnhooking a NAT gateway cleanly
A NAT gateway with subnet associations still serves as those subnets’ outbound path even when current traffic is nil. Confirm under Subnets that nothing routes through it, remove the associations, then delete. The attached public IP survives independently and keeps billing, so release it too. If a VNet needs outbound access only to specific Azure services, Private Link or service endpoints replace the gateway at lower cost.
Detection footprint
Reader covers gateway discovery and its subnet associations; Monitoring Reader covers ByteCount. ZopNight holds no write path to NAT gateways; the delete is always yours.