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: flow logs in storage accounts (virtual network flow logs, or NSG flow logs until their 2027 retirement) and connection monitor runs. ZopNight discovers each instance plus its flow logs and connection monitors, which 5 rules check.
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. The watcher instance itself is discovery-only, with no state to stop and no schedule to apply. Its billable exhaust is covered separately: flow logs and connection monitors are discovered as their own resource types, and five rules check them: RC-1399 (Traffic Analytics on the 10-minute interval), RC-1400 (duplicate flow logging), RC-1402 (a flow log on a gateway subnet), RC-1403 (a connection monitor with no surviving source), and RC-1404 (NSG flow logs past end-of-life). 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 flow log with its target storage account and retention setting, the two facts that decide what this free-looking service actually costs. NSG flow logs can no longer be created and retire on 30 September 2027; virtual network flow logs replace them, and ZopNight flags the remaining NSG ones with RC-1404.