Before diving into individual tools, we need a clear picture of the service, its purpose, and its limits.

The short definition

Azure Network Watcher is a collection of tools for monitoring, diagnosing, and recording the health of networks in Azure. A network, in this setting, is the set of virtual networks, subnets, network cards, routes, gateways, and security rules that let your virtual machines and other resources talk to each other, to the internet, and to your offices. Network Watcher does not carry your traffic. It watches, tests, explains, and records.

Microsoft describes it as a service aimed at infrastructure resources such as virtual machines, virtual networks, application gateways, and load balancers. It is not designed to monitor the inner workings of fully managed platform services, and it is not a tool for studying website visitors. Keeping this boundary in mind saves you from expecting answers the tool was never built to give.

Why it exists

Cloud networks are built from software, not from cables you can touch. You cannot walk to a server room and look at a blinking light. A rule written in one place can silently block traffic in another. A route added by one team can send packets into a black hole. A cloud network is therefore powerful but also invisible, and invisibility makes problems hard to solve. Network Watcher gives you the eyes and the instruments to make the invisible visible.

An important note about flow logs

Microsoft has announced that network security group flow logs will be retired on 30 September 2027. New network security group flow logs can no longer be created. Microsoft recommends moving to virtual network flow logs, which record similar information with broader and simpler coverage. After the retirement date, traffic analytics will no longer support network security group flow logs, and the flow log resources themselves will be deleted, although log files already stored in your storage accounts are not deleted and keep following their retention settings.

A handful of networking ideas appear in almost every Network Watcher conversation. Learn them once and the tools will make sense.

More words you will meet

Three further ideas are worth stating plainly. The first is the idea of being stateful. A network security group is stateful, which means that when it allows a request in one direction, it automatically allows the reply in the other direction. You do not need a second rule for the answer. This surprises many beginners who expect to write a rule for each direction.

The second is the difference between the data plane and the management plane. The data plane carries your real traffic. The management plane is where you create and change resources. Network Watcher tools mostly work on the management plane: they read rules and routes and compute what would happen, or they ask the platform to run a test. Only some tools, such as packet capture and connection monitor, observe real traffic on the data plane.

The third is the regional nature of the service. Network Watcher exists as one instance per region in each subscription. To use a tool on a virtual machine in a given region, you use the instance of Network Watcher in that same region. Azure turns it on automatically in a region when you create or update a virtual network there, and doing so does not change your resources or your charges.

Direction matters

Every flow has a direction. Inbound means traffic coming toward a resource, and outbound means traffic leaving it. A single conversation involves both, but the rules that apply are different in each direction. A web server needs an inbound rule that allows visitors to reach it and may also need an outbound rule that lets it call a database. Mixing up direction is one of the most frequent causes of rules that look right and still do nothing.

Now we look at the building blocks that make up Network Watcher and how they connect to the resources you already have.

The big picture

Network Watcher is not a single program you install. It is a regional service that reads the configuration of your network resources, runs tests through the Azure platform, and in some cases uses a small agent running on your virtual machines. Around it sit storage accounts that hold logs and captures, a log analytics workspace that holds analysed data, and the Azure Monitor service that draws charts and sends alerts.

flowchart TD
    U[You or automation] --> NW[Network Watcher regional instance]
    NW --> CFG[Reads rules and routes of your network]
    NW --> AG[Network Watcher agent on virtual machines]
    NW --> FL[Flow log settings]
    FL --> ST[Storage account with log files]
    ST --> TA[Traffic analytics]
    TA --> LA[Log Analytics workspace]
    NW --> CM[Connection monitor tests]
    CM --> LA
    LA --> AM[Azure Monitor charts and alerts]
        

The regional instance

Each region in a subscription can hold one Network Watcher resource. By default Azure places it in a special resource group created for the purpose, so that it does not clutter your own groups. You usually never touch it directly, but it is the anchor to which every tool attaches. If you ever opted out of automatic enablement, you must create it yourself in the regions where you want to use the tools.

The agent on the machine

Some tools need to run something inside the virtual machine. For these, Azure installs a small extension, often called the Network Watcher agent. It lets the platform ask the machine to send test traffic or to record packets. If the tool is started from the portal, the extension is normally added for you. If a tool complains about a missing agent, the fix is usually to install the extension on the machine, and to make sure the machine is running and can reach the Azure management services.

Storage for logs and captures

Flow logs, packet captures, and the output of some troubleshooting tools are saved in an Azure storage account. This account becomes part of your security surface, because the files may reveal who talked to whom or even the content of traffic. Access to it must be controlled just as carefully as access to a database.

The analytics layer

Raw flow log files are hard to read. Traffic analytics reads them, groups them, adds information such as location and known risky addresses, and saves the result in a log analytics workspace. Connection monitor also writes its results there. From the workspace you can run searches, draw charts, and set alerts.

Why regional design matters

Because Network Watcher works region by region, your design must think regionally too. A company with machines in three regions needs three regional instances, three sets of flow log settings, and a plan for where the data is stored. Keeping logs in the region where the traffic happens avoids extra transfer charges and often satisfies rules about where data may live. At the same time, security teams want to search everything together, which is why many organisations send analysed data from all regions into one central workspace. Decide this balance early, because moving large volumes of log data later is slow and costly.

Network Watcher groups its tools into monitoring, diagnostics, and traffic recording. Here is the full map before we study each tool in depth.

Three kinds of tools

It helps to sort the tools by how they work. Some tools, such as IP flow verify, next hop, effective security rules, and NSG diagnostics, are rule-reading tools. They read the configuration and work out what would happen. They are fast, free from side effects, and safe to run on production. Others, such as connection troubleshoot, connection monitor, and packet capture, are traffic-testing tools. They send or observe real packets and so show what really happens. A third group, flow logs and traffic analytics, are record-keeping tools that quietly write down what happened for later study.

Enablement, permissions, and cost

Network Watcher is switched on per region and subscription, usually automatically. To use the tools, a person or automation needs permission to read the network resources and to use the Network Watcher resource itself. Many organisations give this to the network team through a built-in role for network work, or through a custom role that lists exactly the allowed actions. For tools that save files, the person also needs the right to write to the chosen storage account.

Cost works differently for each tool. Enabling the service in a region costs nothing by itself. Some diagnostic tools are charged by the number of checks, connection monitor is charged by the number of tests, flow logs are charged by the volume of data they collect, and traffic analytics is charged by the amount of data it processes. On top of that you pay for the storage and workspace that hold the data. Prices change and vary, so always check the official pricing page before planning a large rollout.

flowchart LR
    P[Problem reported] --> Q{What kind of question}
    Q -->|Layout| T[Topology]
    Q -->|Allowed or blocked| R[IP flow verify and NSG diagnostics]
    Q -->|Wrong route| N[Next hop and effective routes]
    Q -->|Live reachability| C[Connection troubleshoot]
    Q -->|Health over time| M[Connection monitor]
    Q -->|Need the proof| K[Packet capture and flow logs]
        

Choosing your first three tools

New teams often feel overwhelmed by the number of tools. A practical starting point is to master three. Learn IP flow verify for blocked traffic, next hop for wrong routes, and connection troubleshoot for a quick combined verdict. These three cover a large share of everyday problems and need almost no setup. Once the team is comfortable, add connection monitor for the paths that matter most, then flow logs with analytics, and finally packet capture for the rare deep cases.

Before fixing anything, it helps to see the whole picture. These two tools give you a map and a fuel gauge.

Topology

The topology tool draws a diagram of your network resources and the relationships between them. It can show virtual networks, subnets, network interfaces, machines, gateways, load balancers, and peering links, across resource groups and even across subscriptions and regions that you can read. Instead of opening ten portal pages and trying to hold the layout in your head, you see it at once.

Topology is most useful in three situations. When you inherit an environment that nobody documented, it shows what actually exists. When you are about to change something, it shows what else might be affected. And during an incident, it helps you check whether the path you imagine between two machines is the path that exists.

What topology cannot tell you

A topology picture shows connections that exist, not traffic that flows or rules that allow it. Two machines may be drawn in the same virtual network and still be unable to talk because a security rule blocks them. Treat the map as the starting point for asking questions, not as proof that things work.

flowchart TD
    VNA[Virtual network Hub] --- VNB[Virtual network Spoke 1]
    VNA --- VNC[Virtual network Spoke 2]
    VNA --- GW[VPN gateway]
    GW --- OFF[Office network]
    VNB --- VM1[Web servers]
    VNC --- DB[Database servers]
    VNA --- FW[Firewall appliance]
        

Usage and quotas

Every subscription has limits on how many network resources it may create in each region: how many virtual networks, how many public addresses, how many network interfaces, how many security groups, and more. The usage and quotas page shows your current counts next to these limits. It is a fuel gauge for your network. Teams that ignore it often discover the limit on the worst possible day, when a deployment fails because the last public address was used.

Using the map together with documentation

A topology view is most valuable when it is paired with written knowledge. Add to each important diagram a short note about the purpose of every network, the team that owns it, and the traffic that is expected to cross each link. When an incident happens at night, the engineer on call sees both the picture and the story behind it. Over time, this combination also becomes the best training material for new colleagues, who can learn the estate by exploring a map instead of reading long documents.

When a connection fails, the cause is very often a security rule or a route. These tools read your configuration and tell you exactly which one.

How security rules are evaluated

To use the diagnostic tools wisely, you must understand how a network security group makes decisions. Every rule has a priority number, a direction, a source, a destination, a port range, a protocol, and an action of allow or deny. Rules are checked from the lowest priority number to the highest. The first rule that matches decides the result, and the checking stops there. Every group also contains built-in default rules at the bottom with very high numbers: they allow traffic inside the virtual network, allow traffic from the load balancer health probes, and deny other inbound traffic, while for outbound traffic they allow the virtual network and the internet and deny the rest.

A security group can be attached to the subnet, to the network interface of a machine, or to both. When both exist, inbound traffic is checked by the subnet group first and then by the interface group, and outbound traffic is checked by the interface group first and then by the subnet group. Traffic must be allowed at every stage to pass. This is the source of many puzzles: a rule that allows traffic on the interface is useless if the subnet group denies it earlier.

flowchart LR
    I[Internet or other network] --> SN[Subnet security group]
    SN -->|allowed| NIC[Interface security group]
    NIC -->|allowed| VM[Virtual machine]
    SN -->|denied| X1[Dropped]
    NIC -->|denied| X2[Dropped]
        

IP flow verify

IP flow verify answers one precise question: would a packet with these details be allowed or denied at this machine, and which rule decides? You choose the machine and its interface, then describe the packet: the direction, the protocol, the local port, the remote address, and the remote port. The tool evaluates the rules and returns allow or deny together with the name of the rule responsible. It is a quick way to turn “it does not work” into “rule number three hundred in the subnet group denies it”.

NSG diagnostics

NSG diagnostics goes a step further. It works with a described flow at a virtual machine, a scale set, or an application gateway, and shows every security group and every rule that applies to that flow, in order, with the result at each stage. It can also point out a higher-priority rule that would allow or deny the traffic, which is useful when you want to know the smallest change that would fix the problem. Because it shows the whole chain, it is the better choice when several groups are involved.

Effective security rules

Effective security rules shows the combined list of rules that apply to a network interface, merging the subnet group and the interface group in the order they take effect. It is the “show me everything” view. It is slower to read than IP flow verify, because you must scan the list yourself, but it is excellent for reviewing a machine and for spotting rules that are far broader than intended.

How routing decides

Routing is the second half of most puzzles. Azure creates default system routes so that machines in a virtual network can talk to each other and to the internet. You can add your own routes, called user-defined routes, and routes can also be learned from gateways connected to your offices. When several routes match a destination, the one with the most specific address range wins. This idea is called longest prefix matching. If two routes have the same range, a user-defined route beats a learned gateway route, and both beat a system route.

Each route points to a next hop of some type. The common types are the virtual network itself, the internet, a gateway, a network appliance such as a firewall, a service endpoint, and none, which means the traffic is deliberately dropped. Choosing none by mistake, or pointing a default route at an appliance that is switched off, is a classic way to lose all outbound traffic.

Next hop

The next hop tool tells you, for a given machine and destination address, which next hop type and address would be used and which route table supplied the choice. It is the fastest way to confirm that traffic really goes through your firewall, or to find the route that is sending it somewhere unexpected.

Reading results like an investigator

The output of a rule-reading tool is only as useful as the care taken in reading it. Always note the name of the rule that decided the result, the group it belongs to, and whether it is attached to a subnet or an interface. Ask why the rule exists. A rule with a vague name such as temporary access that is two years old is a red flag. Compare the rule’s source range with the addresses you actually expect. Overly broad ranges, such as any address on any port, are frequent causes of unwanted exposure, and the same investigation that solves a blocked connection often reveals rules that should be tightened.

Also remember that different Azure features can influence traffic before or after security groups. Firewalls placed in the path, central security rules defined at a larger scope, and routes that steer traffic through appliances all contribute. If the result from a tool does not match what you see in real life, widen your search to these other layers instead of doubting the tool.

When the rules look fine but things still fail, it is time to send real traffic or watch real packets.

Connection troubleshoot

Connection troubleshoot runs a one-time test from a source to a destination and reports what happened. The source can be a virtual machine, a scale set, an application gateway, or a Bastion host. The destination can be a machine, a host name, a web address, or an IP address. The tool reports whether the connection succeeded, how long it took, how many hops were involved, and where the problem lies if it failed, such as a security rule, a route, a stopped machine, or a port that nobody is listening on. For machines, it uses the Network Watcher agent to send the test traffic.

The strength of this tool is that it combines several checks into one answer. Instead of running IP flow verify, next hop, and a manual connection test separately, you ask a single question and receive a combined verdict. Its weakness is that it is a snapshot. A problem that comes and goes will not be caught unless it happens at the moment of the test, which is the reason connection monitor exists.

VPN troubleshoot

Many organisations connect their offices to Azure through virtual private network gateways. When such a link fails, the problem may lie in the gateway, in the settings on the office device, in a mismatch of security parameters, or in the internet path in between. VPN troubleshoot examines a gateway or a connection, checks its health, and writes diagnostic information to a storage account. It reports whether the gateway is healthy and gives hints about likely causes. It can run only one troubleshooting operation at a time per subscription, so coordinate with colleagues in a busy environment.

Packet capture

Packet capture is the microscope. It records the packets going into and out of a virtual machine or scale set, so that you can study them afterwards with a protocol analysis tool. You can set filters to record only certain protocols, addresses, and ports, and limits for how long to capture and how large the file may grow. The capture can be saved in a storage account, as a file on the machine, or both. It needs the Network Watcher agent on the machine, and each region has a generous limit on the number of capture sessions.

When packet capture earns its place

Practical tips for live tests

Before running a live test, confirm that the source machine is running and has the agent installed, that its operating system is healthy, and that you have permission to use the tool. Choose the destination port that the real application uses, not a convenient one. Run the test from the same place real users or services connect from. When a test fails, read the reported reason carefully; it often names the exact rule, route, or stopped service. When a test succeeds but the application still fails, the problem likely lies above the network layer, such as a wrong credential, an expired certificate, or an overloaded server.

A single test tells you about one moment. Connection monitor keeps testing, so you can see trends, find intermittent faults, and be warned before users complain.

What it does

Connection monitor sends test traffic at regular intervals between sources and destinations and records the results. Sources can be Azure virtual machines or machines in your own offices that run a monitoring agent. Destinations can be machines, host names, web addresses, or IP addresses, inside Azure, in other clouds, or on the internet. Each test measures whether the connection succeeded and how long a round trip took. Results are saved for charts and alerts.

The building blocks

There are documented limits on how large one monitor may grow. A region in a subscription can hold up to one hundred connection monitors, each can have up to twenty test groups and twenty test configurations, and up to one hundred sources and destinations. These limits are generous, but large estates should plan their structure rather than creating one monitor per machine.

flowchart LR
    S1[Web servers in Azure] --> T[Test group]
    S2[Office machine with agent] --> T
    T --> D1[Database in Azure]
    T --> D2[Payment service on internet]
    T --> D3[Partner site over VPN]
    T --> R[Results in workspace and metrics]
    R --> A[Alerts and dashboards]
        

Protocols and what they prove

Connection monitor can test using different methods, and each proves something different. A test using the basic echo protocol shows that a path exists and measures delay, but it proves nothing about the application. A test that opens a connection to a specific port proves that something is listening there. A test that makes a web request proves that the web service answers with an acceptable result. Choose the method that matches what you truly care about. For an important web service, a request test is far more meaningful than an echo test.

Reading the results

Two measures matter most. The percentage of failed checks shows how often the path breaks. The round trip time shows how fast it is. Watch both over days and weeks. A path that is always slightly slow, a path that is fast but fails one time in a hundred, and a path that gets slower every Monday morning each tell a different story and point to different causes. When a test fails, the tool also shows the path taken and can highlight the hop where trouble begins, which turns a vague complaint into a specific place to look.

Designing tests that reflect real use

A test is only as good as its resemblance to real traffic. If users reach a web service over a certain port with a certain protocol, test exactly that. If the application depends on a name lookup, include the name rather than a raw address so that name resolution problems are caught too. Place the source where real clients are: a test from a machine in the same subnet as the server proves little about how an office user experiences the service. Use several sources in different places for the most important destinations, so that a problem affecting only one route can be separated from a problem affecting everyone.

Finally, treat monitors as living objects. When a server moves, a service gets a new address, or a partner changes its endpoint, the test must change with it. Otherwise the dashboard will show a red alarm for a retired destination or, worse, a green light for a path nobody uses any more.

Flow logs keep the history of your network conversations. Traffic analytics turns that history into insight.

What a flow log records

A flow log writes down information about the IP traffic passing through a part of your network. For each flow it records the source and destination addresses and ports, the protocol, the direction, and whether the traffic was allowed or denied by the rules. Over time it also records how many packets and bytes were exchanged. It does not record the content of the conversation. You learn who talked to whom and how much, not what they said.

The files are written as structured text, saved in a storage account in time-ordered folders, and kept for a retention period that you set. The raw files are meant for machines to read, which is why most people use them through traffic analytics or a search tool rather than by opening them one by one.

Network security group flow logs and virtual network flow logs

The older kind of flow log is attached to a network security group. It records only the traffic that the group’s rules evaluated, so its coverage depends on where groups are attached. The newer kind is attached to a virtual network, a subnet, or a network interface, and records traffic for everything in that scope. This makes coverage simpler to reason about: switching it on for a virtual network covers the resources in that network, without the need to enable logging group by group.

Traffic analytics

Traffic analytics reads the flow log files at regular intervals, groups the records, enriches them with information such as the geographic location of addresses and whether an address is known to be risky, and writes the result to a log analytics workspace. It then offers dashboards that show the busiest talkers, the most used ports, traffic between regions and virtual networks, the share of allowed and blocked traffic, and flows to or from suspicious places. It is a powerful way to spot misconfigurations, unexpected data flows, and possible attacks.

flowchart LR
    V[Virtual network traffic] --> FL[Flow log]
    FL --> ST[Storage account files]
    ST --> TA[Traffic analytics processing]
    TA --> LA[Log Analytics workspace]
    LA --> DB[Dashboards and maps]
    LA --> AL[Alerts and searches]
        

What you can learn from the data

Reading flow records with care

Flow data has a few quirks that beginners should know. A long conversation may produce several records over time, so the same flow can appear more than once as it continues. Byte and packet counts are totals for an interval, not for the whole conversation. Allowed and denied decisions are recorded where the rule was applied, which matters when several groups are involved. And flow logs are about the network layer, so they cannot tell you which user or application was behind a connection without extra information from other systems. Joining flow data with inventory data, such as which machine owns which address, makes the records far more useful.

Choosing between raw files and analytics

Raw files in storage are cheap to keep for long periods and are the right source for deep forensic work or for loading into other analysis systems. Traffic analytics is quicker for everyday questions and dashboards but adds processing cost and keeps data in a workspace with its own retention rules. Many organisations use both: analytics for fresh data over a few weeks or months, and raw files for long-term archive. Decide which questions each source will answer, and set retention separately for each so that you do not pay twice for the same history.

Let us follow what happens behind the scenes when you run a diagnostic tool, record a flow, or keep a monitor running for months.

The life of a diagnostic request

When you ask a tool such as IP flow verify for an answer, the request travels to the Network Watcher instance in the region of the machine. The service reads the current configuration of the machine’s network interface, subnet, security groups, and routes, then computes the outcome and returns it. No traffic is sent, and nothing on your machine changes. When you ask connection troubleshoot or packet capture for help, the service also contacts the agent on the machine, which performs the test or captures packets and returns the results or saves them in storage.

sequenceDiagram
    participant U as You
    participant NW as Network Watcher
    participant CFG as Network configuration
    participant AG as Agent on machine
    participant ST as Storage account
    U->>NW: Ask for a check
    NW->>CFG: Read rules and routes
    CFG-->>NW: Current settings
    NW->>AG: Run live test if tool needs it
    AG-->>NW: Test results
    NW->>ST: Save output for captures and logs
    NW-->>U: Verdict and details
        

The life of a flow record

The life of the setup itself

Delays you should expect

Not every tool answers instantly. Rule-reading tools respond within seconds. Live tests take a little longer because they wait for the agent. Flow log files are written in batches, so there is a delay between traffic happening and the record appearing in storage, and traffic analytics adds another delay while it processes the files. For this reason, flow logs are excellent for investigation and trends but are not a real-time alarm system. For fast detection of a broken path, rely on connection monitor, and use flow logs to explain what happened afterwards.

The tools that help you see everything are themselves powerful. Handle them with the care you give to any system that touches sensitive information.

Who may do what

Access is controlled through roles. Reading topology and running rule-reading tools is a low-risk activity and can be given to a wider group of engineers. Starting packet captures, creating flow logs, changing monitors, and reading storage accounts that hold logs are higher-risk activities and should be limited to a small, named group. Use built-in network roles where they fit, and create custom roles when you need to grant only specific actions. Separate the people who can change network rules from the people who can delete logs, so that an attacker or a careless colleague cannot cover their tracks.

Protecting the data you collect

Governance with policy

In large organisations, relying on individuals to remember to switch on logs will always leave gaps. Azure Policy can check that every virtual network has a flow log, and in some cases it can create one automatically. It can also check that logs go to approved storage accounts, use approved retention, and send data to the right workspace. Policy turns a good intention into an enforced standard, and it is the natural way to roll out virtual network flow logs at scale.

Separating duties

Good governance separates the people who build the network from the people who watch it. If one person can change a rule, switch off the log that would show the change, and delete the stored history, nobody can prove what happened. Give the network team the power to manage rules and routes, give the security team read access to logs and the power to protect them, and give a small independent group the power to change retention. This separation costs little and greatly improves trust in your records.

Tools are only useful when they are used in a sensible order. Here are playbooks for the symptoms people report most often.

A general method

Good troubleshooting is a habit, not a talent. Describe the problem exactly. Draw the path. Test layer by layer from the simplest to the most detailed. Change one thing at a time. Write down what you learned. Following the same method every time makes you faster and keeps a team consistent, even when the person on call is tired.

flowchart TD
    A[Symptom reported] --> B[Write down source destination port protocol]
    B --> C[Look at topology for the path]
    C --> D[Check security rules at both ends]
    D --> E[Check routes in both directions]
    E --> F[Run connection troubleshoot]
    F --> G{Still unclear}
    G -->|Yes| H[Review flow logs and run a filtered packet capture]
    G -->|No| I[Fix one thing and retest]
    H --> I
        

Playbook cards for common symptoms

After the incident: making the fix last

Solving a problem is only half the job. Once the service is back, hold a short review. Which tool found the cause, and how long did that take? Was there a monitor that should have warned you earlier? Was the runbook helpful, and what was missing? Update the runbook, adjust the alerts, and where possible add a policy or template change that prevents the same mistake in other places. Teams that improve their tools after each incident gradually reduce both the number and the length of incidents, which is the real return on investing in visibility.

Network Watcher is itself a source of measurements. This chapter shows how to turn those measurements into early warnings.

The signals available

Alerts that people trust

An alert that fires too often teaches people to ignore it. Design alerts with care. Base thresholds on real history, not guesses. Require a condition to persist for a few minutes before alerting so that a single lost packet does not wake anyone. Send each alert to a named owner and attach a short note explaining what it means and what to check first. Review alerts monthly and remove the ones that never lead to action.

Dashboards for different audiences

Different people need different views. An operations team needs a live view of path health and recent changes. A security team needs a view of exposure, blocked flows, and traffic to risky places. A finance or architecture team needs a view of the largest flows between regions and out to the internet, since these drive cost. Build separate dashboards instead of one crowded page, and agree who owns each.

Learning the normal pattern

Networks have rhythms. Traffic rises on weekday mornings, drops overnight, and jumps at month end. An alert threshold that ignores these rhythms either fires every morning or misses real problems at night. Spend a few weeks collecting data, look at each hour of each weekday, and set thresholds that respect the pattern. Where the tools support it, use alerts that learn normal behaviour automatically. Revisit the thresholds after big changes such as a new application launch or a network redesign.

With network security group flow logs scheduled to retire on 30 September 2027, every team that depends on them needs a plan.

What changes at retirement

After the retirement date, Azure stops supporting traffic analytics for network security group flow logs and deletes the flow log resources that remain in your subscriptions. New network security group flow logs can no longer be created. Importantly, the log files already written to your storage accounts are not deleted and continue to follow the retention rules you configured. This means history is preserved, but nothing new will be recorded by the old mechanism, and dashboards fed by it will stop updating.

flowchart TD
    A[Inventory existing NSG flow logs] --> B[Decide target scope for new logs]
    B --> C[Plan storage retention and workspace]
    C --> D[Choose migration route]
    D --> E[Migration script for mixed setups]
    D --> F[Azure Policy for uniform setups]
    E --> G[Review analysis report and confirm]
    F --> G
    G --> H[Verify new logs are writing]
    H --> I[Update dashboards and alerts]
    I --> J[Disable and delete old NSG flow logs]
        

Two migration routes

Microsoft describes two approaches, and the right one depends on how uniform your setup is.

Planning decisions

Lessons teams commonly learn

Teams that have completed the move often report the same lessons. Inventory takes longer than expected because settings were created by many people over many years. Dashboards and alerts built on the old data need more rebuilding than the logs themselves. Storage and workspace costs shift, so budgets need review. And the best results come when the migration is treated as a chance to simplify: fewer storage accounts, clearer ownership, and logging scopes that match the way the network is really organised.

A pattern is a proven way to use a tool. An anti-pattern is a tempting habit that causes trouble later.

Patterns worth adopting

flowchart LR
    SP1[Spoke 1 workloads] -->|tests| HUB[Hub shared services]
    SP2[Spoke 2 workloads] -->|tests| HUB
    HUB -->|tests| OFF[Office over VPN]
    HUB -->|tests| EXT[External partner service]
    SP1 -.-> FL[Flow logs to central storage]
    SP2 -.-> FL
    HUB -.-> FL
    FL --> AN[Central analytics workspace]
        

Anti-patterns to avoid

This chapter collects the habits that separate calm network operations from endless firefighting.

Best practices by area

Common mistakes and how to avoid them

A launch checklist for a new environment

Building team skill

Tools only help when people know how to use them. Run a short training that walks through a staged problem, such as a blocked port caused by a subnet rule, a wrong route caused by a new appliance, and a flaky link revealed by connection monitor history. Let engineers practise each tool on a safe practice environment. Share a one-page cheat sheet that states which tool answers which question. Encourage engineers to write down what they learned in simple notes. A team that practises together solves real incidents faster and with less stress.

Every tool has a price in money, effort, and attention. Here we weigh what Network Watcher gives you against what it asks in return.

How the bill is made

Turning on Network Watcher in a region costs nothing by itself. Charges come from what you use. Some diagnostic tools are charged by the number of checks. Connection monitor is charged by the number of tests it runs. Flow logs are charged by the amount of data they collect, and traffic analytics by the amount of data it processes. On top of these, you pay for the storage that holds log files and captures, and for the workspace where analysed data lives. Prices change and differ between regions, so use the official pricing page and calculator for real numbers and avoid quoting old figures in business cases.

Ways to spend less without losing visibility

A worked cost-thinking example

Imagine a company with three environments: a customer-facing production network, an internal business network, and a developer sandbox. A careless design enables the highest level of logging, analytics, and testing everywhere. A thoughtful design asks what each needs. Production gets full flow logging with analytics, longer retention for security evidence, and connection monitor tests on its critical paths. The internal network gets flow logging with a shorter retention and fewer tests. The sandbox gets minimal logging, enough to investigate abuse, and the diagnostic tools on demand. The savings come from matching effort to risk, not from switching tools off blindly.

The hidden cost of not looking

It is easy to count the money spent on logs and tests and forget the cost of having none. Hours lost to guessing during an outage, security incidents found weeks late, unexplained network bills, and failed audits all have a price, often far larger than the monthly charge for visibility. A balanced view compares the cost of the tools with the cost of the problems they prevent or shorten. Seen this way, a well-designed monitoring and logging setup is usually an inexpensive insurance policy.

Here are five everyday situations that show how the tools fit together. The names are illustrative, not real customers.

flowchart TD
    A[Slow checkout on Fridays] --> B[Connection monitor shows partner path slower]
    B --> C[Traffic analytics shows large export job]
    C --> D[Job moved to quiet hours]
    D --> E[Alert added for same pattern]
        

When another service may be a better fit

Network Watcher is not the answer to every question. If you need to understand the inner behaviour of a platform service, the service’s own diagnostics will tell you more. If you need to inspect and filter traffic through deep rules, a firewall service with its own logs is the right tool. If you need to understand how real users experience a website, an application monitoring service gives better answers. Choosing the right tool for each question is part of good architecture.

Short answers to the questions teams ask most often.

Usually not. It is switched on automatically in a region when you create or update a virtual network there, at no extra charge. Some tools need an agent on the machine, which the portal normally installs when you start them.

No. It tells you whether security rules would allow or deny a packet. Firewalls, appliances, operating system settings, and the application can still block it, so follow with a live test.

Connection troubleshoot runs a one-time test and explains the result. Connection monitor runs tests repeatedly, stores results, and lets you see trends and set alerts.

No. They record who talked to whom, on which ports and protocol, how much data moved, and whether the traffic was allowed or denied. To see content you would need packet capture, which must be used carefully.

It reads flow logs, enriches them with information such as location and known risky addresses, and saves the result in a workspace, where dashboards and searches show patterns and possible problems.

Yes. Microsoft has announced retirement on 30 September 2027, and new ones can no longer be created. Existing log files in storage are not deleted. Microsoft recommends virtual network flow logs, so plan your migration and confirm dates on the official page.

Use the migration script for mixed or partial setups, or Azure Policy for uniform setups. Review the analysis, pilot first, verify the new logs and analytics, and then remove the old ones.

It is designed for infrastructure resources such as machines, virtual networks, application gateways, and load balancers, not for the internals of fully managed platform services. Use the service’s own monitoring for those.

A small, trained group. Captures may contain sensitive data, so restrict access, use filters and short limits, store files securely, and delete them after use.

Automatic enablement may have been turned off, so the regional instance was never created. Enable Network Watcher in that region and try again.

Scope logs to where they matter, set retention to need, test fewer and better paths, delete old captures and unused monitors, and review the bill every quarter.

Confirm Network Watcher is enabled, create flow logs with secure storage and a workspace, add connection monitor tests on the critical paths, set a few trusted alerts, and write a short runbook.

Azure Network Watcher gives you the eyes and instruments to understand a network you cannot touch. Topology draws the map. Rule-reading tools explain which security rule or route decides an outcome. Connection troubleshoot and packet capture send or observe real traffic. Connection monitor keeps testing important paths and shows trends. Flow logs and traffic analytics keep a durable record of who talked to whom. Used in a sensible order, and guarded with proper security and governance, these tools turn long guessing sessions into short, clear investigations. And because network security group flow logs are scheduled to retire on 30 September 2027, every team that relies on them should plan, pilot, and complete the move to virtual network flow logs well before that date.