{"id":477,"date":"2026-04-14T04:50:47","date_gmt":"2026-04-14T04:50:47","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-network-watcher-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/"},"modified":"2026-04-14T04:50:47","modified_gmt":"2026-04-14T04:50:47","slug":"azure-network-watcher-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-network-watcher-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/","title":{"rendered":"Azure Network Watcher Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Management and Governance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Management and Governance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure Network Watcher is Azure\u2019s native network monitoring and diagnostics service for virtual networks. It helps you understand, diagnose, and gain visibility into network traffic, routing, and connectivity issues inside Azure networking.<\/p>\n\n\n\n<p>In simple terms: <strong>Azure Network Watcher tells you what the network is doing and why<\/strong>\u2014whether a VM can (or cannot) reach another endpoint, which route is being used, whether an NSG rule is blocking traffic, and what flows are actually traversing your network.<\/p>\n\n\n\n<p>Technically, Azure Network Watcher is a <strong>regional service<\/strong> that provides a set of tools (connectivity tests, packet capture, NSG flow logs, topology views, routing diagnostics, and VPN troubleshooting) that interact with Azure networking resources such as VNets, NICs, NSGs, route tables, and VPN gateways. It integrates with Azure Monitor and Log Analytics for alerting, visualization, and long-term analysis.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> network problems are often the hardest to troubleshoot in cloud environments because the \u201cnetwork\u201d is a mix of distributed components (NSGs, routes, DNS, NAT, firewalls, private endpoints, gateways). Azure Network Watcher provides first-party, Azure-aware diagnostics so you can troubleshoot faster, reduce downtime, and improve governance over network operations.<\/p>\n\n\n\n<blockquote>\n<p>Naming and lifecycle note (verify in official docs for the latest): <strong>Azure Network Watcher is an active service<\/strong>. Some experiences within it have evolved over time (for example, \u201cConnection Monitor\u201d has newer versions, and older \u201cclassic\u201d monitoring experiences have been retired or deprecated). When using this tutorial, always prefer the latest workflow shown in Azure\u2019s official documentation.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Network Watcher?<\/h2>\n\n\n\n<p><strong>Official purpose:<\/strong> Azure Network Watcher is designed to <strong>monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what it does)<\/h3>\n\n\n\n<p>Azure Network Watcher commonly provides:\n&#8211; <strong>Connectivity diagnostics<\/strong> (why a connection succeeds or fails)\n&#8211; <strong>Traffic flow logging<\/strong> (NSG flow logs)\n&#8211; <strong>Network topology visualization<\/strong> (resource relationship mapping)\n&#8211; <strong>Routing diagnostics<\/strong> (effective routes, next-hop checks)\n&#8211; <strong>Security rule evaluation<\/strong> (IP flow verify, security group view)\n&#8211; <strong>Deep packet-level capture<\/strong> (packet capture on supported VMs)\n&#8211; <strong>VPN troubleshooting<\/strong> (for supported VPN gateway scenarios)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (how it\u2019s organized)<\/h3>\n\n\n\n<p>In practice, you\u2019ll interact with Azure Network Watcher through:\n&#8211; <strong>Azure Portal<\/strong> (Network Watcher blade)\n&#8211; <strong>Azure CLI \/ PowerShell<\/strong> (network watcher commands)\n&#8211; <strong>Azure Resource Manager (ARM)<\/strong> APIs (management-plane operations)\n&#8211; <strong>Regional Network Watcher resource<\/strong> that Azure creates\/uses (often visible in a <code>NetworkWatcherRG<\/code> resource group in the region)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service category fit:<\/strong> Although it\u2019s closely tied to networking, Azure Network Watcher is also a key <strong>Management and Governance<\/strong> tool because it supports operational governance: troubleshooting, logging, auditing network changes, and enforcing visibility standards across environments.<\/li>\n<li><strong>Type:<\/strong> Primarily a <strong>management-plane diagnostic service<\/strong> that orchestrates data collection from networking resources and agents\/extensions on VMs for certain features.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional vs global<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional service:<\/strong> Azure Network Watcher is <strong>enabled per region<\/strong>. If you troubleshoot resources in multiple Azure regions, you typically ensure Network Watcher is enabled in each of those regions.<\/li>\n<li><strong>Subscription context:<\/strong> It operates within the context of a subscription (and the resources you have access to via RBAC).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Azure ecosystem<\/h3>\n\n\n\n<p>Azure Network Watcher complements and integrates with:\n&#8211; <strong>Azure Virtual Network (VNet)<\/strong>, <strong>NICs<\/strong>, <strong>NSGs<\/strong>, <strong>route tables<\/strong>, <strong>Private Endpoints<\/strong>\n&#8211; <strong>VPN Gateway<\/strong> (and certain gateway diagnostic scenarios)\n&#8211; <strong>Azure Monitor \/ Log Analytics<\/strong> for querying and alerting on logs\n&#8211; <strong>Azure Storage<\/strong> (common destination for NSG flow logs and packet captures)\n&#8211; <strong>Microsoft Sentinel<\/strong> (optional downstream consumption of logs, depending on your logging architecture)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure Network Watcher?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce downtime and MTTR:<\/strong> Faster root cause analysis for network incidents.<\/li>\n<li><strong>Improve service reliability:<\/strong> Proactive monitoring (for example, continuous connection monitoring) can detect degradations before users report them.<\/li>\n<li><strong>Operational standardization:<\/strong> Establish repeatable troubleshooting and logging patterns across teams and subscriptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure-aware diagnostics:<\/strong> The tools understand Azure networking objects (NSGs, UDRs, NAT behavior, gateways).<\/li>\n<li><strong>Pinpoint \u201cwhere it broke\u201d:<\/strong> Identify whether failure is due to NSG rules, routing, DNS resolution, or unreachable next hop.<\/li>\n<li><strong>Evidence-driven troubleshooting:<\/strong> Flow logs and packet capture provide concrete proof rather than assumptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Self-service for platform teams:<\/strong> Provide engineers a consistent diagnostic toolkit.<\/li>\n<li><strong>Integrates with runbooks:<\/strong> CLI\/PowerShell support enables automation in incident response.<\/li>\n<li><strong>Supports governance:<\/strong> Enabling consistent logging (like NSG flow logs) supports audits and investigations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Network forensics:<\/strong> Flow logs help investigate suspicious traffic patterns and policy violations.<\/li>\n<li><strong>Change validation:<\/strong> Verify the effect of NSG\/route changes without waiting for user impact.<\/li>\n<li><strong>Segmentation assurance:<\/strong> Validate that segmentation rules actually block prohibited traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Designed for cloud scale:<\/strong> Continuous monitoring and logging can scale across many VNets and workloads (with careful cost control).<\/li>\n<li><strong>Targeted deep dives:<\/strong> Packet capture is available when you need detail, rather than always-on full capture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Azure Network Watcher when you need:\n&#8211; Repeatable network troubleshooting for Azure IaaS and hybrid networking\n&#8211; NSG flow visibility for detection, investigation, and governance\n&#8211; Connection monitoring between endpoints (Azure-to-Azure and potentially hybrid, depending on your design)\n&#8211; A first-party approach aligned with Azure RBAC and resource model<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives or complements when:\n&#8211; You need <strong>full NPM\/APM<\/strong> across applications (use Azure Monitor Application Insights or third-party APM)\n&#8211; You need <strong>full network IDS\/IPS<\/strong> or advanced L7 inspection (consider Azure Firewall, third-party NVA, or dedicated security tooling)\n&#8211; Your environment is mostly <strong>PaaS-only<\/strong> with minimal VNets\/NSGs (you may rely more on service-specific diagnostics and Azure Monitor)\n&#8211; You require <strong>long-term, centralized SIEM correlation<\/strong>: Network Watcher is a source; Sentinel\/SIEM is the analysis plane<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Network Watcher used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Common in any industry operating regulated or mission-critical networks:\n&#8211; Finance and insurance (segmentation, auditability)\n&#8211; Healthcare (compliance logging, incident investigations)\n&#8211; Retail\/e-commerce (availability and performance)\n&#8211; SaaS providers (multi-tenant segmentation and operational monitoring)\n&#8211; Public sector (governance, audit trails)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud platform teams managing shared networking<\/li>\n<li>SRE\/operations teams responding to incidents<\/li>\n<li>Security engineering and SOC teams investigating network events<\/li>\n<li>DevOps teams validating connectivity for deployments<\/li>\n<li>Network engineers extending on-prem patterns into Azure<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hub-and-spoke VNets with centralized firewalls<\/li>\n<li>Multi-region active-active or active-passive designs<\/li>\n<li>Hybrid connectivity (VPN\/ExpressRoute plus on-prem DNS)<\/li>\n<li>Microsegmented environments using NSGs and UDRs<\/li>\n<li>Kubernetes clusters (AKS) that depend on underlying VNet routing and security (note: some diagnostics are at VM\/NIC\/NSG level; interpret accordingly)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Continuous connection monitoring, NSG flow logs to a centralized logging account, alerting on failures<\/li>\n<li><strong>Dev\/test:<\/strong> Ad-hoc troubleshooting during provisioning, validating NSG rules, debugging routes during lab builds<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Azure Network Watcher is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Diagnose \u201cVM can\u2019t reach VM\u201d inside a VNet<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Two VMs in the same VNet can\u2019t connect on a specific port.<\/li>\n<li><strong>Why it fits:<\/strong> Connection troubleshoot + IP flow verify can quickly isolate NSG\/routing issues.<\/li>\n<li><strong>Example:<\/strong> App VM can\u2019t reach DB VM on TCP 1433 after an NSG change.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Validate NSG rules before and after deployments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Engineers deploy new rules but aren\u2019t sure which rule will match traffic.<\/li>\n<li><strong>Why it fits:<\/strong> IP flow verify and security group view help confirm effective security rules.<\/li>\n<li><strong>Example:<\/strong> Confirm that only the load balancer subnet can reach backend VMs on port 443.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Capture packets to debug intermittent TCP resets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Users see timeouts or resets, but logs aren\u2019t conclusive.<\/li>\n<li><strong>Why it fits:<\/strong> Packet capture provides packet-level evidence (SYN\/SYN-ACK, retransmits, resets).<\/li>\n<li><strong>Example:<\/strong> A Linux VM intermittently fails to establish TLS sessions to an internal API.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Audit traffic patterns with NSG flow logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need to know which sources are talking to a subnet and on which ports.<\/li>\n<li><strong>Why it fits:<\/strong> NSG flow logs provide structured flow telemetry for investigation and baselining.<\/li>\n<li><strong>Example:<\/strong> Detect unexpected inbound attempts on SSH from unapproved source ranges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Confirm routing and next hop after UDR changes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Routing changes accidentally send traffic to the wrong appliance or blackhole.<\/li>\n<li><strong>Why it fits:<\/strong> Next hop and effective routes show the chosen path.<\/li>\n<li><strong>Example:<\/strong> After adding a default route to a firewall, a subnet loses access to Azure services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Troubleshoot VPN connectivity issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> On-premises can\u2019t reach Azure subnets through VPN.<\/li>\n<li><strong>Why it fits:<\/strong> VPN troubleshoot can help identify common tunnel and configuration issues.<\/li>\n<li><strong>Example:<\/strong> A site-to-site VPN drops after an on-prem network device update.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Continuous monitoring of critical dependencies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need early warning if a critical service becomes unreachable.<\/li>\n<li><strong>Why it fits:<\/strong> Connection Monitor supports continuous tests and integration with alerts (via Azure Monitor).<\/li>\n<li><strong>Example:<\/strong> Monitor connectivity between web tier and database tier across regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Validate segmentation in hub-and-spoke environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Must prove that spokes are isolated except through shared services.<\/li>\n<li><strong>Why it fits:<\/strong> IP flow verify, next hop, and flow logs help validate and document segmentation.<\/li>\n<li><strong>Example:<\/strong> Ensure Spoke-A cannot reach Spoke-B directly, only via firewall.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Investigate suspected data exfiltration paths<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Security suspects a VM is sending data to an unauthorized destination.<\/li>\n<li><strong>Why it fits:<\/strong> NSG flow logs and connection monitoring help confirm egress paths and destinations.<\/li>\n<li><strong>Example:<\/strong> A workload unexpectedly initiates outbound connections to unknown IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Troubleshoot DNS-related connectivity symptoms (indirectly)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> \u201cConnection fails\u201d but root cause is name resolution.<\/li>\n<li><strong>Why it fits:<\/strong> Connection troubleshooting workflows can reveal whether failure is at DNS vs network.<\/li>\n<li><strong>Example:<\/strong> App can reach an IP directly but fails when using hostname after DNS changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Validate Private Endpoint and NSG\/UDR interactions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Private Endpoint traffic doesn\u2019t behave as expected; access is denied.<\/li>\n<li><strong>Why it fits:<\/strong> Effective security rules and route diagnostics clarify whether traffic is blocked.<\/li>\n<li><strong>Example:<\/strong> Private Endpoint access fails from a locked-down subnet with strict NSGs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Standardize incident runbooks for network triage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different engineers troubleshoot differently, wasting time.<\/li>\n<li><strong>Why it fits:<\/strong> Network Watcher provides consistent tools that can be embedded in runbooks.<\/li>\n<li><strong>Example:<\/strong> \u201cTier-1 network triage\u201d checklist using next hop + IP flow verify + test connectivity.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section lists key Azure Network Watcher features commonly available in current Azure deployments. Availability and exact UI naming can change\u2014verify in official docs for your region and subscription.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network topology<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Visualizes network resources and their relationships (VNets, subnets, NICs, NSGs, route tables, gateways).<\/li>\n<li><strong>Why it matters:<\/strong> Helps quickly understand \u201cwhat\u2019s connected to what.\u201d<\/li>\n<li><strong>Practical benefit:<\/strong> Faster onboarding and troubleshooting\u2014especially in shared hub-and-spoke networks.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Topology is a view, not a source of truth for traffic flows; it shows resource relationships, not packet paths.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Connection Monitor (connectivity monitoring)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Continuously monitors connectivity between endpoints and collects latency\/availability metrics; can integrate with alerting.<\/li>\n<li><strong>Why it matters:<\/strong> Moves teams from reactive troubleshooting to proactive detection.<\/li>\n<li><strong>Practical benefit:<\/strong> Detect dependency failures between tiers (web \u2192 API \u2192 DB), across subnets\/regions\/hybrid (depending on endpoint type and agent support).<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Often requires an agent\/extension on VMs for certain endpoint types; monitor design affects cost and data volume.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Connection troubleshoot \/ Test connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Performs on-demand connectivity checks between a source and destination and provides diagnostic output (reachable\/unreachable, hops, potential blocking).<\/li>\n<li><strong>Why it matters:<\/strong> Quickly answers \u201cis it network or not?\u201d<\/li>\n<li><strong>Practical benefit:<\/strong> Identifies NSG\/UDR issues without manually correlating rules and routes.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Some checks require VM agent\/extension; results are point-in-time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IP flow verify<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Validates whether traffic (5-tuple) is allowed or denied by NSG rules for a VM NIC at a given time.<\/li>\n<li><strong>Why it matters:<\/strong> NSG rule evaluation is one of the most common causes of connectivity issues.<\/li>\n<li><strong>Practical benefit:<\/strong> Pinpoints the exact NSG rule (allow\/deny) affecting traffic.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Focused on NSG evaluation; doesn\u2019t prove the remote endpoint is listening or that routing is correct.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Next hop<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Shows the next hop type and IP for traffic from a VM to a destination, based on effective routes.<\/li>\n<li><strong>Why it matters:<\/strong> Routing surprises are common in hub-and-spoke networks with UDRs.<\/li>\n<li><strong>Practical benefit:<\/strong> Confirms whether traffic is going to Internet, a virtual appliance, a gateway, or staying within VNet.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Again, route choice isn\u2019t the same as end-to-end success; downstream devices can still drop traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Effective routes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Displays the effective route table applied to a NIC, including system routes and user-defined routes (UDRs).<\/li>\n<li><strong>Why it matters:<\/strong> Many outages come from unintended route propagation or UDR mistakes.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables deterministic verification of routing behavior.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Must interpret with knowledge of peering, gateways, and appliance routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security group view (effective NSG rules)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Shows the effective inbound\/outbound security rules applied to a NIC from associated NSGs.<\/li>\n<li><strong>Why it matters:<\/strong> Multiple NSGs (subnet + NIC) can make effective policy unclear.<\/li>\n<li><strong>Practical benefit:<\/strong> Quickly review the rules that actually apply.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Effective rules are still just rules; they don\u2019t validate remote service health.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">NSG flow logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Logs network flows that pass through an NSG, typically to a storage account; optionally integrated into broader log analytics pipelines.<\/li>\n<li><strong>Why it matters:<\/strong> Provides network visibility and supports investigations.<\/li>\n<li><strong>Practical benefit:<\/strong> Audit traffic patterns, detect anomalies, and validate segmentation.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Can generate large volumes; requires careful retention, storage security, and cost management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Packet capture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Captures packets on a VM (often via a Network Watcher agent\/extension) and stores captures for analysis.<\/li>\n<li><strong>Why it matters:<\/strong> When logs and flow summaries aren\u2019t enough, packets provide ground truth.<\/li>\n<li><strong>Practical benefit:<\/strong> Diagnose TCP handshakes, MTU issues, retransmissions, and TLS negotiation problems.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Sensitive data risk; capture files can be large; requires strict access control and short retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPN troubleshoot (for supported VPN Gateway scenarios)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Helps diagnose VPN tunnel connectivity issues using Azure-side diagnostics.<\/li>\n<li><strong>Why it matters:<\/strong> Hybrid connectivity is business-critical and often complex.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster isolation of misconfigurations and tunnel state issues.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Not a replacement for on-prem device logs; scenario coverage varies\u2014verify support for your gateway type and configuration.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Azure Network Watcher is a <strong>regional orchestration service<\/strong> that:\n1. Uses Azure control-plane APIs to inspect network configuration (NSGs, routes, NICs).\n2. For certain features (packet capture, continuous connection monitoring), coordinates with an <strong>agent\/VM extension<\/strong> to collect data from the guest\/host boundary.\n3. Stores outputs in <strong>Azure Storage<\/strong> and\/or <strong>Log Analytics<\/strong> depending on the feature and your configuration.\n4. Surfaces results via Portal, CLI\/PowerShell, and APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> You request a diagnostic action (e.g., next hop) \u2192 Network Watcher queries Azure networking configuration \u2192 returns results.<\/li>\n<li><strong>Data plane (logging):<\/strong> NSG flow logs and packet captures generate data \u2192 written to storage\/log destinations \u2192 queried\/processed externally (Log Analytics, SIEM, notebooks, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Monitor \/ Log Analytics:<\/strong> alerting and analytics for connection monitoring and log queries.<\/li>\n<li><strong>Azure Storage:<\/strong> common sink for NSG flow logs and packet capture files.<\/li>\n<li><strong>Azure RBAC:<\/strong> governs who can run diagnostics and access captured data.<\/li>\n<li><strong>Network resources:<\/strong> VNets, NSGs, NICs, route tables, gateways, load balancers (as applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Typical dependencies you\u2019ll see in real deployments:\n&#8211; Storage accounts (logging destination)\n&#8211; Log Analytics workspace (analytics, alerting)\n&#8211; VM extensions\/agents (for packet capture and some monitoring scenarios)\n&#8211; Azure Policy (to enforce enabling flow logs or diagnostic settings\u2014policy availability and effects vary by resource type; verify in official docs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Uses <strong>Azure AD<\/strong> authentication and <strong>Azure RBAC<\/strong> for permissions.<\/li>\n<li>Diagnostic actions are management operations; access is governed by roles on subscriptions\/resource groups\/resources.<\/li>\n<li>Data access (packet capture files, flow logs) is governed by permissions on the <strong>storage account<\/strong> or workspace.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Network Watcher does not \u201csit inline\u201d in your traffic path.<\/li>\n<li>It observes configuration and logs, and for some features it triggers captures\/agents on endpoints.<\/li>\n<li>NSG flow logs are generated as part of NSG processing and exported to configured destinations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Decide upfront:<\/li>\n<li>Which VNets\/subnets require flow logs (usually production and shared networks)<\/li>\n<li>Retention period and access controls for logs<\/li>\n<li>Whether logs go to centralized storage\/workspaces per environment<\/li>\n<li>Who can run packet capture and where outputs are stored<\/li>\n<li>Use tags, naming standards, and consistent resource group layouts to make diagnostics repeatable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  User[Engineer \/ SRE] --&gt;|Portal \/ CLI| NW[Azure Network Watcher (Regional)]\n  NW --&gt; ARM[Azure Resource Manager APIs]\n  ARM --&gt; VNet[VNets \/ NICs \/ NSGs \/ Routes]\n\n  NW --&gt;|Flow logs \/ Capture output| Storage[Azure Storage Account]\n  NW --&gt;|Metrics\/Logs (optional)| LA[Log Analytics Workspace]\n\n  User --&gt;|Query| LA\n  User --&gt;|Download| Storage\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Subscriptions[\"Azure Subscriptions\"]\n    subgraph Hub[\"Hub Network (Prod)\"]\n      FW[Azure Firewall \/ NVA]\n      GW[VPN Gateway]\n      NSGHub[NSGs + UDRs]\n    end\n\n    subgraph Spokes[\"Spoke VNets (Prod)\"]\n      App[App VMs\/VMSS]\n      DB[DB VMs]\n      NSGSpoke[NSGs per subnet\/NIC]\n    end\n  end\n\n  subgraph NWRegion[\"Azure Network Watcher (per region)\"]\n    CM[Connection Monitor]\n    Diag[Diagnostics: Next Hop \/ IP Flow Verify \/ Topology]\n    PC[Packet Capture (on demand)]\n    FL[NSG Flow Logs]\n  end\n\n  subgraph Observability[\"Observability &amp; Governance\"]\n    SA[Central Storage Account(s)]\n    LAW[Log Analytics Workspace]\n    AM[Azure Monitor Alerts]\n    SIEM[Microsoft Sentinel (optional)]\n  end\n\n  App &lt;--&gt; DB\n  App --&gt; FW\n  FW --&gt; GW\n\n  CM --&gt; LAW\n  FL --&gt; SA\n  PC --&gt; SA\n  Diag --&gt; App\n  Diag --&gt; DB\n\n  LAW --&gt; AM\n  LAW --&gt; SIEM\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before starting with Azure Network Watcher in a lab or production environment:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Azure account and subscription<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>Azure subscription<\/strong> where you can create:<\/li>\n<li>Resource groups<\/li>\n<li>VNets, subnets, NSGs<\/li>\n<li>Virtual machines<\/li>\n<li>Storage account (for logs)<\/li>\n<li>Billing must be enabled (even if using free credits), because:<\/li>\n<li>VMs cost money<\/li>\n<li>Storage and log ingestion can cost money<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need sufficient Azure RBAC permissions for:\n&#8211; Creating network and compute resources (e.g., <strong>Contributor<\/strong> on a resource group for the lab)\n&#8211; Running Network Watcher operations (typically covered by Contributor\/Network Contributor)\n&#8211; Enabling NSG flow logs and accessing storage outputs<\/p>\n\n\n\n<p>Common roles (choose least privilege appropriate to your org):\n&#8211; <strong>Network Contributor<\/strong> (network resources)\n&#8211; <strong>Virtual Machine Contributor<\/strong> (VMs)\n&#8211; <strong>Storage Blob Data Reader\/Contributor<\/strong> (to view flow logs \/ packet captures in storage)\n&#8211; <strong>Log Analytics Reader\/Contributor<\/strong> (if using Log Analytics)<\/p>\n\n\n\n<blockquote>\n<p>In production, separate \u201cwho can run packet capture\u201d from \u201cwho can read capture files\u201d to reduce sensitive data exposure.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<p>For the hands-on lab:\n&#8211; <strong>Azure CLI<\/strong> (recommended): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<br\/>\n&#8211; Optional: PowerShell Az module, or Portal-only workflow<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Network Watcher is regional and broadly available. Still:<\/li>\n<li>Verify your target region supports the features you need.<\/li>\n<li>Ensure Network Watcher is enabled in that region for your subscription (often automatic, but not guaranteed in every scenario).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits (high level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM cores quota in the region<\/li>\n<li>Public IP quotas (if using public access)<\/li>\n<li>Storage account limits (IOPS\/throughput) and retention<\/li>\n<li>Flow log volume and workspace ingestion limits (if integrating with Log Analytics)<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Always verify exact service limits in official docs for the feature you\u2019re using.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Virtual network and subnets<\/li>\n<li>NSG applied to a subnet or NIC (for flow logs and rule evaluation)<\/li>\n<li>VMs for connectivity and packet capture scenarios<\/li>\n<li>Storage account for NSG flow logs and packet capture outputs (recommended)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Azure Network Watcher pricing is <strong>feature- and usage-dependent<\/strong>. The base \u201cservice\u201d may appear free, but many capabilities generate costs via dependent services and data processing.<\/p>\n\n\n\n<p>Official pricing page (verify current pricing and meters):<br\/>\nhttps:\/\/azure.microsoft.com\/pricing\/details\/network-watcher\/<\/p>\n\n\n\n<p>Azure Pricing Calculator:<br\/>\nhttps:\/\/azure.microsoft.com\/pricing\/calculator\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>Depending on what you enable, costs typically come from:\n&#8211; <strong>NSG flow logs<\/strong>\n  &#8211; Log generation\/export and\/or processing (metering depends on current Azure pricing model\u2014verify)\n  &#8211; <strong>Storage costs<\/strong> (hot\/cool\/archive, transactions)\n  &#8211; Optional analytics costs if you ingest into Log Analytics \/ SIEM\n&#8211; <strong>Connection Monitor<\/strong>\n  &#8211; Test runs, monitoring frequency, and data ingestion\/storage (often via Azure Monitor\/Log Analytics)\n&#8211; <strong>Packet capture<\/strong>\n  &#8211; Storage for capture files (pcap) and storage transactions\n  &#8211; VM overhead (CPU\/disk during capture) can be indirect cost\n&#8211; <strong>VMs used for monitoring<\/strong>\n  &#8211; If you deploy \u201ctest agents\u201d or monitor from VMs, VM runtime is a cost driver\n&#8211; <strong>Log Analytics<\/strong>\n  &#8211; Data ingestion, retention beyond free thresholds (if any), and queries (pricing varies by model and region)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>There is no universal \u201cfree tier\u201d that makes all Network Watcher features free. Some components may not charge directly, but <strong>downstream storage and analytics almost always do<\/strong>.<\/li>\n<li>Always validate what is included for your subscription type and region in the official pricing page.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Main cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Volume of flow logs<\/strong> (high traffic subnets generate lots of logs)<\/li>\n<li><strong>Retention period<\/strong> (storage costs scale with time)<\/li>\n<li><strong>Connection Monitor frequency and number of tests<\/strong><\/li>\n<li><strong>Log Analytics ingestion<\/strong> (if you centralize flow logs or monitoring into a workspace)<\/li>\n<li><strong>Packet capture size and frequency<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data transfer charges<\/strong> (for moving logs between regions, or exporting out of Azure)<\/li>\n<li><strong>Security overhead<\/strong> (Key rotation, access reviews, SIEM integration)<\/li>\n<li><strong>Operational overhead<\/strong> (incident response processes, runbooks, tooling)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you centralize logs cross-region, or export to third-party tools, you may incur:<\/li>\n<li>Inter-region bandwidth costs<\/li>\n<li>Egress charges to the internet or to other clouds<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical guidance)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>NSG flow logs only where needed<\/strong> (production, shared services, sensitive subnets).<\/li>\n<li>Use <strong>short retention<\/strong> in hot storage; lifecycle older logs to cool\/archive when appropriate.<\/li>\n<li>Prefer <strong>targeted packet captures<\/strong> with strict time windows and filters.<\/li>\n<li>Right-size <strong>Connection Monitor<\/strong>: fewer endpoints, longer intervals, and focused tests for critical paths.<\/li>\n<li>If using Log Analytics:<\/li>\n<li>Control which logs are ingested<\/li>\n<li>Define retention intentionally<\/li>\n<li>Consider sampling strategies where appropriate (verify what is supported)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal lab typically includes:\n&#8211; 2 small Linux VMs for a short time (primary cost)\n&#8211; 1 storage account with minimal logs\/captures (small cost if limited volume and retention)\n&#8211; Optional Log Analytics workspace (can add cost if ingesting flow logs)<\/p>\n\n\n\n<p>Because <strong>prices vary by region and change over time<\/strong>, do not assume fixed numbers\u2014use the pricing calculator with your region and expected data volumes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, the largest costs usually come from:\n&#8211; <strong>High-volume NSG flow logs<\/strong> across many subnets\n&#8211; <strong>Centralized analytics<\/strong> (Log Analytics\/SIEM ingestion and retention)\n&#8211; Multiple regions and high availability logging patterns<\/p>\n\n\n\n<p>A cost-conscious production pattern is:\n&#8211; Enable flow logs for critical NSGs only\n&#8211; Centralize in a small number of storage accounts with lifecycle policies\n&#8211; Ingest only necessary subsets into analytics platforms\n&#8211; Use scheduled audits and on-demand deep diagnostics (packet capture) rather than always-on deep capture<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a small Azure network, intentionally blocks traffic with an NSG, and then uses Azure Network Watcher tools to identify the cause and validate the fix. It is designed to be safe and relatively low-cost if you delete resources afterward.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create two VMs in the same VNet on different subnets.<\/li>\n<li>Apply an NSG rule that blocks SSH to one VM.<\/li>\n<li>Use Azure Network Watcher to:<\/li>\n<li>Test connectivity<\/li>\n<li>Verify IP flow (NSG allow\/deny)<\/li>\n<li>Check next hop (routing)<\/li>\n<li>Fix the NSG rule and confirm connectivity.<\/li>\n<li>(Optional) Enable NSG flow logs to a storage account and view generated log blobs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will create:\n&#8211; Resource group: <code>rg-nw-lab<\/code>\n&#8211; VNet: <code>vnet-nw-lab<\/code> with two subnets\n&#8211; NSG: <code>nsg-vm2<\/code> applied to VM2 NIC (or subnet)\n&#8211; VM1 (jump\/test): <code>vm1-nw<\/code> (Linux)\n&#8211; VM2 (target): <code>vm2-nw<\/code> (Linux)\n&#8211; Public IP for VM1 to SSH in (optional but convenient)\n&#8211; Use Azure Network Watcher diagnostics in the same region<\/p>\n\n\n\n<blockquote>\n<p>Cost note: The biggest cost in this lab is VM runtime. Use small VM sizes and delete the resource group when finished.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and sign in (Azure CLI)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open a terminal with Azure CLI installed.<\/li>\n<li>Sign in and pick a subscription.<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">az login\naz account show\n# If needed:\naz account set --subscription \"&lt;YOUR_SUBSCRIPTION_ID_OR_NAME&gt;\"\n<\/code><\/pre>\n\n\n\n<p>Set variables (choose a region close to you):<\/p>\n\n\n\n<pre><code class=\"language-bash\">RG=\"rg-nw-lab\"\nLOC=\"eastus\"           # change as needed\nVNET=\"vnet-nw-lab\"\nSUBNET1=\"snet-vm1\"\nSUBNET2=\"snet-vm2\"\nNSG=\"nsg-vm2\"\nVM1=\"vm1-nw\"\nVM2=\"vm2-nw\"\nADMINUSER=\"azureuser\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You\u2019re authenticated, and variables are defined.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a resource group and VNet with two subnets<\/h3>\n\n\n\n<pre><code class=\"language-bash\">az group create -n \"$RG\" -l \"$LOC\"\n\naz network vnet create \\\n  -g \"$RG\" -n \"$VNET\" -l \"$LOC\" \\\n  --address-prefixes 10.10.0.0\/16 \\\n  --subnet-name \"$SUBNET1\" --subnet-prefixes 10.10.1.0\/24\n\naz network vnet subnet create \\\n  -g \"$RG\" --vnet-name \"$VNET\" -n \"$SUBNET2\" \\\n  --address-prefixes 10.10.2.0\/24\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Resource group, VNet, and two subnets exist.<\/p>\n\n\n\n<p><strong>Verify:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet show -g \"$RG\" -n \"$VNET\" --query \"{addressSpace:addressSpace.addressPrefixes, subnets:subnets[].name}\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an NSG that blocks SSH inbound (intentionally)<\/h3>\n\n\n\n<p>Create an NSG and a deny rule for TCP 22 inbound:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg create -g \"$RG\" -n \"$NSG\" -l \"$LOC\"\n\naz network nsg rule create \\\n  -g \"$RG\" --nsg-name \"$NSG\" -n \"Deny-SSH-Inbound\" \\\n  --priority 100 \\\n  --direction Inbound --access Deny --protocol Tcp \\\n  --source-address-prefixes \"*\" --source-port-ranges \"*\" \\\n  --destination-address-prefixes \"*\" --destination-port-ranges 22\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> VM2 will not allow inbound SSH (even from VM1) once the NSG is applied.<\/p>\n\n\n\n<p><strong>Verify:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg rule list -g \"$RG\" --nsg-name \"$NSG\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create VM1 (with public IP) and VM2 (private only)<\/h3>\n\n\n\n<p>Create VM1 in subnet1:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm create \\\n  -g \"$RG\" -n \"$VM1\" -l \"$LOC\" \\\n  --image Ubuntu2204 \\\n  --admin-username \"$ADMINUSER\" \\\n  --generate-ssh-keys \\\n  --vnet-name \"$VNET\" --subnet \"$SUBNET1\" \\\n  --public-ip-sku Standard\n<\/code><\/pre>\n\n\n\n<p>Create VM2 in subnet2 (no public IP):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm create \\\n  -g \"$RG\" -n \"$VM2\" -l \"$LOC\" \\\n  --image Ubuntu2204 \\\n  --admin-username \"$ADMINUSER\" \\\n  --generate-ssh-keys \\\n  --vnet-name \"$VNET\" --subnet \"$SUBNET2\" \\\n  --public-ip-address \"\"\n<\/code><\/pre>\n\n\n\n<p>Apply the NSG to VM2\u2019s NIC (NIC-level is clear for labs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">VM2_NIC_ID=$(az vm show -g \"$RG\" -n \"$VM2\" --query \"networkProfile.networkInterfaces[0].id\" -o tsv)\n\naz network nic update \\\n  --ids \"$VM2_NIC_ID\" \\\n  --network-security-group \"$NSG\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> VM1 is reachable via SSH from your machine; VM2 has no public IP and blocks SSH inbound due to the NSG.<\/p>\n\n\n\n<p><strong>Verify VM IPs:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">VM1_PUBLIC_IP=$(az vm show -d -g \"$RG\" -n \"$VM1\" --query publicIps -o tsv)\nVM1_PRIVATE_IP=$(az vm show -d -g \"$RG\" -n \"$VM1\" --query privateIps -o tsv)\nVM2_PRIVATE_IP=$(az vm show -d -g \"$RG\" -n \"$VM2\" --query privateIps -o tsv)\n\necho \"VM1 public:  $VM1_PUBLIC_IP\"\necho \"VM1 private: $VM1_PRIVATE_IP\"\necho \"VM2 private: $VM2_PRIVATE_IP\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Ensure Azure Network Watcher is enabled in the region<\/h3>\n\n\n\n<p>In many subscriptions, Azure enables Network Watcher automatically when networking resources exist. Still, explicitly enabling it avoids confusion.<\/p>\n\n\n\n<p>Run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher configure --locations \"$LOC\" --enabled true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Network Watcher is enabled for the region.<\/p>\n\n\n\n<p><strong>Verify:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher list -g \"NetworkWatcherRG\" -o table 2&gt;\/dev\/null || true\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>If the <code>NetworkWatcherRG<\/code> resource group name differs or isn\u2019t visible due to permissions, verify in the Azure Portal: search <strong>Network Watcher<\/strong> \u2192 ensure the region is enabled.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Reproduce the problem (SSH from VM1 to VM2 should fail)<\/h3>\n\n\n\n<p>SSH into VM1 from your local machine:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh ${ADMINUSER}@${VM1_PUBLIC_IP}\n<\/code><\/pre>\n\n\n\n<p>From VM1, attempt to SSH to VM2 private IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh -o ConnectTimeout=5 ${ADMINUSER}@${VM2_PRIVATE_IP}\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> SSH fails (timeout or connection failure), because VM2 inbound TCP 22 is denied by the NSG.<\/p>\n\n\n\n<p>Exit VM1 (or keep it open for later):<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Use Network Watcher \u201cIP flow verify\u201d to confirm NSG is denying<\/h3>\n\n\n\n<p>Run IP flow verify against VM2 NIC for inbound port 22. You need:\n&#8211; Target VM (VM2)\n&#8211; Direction: inbound\n&#8211; Protocol: TCP\n&#8211; Local port: 22\n&#8211; Remote IP: VM1 private IP (source)<\/p>\n\n\n\n<p>In Azure CLI, IP flow verify is exposed under Network Watcher. The exact CLI parameters can vary by CLI version; use <code>--help<\/code> if needed.<\/p>\n\n\n\n<p>Check help:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher ip-flow-verify --help\n<\/code><\/pre>\n\n\n\n<p>A commonly used pattern is:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher ip-flow-verify \\\n  -g \"$RG\" \\\n  --vm \"$VM2\" \\\n  --direction Inbound \\\n  --protocol Tcp \\\n  --local  \"$VM2_PRIVATE_IP:22\" \\\n  --remote \"$VM1_PRIVATE_IP:12345\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Result indicates <strong>Deny<\/strong> and identifies the rule (for example, <code>Deny-SSH-Inbound<\/code>).<\/p>\n\n\n\n<blockquote>\n<p>If the CLI syntax differs in your installed version, use the Azure Portal alternative: Network Watcher \u2192 <strong>IP flow verify<\/strong> \u2192 select VM2 \u2192 specify inbound, TCP, local port 22, remote IP VM1.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Use Network Watcher \u201cNext hop\u201d to confirm routing is not the issue<\/h3>\n\n\n\n<p>Check next hop from VM1 to VM2 private IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher show-next-hop \\\n  -g \"$RG\" \\\n  --vm \"$VM1\" \\\n  --destination-ip-address \"$VM2_PRIVATE_IP\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Next hop should indicate a VNet route (for example, <strong>VnetLocal<\/strong>) and show that routing is normal inside the VNet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Use Network Watcher \u201cTest connectivity\u201d (connection troubleshoot)<\/h3>\n\n\n\n<p>Run a connectivity test from VM1 to VM2:22.<\/p>\n\n\n\n<p>Check help:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher test-connectivity --help\n<\/code><\/pre>\n\n\n\n<p>Run the test:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher test-connectivity \\\n  -g \"$RG\" \\\n  --source-resource \"$(az vm show -g \"$RG\" -n \"$VM1\" --query id -o tsv)\" \\\n  --dest-address \"$VM2_PRIVATE_IP\" \\\n  --dest-port 22\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Status should be <strong>Unreachable<\/strong> (or similar), and details may point to NSG denial.<\/p>\n\n\n\n<blockquote>\n<p>If it reports agent\/extension requirements, install the Network Watcher VM extension (next step) or use portal-based diagnostics which may guide you.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Fix the NSG and re-test<\/h3>\n\n\n\n<p>Now allow SSH from VM1 subnet to VM2 on port 22 (more secure than allowing <code>*<\/code>).<\/p>\n\n\n\n<p>Create an allow rule with higher priority (lower number) than the deny rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg rule create \\\n  -g \"$RG\" --nsg-name \"$NSG\" -n \"Allow-SSH-From-Subnet1\" \\\n  --priority 90 \\\n  --direction Inbound --access Allow --protocol Tcp \\\n  --source-address-prefixes 10.10.1.0\/24 --source-port-ranges \"*\" \\\n  --destination-address-prefixes \"*\" --destination-port-ranges 22\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> SSH from VM1 to VM2 should succeed now.<\/p>\n\n\n\n<p>Re-SSH to VM1 and test again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh ${ADMINUSER}@${VM1_PUBLIC_IP}\nssh -o ConnectTimeout=5 ${ADMINUSER}@${VM2_PRIVATE_IP}\n<\/code><\/pre>\n\n\n\n<p>You should get an SSH prompt on VM2. Exit both sessions:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\nexit\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11 (Optional): Enable NSG flow logs to a storage account (Portal-first)<\/h3>\n\n\n\n<p>This optional step adds observability but can increase cost and complexity. It\u2019s valuable to see real flow records.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create a storage account (CLI):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">STORAGE=\"stnwl$RANDOM$RANDOM\"\naz storage account create \\\n  -g \"$RG\" -n \"$STORAGE\" -l \"$LOC\" \\\n  --sku Standard_LRS \\\n  --kind StorageV2\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>\n<p>In Azure Portal:\n&#8211; Go to <strong>Network Watcher<\/strong> \u2192 <strong>NSG flow logs<\/strong>\n&#8211; Select your NSG (<code>nsg-vm2<\/code>)\n&#8211; Set <strong>Flow logs<\/strong> = On\n&#8211; Choose the storage account you created\n&#8211; Choose retention (keep it short for lab)\n&#8211; Save<\/p>\n<\/li>\n<li>\n<p>Generate some traffic (from VM1 to VM2):\n&#8211; SSH to VM1\n&#8211; SSH to VM2 a few times, or run <code>curl<\/code> to a port if you open one\n&#8211; Wait a few minutes for logs to appear<\/p>\n<\/li>\n<li>\n<p>View logs in the storage account:\n&#8211; Storage account \u2192 <strong>Containers<\/strong>\n&#8211; Look for the flow logs container\/path created by the feature\n&#8211; Download a JSON log file and inspect it<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You\u2019ll find flow log blobs that record allowed\/denied flows through the NSG.<\/p>\n\n\n\n<blockquote>\n<p>Exact container names and schema can evolve; use Microsoft\u2019s documentation for current flow log format and fields.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully validated:\n&#8211; An NSG deny rule caused an SSH outage (reproduced).\n&#8211; <strong>IP flow verify<\/strong> identified the deny action and (typically) the matching rule.\n&#8211; <strong>Next hop<\/strong> confirmed routing was not the issue.\n&#8211; <strong>Test connectivity<\/strong> confirmed the reachability status.\n&#8211; Updating NSG rules restored connectivity.\n&#8211; (Optional) NSG flow logs captured flow telemetry to storage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Network Watcher isn\u2019t enabled in the region<\/strong>\n&#8211; Symptom: Tools fail or region isn\u2019t selectable.\n&#8211; Fix: Enable it for the region:\n  <code>bash\n  az network watcher configure --locations \"$LOC\" --enabled true<\/code><\/p>\n<\/li>\n<li>\n<p><strong>RBAC permissions<\/strong>\n&#8211; Symptom: Access denied when running diagnostics or configuring flow logs.\n&#8211; Fix: Ensure you have appropriate roles (Network Contributor, Contributor, plus storage\/log roles for data access).<\/p>\n<\/li>\n<li>\n<p><strong>NSG applied to wrong place<\/strong>\n&#8211; Symptom: SSH isn\u2019t blocked even though you created a deny rule, or remains blocked after allowing.\n&#8211; Fix: Confirm the NSG is associated with the correct <strong>NIC<\/strong> or <strong>subnet<\/strong>, and verify effective rules:\n  &#8211; Portal \u2192 VM \u2192 Networking \u2192 NIC NSG association\n  &#8211; Network Watcher \u2192 Security group view (effective rules)<\/p>\n<\/li>\n<li>\n<p><strong>SSH fails even after allow rule<\/strong>\n&#8211; Potential causes:\n  &#8211; VM2\u2019s OS firewall (UFW\/iptables) blocks port 22\n  &#8211; Wrong username or keys\n  &#8211; You\u2019re testing from a different source IP range than allowed\n&#8211; Fix: Verify OS firewall and confirm rule source prefix matches VM1 subnet.<\/p>\n<\/li>\n<li>\n<p><strong>Flow logs not appearing<\/strong>\n&#8211; Causes:\n  &#8211; Flow logs not enabled on the correct NSG\n  &#8211; Wrong storage account selected or access issue\n  &#8211; Not enough time elapsed\n&#8211; Fix: Re-check configuration, then generate traffic and wait several minutes.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete the entire resource group to avoid ongoing charges:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete -n \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All lab resources are removed (VMs, network, NSG, storage). Confirm in portal after deletion completes.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Design for debuggability:<\/strong> Standardize NSG usage (subnet vs NIC) so effective policy is predictable.<\/li>\n<li><strong>Hub-and-spoke clarity:<\/strong> In complex networks, document UDRs, firewall paths, and DNS\u2014Network Watcher helps validate, but architecture clarity prevents incidents.<\/li>\n<li><strong>Centralize logs deliberately:<\/strong> Decide whether flow logs go to per-subscription storage or centralized logging subscriptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply <strong>least privilege<\/strong>:<\/li>\n<li>Many engineers can run \u201cread-only\u201d diagnostics (topology, effective routes).<\/li>\n<li>Only a small group should run <strong>packet capture<\/strong>.<\/li>\n<li>Separate permissions for:<\/li>\n<li>Running packet capture<\/li>\n<li>Reading capture output in storage<\/li>\n<li>Use <strong>Privileged Identity Management (PIM)<\/strong> where appropriate for just-in-time elevation (verify applicability in your tenant).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>NSG flow logs selectively<\/strong> and review periodically.<\/li>\n<li>Control retention and storage lifecycle policies.<\/li>\n<li>Avoid indiscriminate Log Analytics ingestion for high-volume flow logs unless you have a clear detection\/analytics need and budget.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>flow logs<\/strong> for broad visibility and <strong>packet capture<\/strong> for targeted deep dives.<\/li>\n<li>Schedule captures for short windows; use filters where supported.<\/li>\n<li>For continuous monitoring, pick intervals appropriate for the SLO (don\u2019t over-sample).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Connection Monitor<\/strong> for critical dependencies with alerting via Azure Monitor.<\/li>\n<li>Run periodic \u201cnetwork health checks\u201d as part of operational readiness.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Maintain an incident runbook:<\/li>\n<li>Step 1: test-connectivity<\/li>\n<li>Step 2: IP flow verify<\/li>\n<li>Step 3: next hop + effective routes<\/li>\n<li>Step 4: check NSG flow logs (if enabled)<\/li>\n<li>Step 5: packet capture (only if needed)<\/li>\n<li>Standardize naming conventions:<\/li>\n<li><code>nsg-&lt;app&gt;-&lt;env&gt;-&lt;region&gt;<\/code><\/li>\n<li><code>rt-&lt;subnet&gt;-&lt;env&gt;<\/code><\/li>\n<li>Tags: <code>env<\/code>, <code>owner<\/code>, <code>costCenter<\/code>, <code>dataSensitivity<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tag NSGs and logging storage accounts with:<\/li>\n<li><code>dataClassification<\/code> (because flow logs can be sensitive)<\/li>\n<li><code>retentionPolicy<\/code><\/li>\n<li><code>securityOwner<\/code><\/li>\n<li>Use Azure Policy where possible to audit:<\/li>\n<li>NSG presence on subnets<\/li>\n<li>Flow log enablement (availability depends on policy definitions\u2014verify current built-ins)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Network Watcher actions are controlled by <strong>Azure RBAC<\/strong>.<\/li>\n<li>Treat the ability to run <strong>packet capture<\/strong> and to read its output as privileged.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>At rest:<\/strong> Azure Storage and Log Analytics encrypt data at rest by default (verify current guarantees and configuration options).<\/li>\n<li><strong>In transit:<\/strong> Access to storage\/workspaces uses TLS.<\/li>\n<li>Consider customer-managed keys (CMK) if required by policy (verify service support for your chosen storage\/workspace configuration).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Network Watcher does not expose inbound endpoints into your VNets, but:<\/li>\n<li>Packet capture outputs and flow logs are stored in storage accounts\u2014secure those endpoints (private endpoints, firewall rules, least privilege).<\/li>\n<li>Avoid public access to storage where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer identity-based access (Azure AD) to storage over shared keys when possible.<\/li>\n<li>Rotate storage keys if they must be used (some workflows historically relied on keys; verify current options).<\/li>\n<li>Avoid sharing capture files outside controlled channels.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Log and audit:<\/li>\n<li>Who enabled flow logs<\/li>\n<li>Who ran packet captures and when<\/li>\n<li>Storage access (Blob access logs, Azure Activity Logs)<\/li>\n<li>Consider sending Activity Logs to a central workspace\/SIEM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Flow logs and packet captures may contain:<\/li>\n<li>IP addresses, ports, and metadata<\/li>\n<li>Potential payload data (packet capture)<\/li>\n<li>Apply:<\/li>\n<li>Data retention limits<\/li>\n<li>Access reviews<\/li>\n<li>Incident handling procedures<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Storing packet captures in a broadly accessible storage account.<\/li>\n<li>Long retention without justification.<\/li>\n<li>Enabling flow logs everywhere without a plan, then failing to secure or review the data.<\/li>\n<li>Granting broad Contributor rights to too many people, enabling unintended data exposure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use dedicated, locked-down storage accounts for network logs.<\/li>\n<li>Apply private endpoints and storage firewall rules where possible.<\/li>\n<li>Define a minimal group for packet capture capability and enforce JIT access.<\/li>\n<li>Document data handling and retention policies for flow logs and captures.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>The exact limitations vary by feature and evolve over time. Always confirm in official documentation for your region and scenario.<\/p>\n\n\n\n<p>Common, practical gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional enablement:<\/strong> Network Watcher is regional; troubleshooting a resource in a region where it\u2019s not enabled can fail or be confusing.<\/li>\n<li><strong>Agent\/extension dependencies:<\/strong> Some features (notably packet capture and certain continuous monitoring scenarios) may require VM extensions\/agents and proper VM access.<\/li>\n<li><strong>Data volume growth:<\/strong> NSG flow logs can become massive in busy environments.<\/li>\n<li><strong>Retention surprises:<\/strong> Keeping logs \u201cforever\u201d in hot storage is expensive and risky.<\/li>\n<li><strong>Storage security:<\/strong> Flow logs and packet capture files are sensitive; a misconfigured storage account is a security incident waiting to happen.<\/li>\n<li><strong>Point-in-time vs continuous:<\/strong> Tools like IP flow verify and next hop are point-in-time evaluations; they don\u2019t replace continuous telemetry.<\/li>\n<li><strong>Complex routing:<\/strong> Effective routes can be correct yet traffic still fails due to downstream appliances, asymmetric routing, or on-prem routes.<\/li>\n<li><strong>Portal UX changes:<\/strong> Azure Portal often renames or reorganizes blades; rely on official docs when you can\u2019t find a feature.<\/li>\n<li><strong>CLI command variations:<\/strong> Azure CLI evolves; if a command differs, use <code>--help<\/code> and cross-check official CLI reference pages.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure Network Watcher is not the only way to monitor and troubleshoot networking. It\u2019s often used alongside other tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure Network Watcher<\/strong><\/td>\n<td>Azure VNet diagnostics, NSG flow logs, routing\/connectivity troubleshooting<\/td>\n<td>First-party Azure-aware tools; deep diagnostics (IP flow verify, next hop); integrates with Azure Monitor<\/td>\n<td>Some features require agents; logging can be high-volume; not a full SIEM\/APM<\/td>\n<td>Default choice for Azure IaaS network troubleshooting and baseline network visibility<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Monitor (Logs\/Metrics\/Alerts)<\/strong><\/td>\n<td>Central monitoring, alerting, query, dashboards<\/td>\n<td>Strong analytics and alerting; cross-service observability<\/td>\n<td>Needs data sources (flow logs, VM logs); may increase cost with ingestion<\/td>\n<td>Use with Network Watcher for alerting and long-term analysis<\/td>\n<\/tr>\n<tr>\n<td><strong>Microsoft Sentinel<\/strong><\/td>\n<td>SIEM and security analytics<\/td>\n<td>Correlation, detection rules, incident management<\/td>\n<td>Additional cost and tuning; needs good data hygiene<\/td>\n<td>Choose when security monitoring and SOC workflows are required<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Firewall logs \/ NVA logs<\/strong><\/td>\n<td>Centralized egress\/ingress inspection<\/td>\n<td>L3\u2013L7 visibility at chokepoints<\/td>\n<td>Doesn\u2019t replace NSG-level visibility everywhere<\/td>\n<td>Use when you enforce centralized inspection and want firewall-centric visibility<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS VPC Reachability Analyzer + VPC Flow Logs<\/strong><\/td>\n<td>Similar capabilities in AWS<\/td>\n<td>Strong path analysis; flow logging<\/td>\n<td>Different cloud; not Azure-native<\/td>\n<td>Choose for AWS environments<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Network Intelligence Center (incl. Connectivity Tests)<\/strong><\/td>\n<td>Similar capabilities in GCP<\/td>\n<td>Network insights and tests<\/td>\n<td>Different cloud<\/td>\n<td>Choose for GCP environments<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed tcpdump\/Wireshark\/Zeek<\/strong><\/td>\n<td>Deep packet and protocol analysis<\/td>\n<td>Maximum detail and control<\/td>\n<td>Operational overhead; access challenges; not Azure-aware by default<\/td>\n<td>Use when you need deep inspection beyond what managed tooling provides (often alongside Network Watcher)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated, hub-and-spoke)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services company runs a hub-and-spoke Azure network with strict segmentation. Periodic incidents occur after NSG\/UDR changes, and audits require evidence of traffic controls.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Enable Azure Network Watcher in all production regions.<\/li>\n<li>Enable NSG flow logs for:<ul>\n<li>Hub firewall subnets<\/li>\n<li>Spoke subnets containing regulated workloads<\/li>\n<\/ul>\n<\/li>\n<li>Send flow logs to dedicated storage accounts with lifecycle policies.<\/li>\n<li>Use Connection Monitor for critical dependency paths (web \u2192 API \u2192 DB, and hybrid endpoints).<\/li>\n<li>Use Azure Monitor alerts for connection monitor failures.<\/li>\n<li><strong>Why this service was chosen:<\/strong><\/li>\n<li>Azure-native diagnostics map directly to NSGs, NICs, and UDRs.<\/li>\n<li>Supports audit and incident response with flow evidence.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster resolution of \u201cblocked traffic\u201d incidents.<\/li>\n<li>Improved audit readiness with consistent, reviewable network logs.<\/li>\n<li>Reduced risk from misconfigured routes and security rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (lean ops)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup hosts a small SaaS on a few VMs. They occasionally break internal connectivity when tightening NSG rules and need a fast way to debug without a dedicated network team.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Use Azure Network Watcher\u2019s IP flow verify + next hop as standard incident steps.<\/li>\n<li>Enable NSG flow logs only on the production backend subnet NSG with short retention.<\/li>\n<li>Use Connection Monitor only for the single most critical dependency path.<\/li>\n<li><strong>Why this service was chosen:<\/strong><\/li>\n<li>Low operational overhead; first-party tool integrated into Azure Portal.<\/li>\n<li>Targeted logging keeps cost manageable.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Fewer \u201cmystery outages\u201d after configuration changes.<\/li>\n<li>Better confidence during deployments and security hardening.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is Azure Network Watcher free?<\/h3>\n\n\n\n<p>The \u201cservice\u201d may not have a flat monthly fee, but <strong>many features generate usage-based costs<\/strong>, especially <strong>NSG flow logs<\/strong>, storage, and any analytics ingestion. Always check the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Is Azure Network Watcher global or regional?<\/h3>\n\n\n\n<p>It is <strong>regional<\/strong>. You typically enable and use it per Azure region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Do I need to enable Azure Network Watcher manually?<\/h3>\n\n\n\n<p>Often it is enabled automatically when you create networking resources, but not always in every scenario. If diagnostics aren\u2019t working, explicitly enable it for the region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) What\u2019s the fastest way to see if an NSG is blocking traffic?<\/h3>\n\n\n\n<p>Use <strong>IP flow verify<\/strong> (and optionally <strong>security group view<\/strong>) to see whether a specific flow is allowed or denied and which rule matches.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) What\u2019s the fastest way to check routing issues?<\/h3>\n\n\n\n<p>Use <strong>Next hop<\/strong> and <strong>effective routes<\/strong>. These show where Azure will send traffic and which routes apply.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) What is the difference between NSG flow logs and packet capture?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NSG flow logs<\/strong>: summarized flow records at the NSG level (who talked to whom, allowed\/denied).<\/li>\n<li><strong>Packet capture<\/strong>: packet-level data from a VM (deep inspection, payload risk).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Can Azure Network Watcher troubleshoot PaaS services directly?<\/h3>\n\n\n\n<p>Network Watcher primarily targets <strong>VNet-attached resources<\/strong> (VMs, NICs, NSGs, routes). For PaaS, you often combine it with service-specific diagnostics and Azure Monitor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Does Connection Monitor replace the older Network Performance Monitor?<\/h3>\n\n\n\n<p>Historically, Azure offered Network Performance Monitor (NPM) and earlier \u201cclassic\u201d experiences. Today, <strong>Connection Monitor<\/strong> is the primary approach under Azure Network Watcher\/Azure Monitor. Verify current migration guidance in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Can I use Connection Monitor for hybrid connectivity?<\/h3>\n\n\n\n<p>Often yes, depending on endpoint types and agent support. Verify current supported endpoints and requirements in the official Connection Monitor documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) Where should I store NSG flow logs?<\/h3>\n\n\n\n<p>Commonly in an <strong>Azure Storage account<\/strong> with restricted access and lifecycle policies. Some organizations centralize logs into a dedicated logging subscription.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) How long should I retain flow logs?<\/h3>\n\n\n\n<p>Keep the minimum required for:\n&#8211; troubleshooting (often days\/weeks)\n&#8211; compliance (varies)\nUse storage lifecycle policies to reduce cost and exposure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Can Network Watcher prove my application is healthy?<\/h3>\n\n\n\n<p>No. It can show <strong>network reachability and network-level symptoms<\/strong>, but application health depends on app logs, dependencies, and performance telemetry.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) Why does \u201cnext hop\u201d look correct but traffic still fails?<\/h3>\n\n\n\n<p>Because routing can be correct while:\n&#8211; NSGs deny the flow\n&#8211; a firewall\/NVA drops traffic\n&#8211; asymmetric routing breaks return traffic\n&#8211; DNS resolves incorrectly\n&#8211; the destination service isn\u2019t listening<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) Is it safe to run packet capture in production?<\/h3>\n\n\n\n<p>It can be, if you:\n&#8211; restrict access\n&#8211; run short captures with filters\n&#8211; store outputs securely\n&#8211; have an approved data handling policy\nBut treat captures as sensitive.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) How do I operationalize Azure Network Watcher for governance?<\/h3>\n\n\n\n<p>Standardize:\n&#8211; which NSGs have flow logs enabled\n&#8211; where logs are stored\n&#8211; retention and access controls\n&#8211; runbooks for incident triage using IP flow verify\/next hop\/test connectivity\nThen audit regularly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) Does Azure Network Watcher work across subscriptions?<\/h3>\n\n\n\n<p>It operates within what you have RBAC access to. Cross-subscription scenarios are common in enterprises, but you must design permissions, logging destinations, and operational processes accordingly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) Can I automate Network Watcher diagnostics?<\/h3>\n\n\n\n<p>Yes. Many actions are exposed via <strong>Azure CLI, PowerShell, and ARM APIs<\/strong>, enabling scripted troubleshooting and runbook automation.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure Network Watcher<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Network Watcher documentation: https:\/\/learn.microsoft.com\/azure\/network-watcher\/<\/td>\n<td>Authoritative reference for features, requirements, and latest updates<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Connection Monitor: https:\/\/learn.microsoft.com\/azure\/network-watcher\/connection-monitor<\/td>\n<td>How to set up continuous connectivity monitoring and interpret results<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>IP flow verify \/ traffic filtering diagnostics: https:\/\/learn.microsoft.com\/azure\/network-watcher\/diagnose-network-traffic-filtering-problem<\/td>\n<td>Step-by-step NSG deny\/allow troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Next hop \/ routing diagnostics: https:\/\/learn.microsoft.com\/azure\/network-watcher\/diagnose-vm-network-routing-problem<\/td>\n<td>Understand effective routes and route-related failures<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Packet capture: https:\/\/learn.microsoft.com\/azure\/network-watcher\/packet-capture-overview<\/td>\n<td>How to safely capture packets and manage outputs<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>NSG flow logs: https:\/\/learn.microsoft.com\/azure\/network-watcher\/nsg-flow-logs<\/td>\n<td>Configuration, log format, and operational guidance<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>VPN troubleshooting: https:\/\/learn.microsoft.com\/azure\/network-watcher\/network-watcher-troubleshoot-vpn<\/td>\n<td>Supported scenarios and troubleshooting steps<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>Azure Network Watcher pricing: https:\/\/azure.microsoft.com\/pricing\/details\/network-watcher\/<\/td>\n<td>Current meters and billing model<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<td>Estimate total cost including storage and Log Analytics<\/td>\n<\/tr>\n<tr>\n<td>Official CLI reference<\/td>\n<td>Azure CLI Network Watcher commands: https:\/\/learn.microsoft.com\/cli\/azure\/network\/watcher<\/td>\n<td>Exact CLI syntax and parameters by version<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Azure Architecture Center: https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<td>Patterns for hub-spoke, governance, and observability (combine with Network Watcher)<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Microsoft Azure YouTube channel: https:\/\/www.youtube.com\/@MicrosoftAzure<\/td>\n<td>Search for Network Watcher\/Connection Monitor walkthroughs and updates<\/td>\n<\/tr>\n<tr>\n<td>Samples (verify)<\/td>\n<td>Azure samples on GitHub: https:\/\/github.com\/Azure<\/td>\n<td>Find scripts and examples; validate they match current docs before using<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following training providers may offer Azure, networking, or operations courses. Verify current course availability and delivery modes on their websites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, cloud engineers, SREs<\/td>\n<td>Azure operations, DevOps practices, monitoring fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps, SCM, cloud fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>Cloud ops, monitoring, governance<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform engineers<\/td>\n<td>Reliability engineering, incident response, observability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and monitoring teams<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites may list trainers, coaching, or training services. Verify background and course relevance directly on each site.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify specifics)<\/td>\n<td>Beginners to intermediate<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training services (verify specifics)<\/td>\n<td>DevOps engineers, admins<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps guidance (verify specifics)<\/td>\n<td>Teams needing short-term help<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify specifics)<\/td>\n<td>Ops\/DevOps teams<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These consulting organizations may help with Azure architecture, operations, and governance initiatives. Confirm service scope, references, and delivery model directly with each provider.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Cloud adoption, operations setup, governance<\/td>\n<td>Designing network observability approach; implementing logging storage and access controls; runbooks for incident response<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps\/cloud consulting and training (verify service catalog)<\/td>\n<td>DevOps transformation, platform practices<\/td>\n<td>Building operational playbooks; implementing monitoring strategy; standardizing Azure RBAC and tagging<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service catalog)<\/td>\n<td>CI\/CD, cloud operations<\/td>\n<td>Operationalizing network diagnostics; integrating logs into monitoring workflows; improving MTTR processes<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Azure Network Watcher<\/h3>\n\n\n\n<p>To use Azure Network Watcher effectively, you should understand:\n&#8211; Azure fundamentals: subscriptions, resource groups, RBAC\n&#8211; Azure networking basics:\n  &#8211; VNets, subnets\n  &#8211; NSGs and rule evaluation\n  &#8211; Route tables (UDRs) and system routes\n  &#8211; VNet peering\n  &#8211; DNS basics in Azure\n&#8211; Basic Linux\/Windows networking tools:\n  &#8211; <code>ping<\/code>, <code>traceroute<\/code>, <code>ss\/netstat<\/code>, <code>curl<\/code>, <code>tcpdump<\/code> (even if you plan to use managed tools)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Network Watcher<\/h3>\n\n\n\n<p>To mature beyond ad-hoc troubleshooting:\n&#8211; Azure Monitor (Logs, Metrics, Alerts)\n&#8211; Log Analytics \/ KQL querying\n&#8211; Microsoft Sentinel (if security monitoring is a requirement)\n&#8211; Azure Firewall and\/or NVA patterns\n&#8211; Infrastructure as Code (Bicep\/Terraform) for consistent NSG\/flow log provisioning\n&#8211; Azure Policy for governance and auditing<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ cloud operations engineer<\/li>\n<li>Network engineer (cloud)<\/li>\n<li>SRE \/ platform engineer<\/li>\n<li>DevOps engineer<\/li>\n<li>Security engineer \/ SOC analyst (as a data source for investigations)<\/li>\n<li>Solutions architect (designing observability and governance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Azure certifications change over time; check Microsoft\u2019s certification pages for current tracks. Commonly relevant areas:\n&#8211; Azure Fundamentals (baseline)\n&#8211; Azure Administrator (operations)\n&#8211; Azure Network Engineer (network specialization)\n&#8211; Azure Security Engineer (security monitoring and governance)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a hub-and-spoke lab and validate:<\/li>\n<li>UDR routing through a firewall\/NVA<\/li>\n<li>segmentation using IP flow verify<\/li>\n<li>flow log baselining for allowed\/denied traffic<\/li>\n<li>Create an \u201cincident runbook\u201d repository with scripts:<\/li>\n<li>test-connectivity wrapper<\/li>\n<li>next hop + effective routes export<\/li>\n<li>NSG rule evaluation helper<\/li>\n<li>Build a cost-controlled logging design:<\/li>\n<li>flow logs \u2192 storage with lifecycle rules<\/li>\n<li>a small subset \u2192 Log Analytics for alerts<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Network Watcher:<\/strong> Azure service for network monitoring and diagnostics in VNets.<\/li>\n<li><strong>VNet (Virtual Network):<\/strong> Private network in Azure for hosting resources.<\/li>\n<li><strong>Subnet:<\/strong> A range within a VNet where resources are placed.<\/li>\n<li><strong>NIC (Network Interface):<\/strong> Network adapter attached to a VM.<\/li>\n<li><strong>NSG (Network Security Group):<\/strong> L3\/L4 stateful filtering rules controlling inbound\/outbound traffic.<\/li>\n<li><strong>UDR (User Defined Route):<\/strong> Custom route table entries to override system routing.<\/li>\n<li><strong>Effective routes:<\/strong> The final set of routes applied to a NIC (system + UDR).<\/li>\n<li><strong>Next hop:<\/strong> The next routing destination Azure selects for traffic to a destination IP.<\/li>\n<li><strong>IP flow verify:<\/strong> A check that returns whether a given 5-tuple is allowed\/denied by NSG rules.<\/li>\n<li><strong>NSG flow logs:<\/strong> Logs that record flows through an NSG (allowed\/denied).<\/li>\n<li><strong>Packet capture:<\/strong> Capturing packets (pcap) from a VM for deep network analysis.<\/li>\n<li><strong>Connection Monitor:<\/strong> Continuous connectivity monitoring with metrics and (typically) alert integration.<\/li>\n<li><strong>Log Analytics workspace:<\/strong> Azure Monitor logs store queried with KQL.<\/li>\n<li><strong>KQL (Kusto Query Language):<\/strong> Query language for Log Analytics and related services.<\/li>\n<li><strong>Azure RBAC:<\/strong> Role-based access control for managing access to Azure resources.<\/li>\n<li><strong>MTTR:<\/strong> Mean time to recovery\/resolve; a key operations metric.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Network Watcher is Azure\u2019s built-in, regional network diagnostics and visibility service. It matters because cloud networking failures are often caused by subtle interactions between NSGs, routes, and gateways\u2014and Network Watcher provides Azure-native tools (IP flow verify, next hop, connectivity tests, flow logs, and packet capture) to troubleshoot quickly and consistently.<\/p>\n\n\n\n<p>From a cost perspective, the key is understanding that <strong>logging and analytics drive spend<\/strong>: NSG flow logs can generate large volumes, and storage\/Log Analytics ingestion and retention can become significant. From a security perspective, treat <strong>flow logs and especially packet captures as sensitive data<\/strong>, and lock down access to both the diagnostic actions and the stored outputs.<\/p>\n\n\n\n<p>Use Azure Network Watcher when you need reliable, first-party network troubleshooting and governance for Azure VNets. Pair it with Azure Monitor and (optionally) Sentinel when you need alerting and centralized security analytics.<\/p>\n\n\n\n<p>Next step: implement a small production-ready pattern\u2014<strong>selective NSG flow logs + Connection Monitor for critical paths + runbooks<\/strong>\u2014and validate it against your organization\u2019s operational and compliance requirements using Microsoft\u2019s official documentation.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Management and Governance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,33,50],"tags":[],"class_list":["post-477","post","type-post","status-publish","format-standard","hentry","category-azure","category-management-and-governance","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/477","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=477"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/477\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=477"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=477"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=477"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}