No Network Watcher Configured: Fixing Azure's Network Visibility Gap

When a connectivity issue or a suspicious traffic pattern hits your Azure environment, the first question is usually "what is actually happening on the wire?" Without Network Watcher, you cannot answer that. There are no flow logs to query, no connection troubleshooting, no packet captures. You are debugging blind. This Lensix check catches subscriptions where Network Watcher has never been turned on, which is more common than most teams expect because Azure does not always enable it for you.

---

What this check detects

The nsg_nonetworkwatcher check inspects an Azure subscription and reports whether a Network Watcher instance exists. Network Watcher is a regional service, so technically you need one per region where you run network resources. The check fails when no Network Watcher is present at all, which means none of the diagnostic and logging features it provides are available.

Historically, Azure auto-enabled Network Watcher when you created a virtual network in a region. Microsoft has since changed and clarified this behavior over time, and auto-enablement can be disabled at the subscription level. The result is that many subscriptions, especially older ones or ones created through automation, end up with no Network Watcher at all.

---

Why it matters

Network Watcher is the difference between knowing what your network is doing and guessing. Here is what you lose without it.

No flow logs means no traffic visibility

NSG flow logs and VNet flow logs record the IP traffic flowing through your network security groups and virtual networks: source and destination IPs, ports, protocols, and whether traffic was allowed or denied. These logs feed into Traffic Analytics and into your SIEM. Without Network Watcher, you cannot turn flow logs on, so a security investigation that depends on "who connected to this VM and when" has nothing to go on.

Incident response slows to a crawl

Picture a compromised VM exfiltrating data. With flow logs, you can see the outbound connections, the destination IPs, the data volume, and the time window. Without them, you are reconstructing the attack from VM-side logs alone, assuming those were not tampered with. The investigation takes hours longer and may never reach a confident conclusion.

Connectivity debugging becomes manual

Tools like IP flow verify and next hop tell you exactly why a packet is being dropped or where it is being routed. Without them, troubleshooting an NSG rule conflict or an unexpected route table entry turns into trial and error across multiple resources.

---

How to fix it

Enabling Network Watcher is cheap and low risk. The service itself has no charge; you only pay for the data that features like flow logs and Connection Monitor generate. The fix has two layers: enable Network Watcher in each region, then turn on the features you actually need (flow logs being the most important).

Option 1: Azure CLI

Create a Network Watcher in the regions you use. You can list your current ones first to see what is missing.

# List existing Network Watchers across the subscription
az network watcher list --query "[].{name:name, region:location}" -o table

# Enable Network Watcher in a specific region
az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled true

If the NetworkWatcherRG resource group does not exist, create it first. Azure conventionally places Network Watcher instances in a resource group with this name.

az group create --name NetworkWatcherRG --location eastus

To cover every region at once, loop over the regions you operate in:

for region in eastus westus2 northeurope; do
  az network watcher configure \
    --resource-group NetworkWatcherRG \
    --locations "$region" \
    --enabled true
done

Option 2: Azure Portal

1. Search for Network Watcher in the portal search bar and open it.
2. Select the Overview blade to see which regions have Network Watcher enabled.
3. For any disabled region, expand the subscription, find the region, and toggle it on. The portal manages the NetworkWatcherRG resource group for you.

Option 3: Terraform

If you manage infrastructure as code, declare the Network Watcher resource so it is created and tracked in state.

resource "azurerm_resource_group" "network_watcher" {
  name     = "NetworkWatcherRG"
  location = "eastus"
}

resource "azurerm_network_watcher" "eastus" {
  name                = "NetworkWatcher_eastus"
  location            = azurerm_resource_group.network_watcher.location
  resource_group_name = azurerm_resource_group.network_watcher.name
}

Turn on flow logs once Network Watcher exists

Enabling Network Watcher alone clears this check, but the real value comes from flow logs. Point them at a storage account and, ideally, a Log Analytics workspace for Traffic Analytics.

az network watcher flow-log create \
  --resource-group NetworkWatcherRG \
  --name myNsgFlowLog \
  --nsg myNsgName \
  --storage-account myStorageAccount \
  --enabled true \
  --retention 90 \
  --workspace myLogAnalyticsWorkspaceId \
  --traffic-analytics true

---

How to prevent it from happening again

Manually enabling Network Watcher in every region of every subscription does not scale. Use Azure Policy to make it the default and to catch any subscription that drifts.

Deploy Network Watcher with Azure Policy

Azure ships a built-in policy with a DeployIfNotExists effect that creates a Network Watcher in regions where one is missing. Assign it at the management group level so every current and future subscription inherits it.

# Find the built-in policy definition
az policy definition list \
  --query "[?contains(displayName, 'Network Watcher')].{name:name, displayName:displayName}" \
  -o table

# Assign it at a management group scope (DeployIfNotExists needs a managed identity)
az policy assignment create \
  --name "deploy-network-watcher" \
  --scope "/providers/Microsoft.Management/managementGroups/your-mg-id" \
  --policy "" \
  --location eastus \
  --mi-system-assigned \
  --role Contributor

Gate it in CI/CD

If you provision subscriptions or landing zones through pipelines, add a post-deployment check that fails the build when Network Watcher is absent. A small script in your pipeline does the job:

count=$(az network watcher list --query "length(@)")
if [ "$count" -eq 0 ]; then
  echo "No Network Watcher configured in subscription. Failing pipeline."
  exit 1
fi

Run a remediation task for existing resources

Policy assignments only evaluate new and updated resources by default. To bring existing subscriptions into line, trigger a remediation task after assigning the policy.

az policy remediation create \
  --name "remediate-network-watcher" \
  --policy-assignment "deploy-network-watcher" \
  --management-group "your-mg-id"

---

Best practices

• Enable it everywhere you have networks. Network Watcher is regional, so a single instance does not cover a multi-region deployment. Enable it in every region where you run VNets, not just your primary one.
• Treat flow logs as the actual goal. A Network Watcher with no flow logs satisfies this check but delivers little operational value. Enable flow logs and route them to Log Analytics so Traffic Analytics can surface anomalies.
• Set retention deliberately. Match flow log retention to your incident response window and compliance obligations. Ninety days is a reasonable baseline for most teams.
• Centralize the logging destination. Send flow logs to a dedicated, access-restricted storage account and a central Log Analytics workspace so your security team has one place to investigate.
• Enforce with policy, not documentation. A runbook that says "remember to enable Network Watcher" will be forgotten. A management-group policy assignment will not.

Network Watcher costs nothing to enable and turns a blind subscription into one you can actually investigate. The only real decision is how much flow log data you want to retain, not whether to turn it on.

Enable it, wire up flow logs, and lock it in with policy. Then the next time you are staring at a connectivity failure or a security alert, you will have the data to answer the question instead of guessing.