Azure Network Watcher
Does ZopNight manage Azure Network Watcher?
Azure Network Watcher deploys 1 instance per region, and the instance itself is cheap. The real charges come from what it emits: NSG flow logs landing in storage accounts and connection monitor test runs. ZopNight discovers every instance via Resource Graph for inventory completeness and regional coverage review.
Rules that fire on Azure Network Watcher
No active rule family targets Azure Network Watcher today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery only. |
Network Watcher provides network diagnostics, flow logs, and connection monitoring per region. The instance is cheap, but its flow logs and tests can drive storage and test-run charges.
One per region, charges downstream
Network Watcher exists as a regional singleton: Azure creates one instance in each region where virtual networks appear, and that instance costs little on its own. The meaningful meters sit downstream of it. Flow logs bill for the log data collected and for the storage account capacity that accumulates it, growing with traffic volume and retention. Connection monitor bills per test run, so a monitor probing aggressively across many endpoint pairs meters continuously. Traffic analytics, where enabled on top of flow logs, processes that collected data for a further charge. The pattern is a cheap sensor with billable exhaust.
Why ZopNight tracks a near-free resource
Discovered via Azure Resource Graph for inventory completeness and regional coverage review. Network Watcher is discovery-only, with no state to stop and no schedule to apply, but its presence map answers two useful questions: which regions have diagnostic tooling enabled at all, and where flow-log emitters exist whose storage destinations deserve a look. Inventory completeness matters here precisely because the resource is forgettable; it appears automatically and nobody audits what it was configured to record.
The exhaust that outlives the investigation
Flow logs are typically enabled during an incident or a compliance push and never turned off, accumulating storage indefinitely for packets nobody will re-inspect. Retention on the destination storage account is the second lever people miss, with logs kept forever because no lifecycle policy was set. And connection monitors built for a migration keep running their test matrix long after the migration ended, paying per run for answers nobody collects.
Confirming coverage region by region
Azure portal → Network Watcher shows the per-region instance list with each region’s enablement state; the Flow logs blade under it enumerates every NSG flow log with its target storage account and retention setting, the two facts that decide what this free-looking service actually costs.