Lesson 22 — Azure Site Recovery & Network Watcher

Domain 5 — Monitor & Maintain AZ-104: 10–15% ~30 min Prereq: Lesson 21 — Azure Backup

Why You Need This

Azure Backup recovers from data loss — a deleted file, a corrupted database, an accidental VM deletion. Azure Site Recovery answers a harder question: what happens if the entire Azure region goes down? ASR continuously replicates your VMs to a secondary region so that a regional failure becomes a planned failover with minutes of downtime rather than a catastrophic loss.

Network Watcher completes the operational picture. Once your infrastructure is running and protected, you need tools to diagnose network issues in real time. NSG flow analysis, routing verification, and end-to-end connectivity monitoring are all in Network Watcher's toolbox — and several of these tools appear directly in AZ-104 scenario questions.

Part 1 — Azure Site Recovery

ASR purpose and positioning

Azure Site Recovery (ASR) is Azure's Disaster Recovery (DR) service. It continuously replicates Azure VMs (or on-premises VMs and physical servers) to a secondary Azure region, enabling failover with near-zero data loss when the primary region becomes unavailable.

Azure BackupAzure Site Recovery
Purpose Operational recovery — restore from accidental deletion, corruption, ransomware Disaster recovery — survive regional outages
RPO Up to 24 hours (daily backup frequency) As low as seconds (crash-consistent); ~1 hour (app-consistent)
RTO Minutes (instant restore) to hours (vault restore, large disks) Minutes (failover starts VMs in secondary region)
Replication Scheduled snapshots Continuous, near-real-time disk change replication
Target Recovery Services Vault Secondary Azure region (or secondary site)
Vault type Recovery Services Vault Also uses Recovery Services Vault — but as an ASR vault, not a backup vault
The key exam differentiator Azure Backup = data recovery (recover from what someone did). Azure Site Recovery = infrastructure recovery (recover from where you are). If the exam scenario mentions "regional outage", "RPO of minutes", or "failover" — the answer is ASR. If it mentions "deleted file", "corrupted database", or "accidental VM deletion" — the answer is Azure Backup.

How Azure-to-Azure ASR Works

Architecture components

When you enable replication for an Azure VM, ASR creates and manages several resources automatically:

Source Region (e.g. East US) ├─ Source VM (running production workload) │ └─ Mobility Service agent (auto-installed by ASR) └─ Cache Storage Account (temporary staging for disk changes) Target Region (e.g. West US) ├─ Replica Managed Disks (continuously updated from cache) ├─ Replica VM (stopped — started only on failover) ├─ Target VNet (must be pre-created; configured via network mapping) └─ Recovery Services Vault (orchestrates replication and failover)

Replication flow

  1. The Mobility Service agent is installed on the source VM (ASR installs it automatically when you enable replication). It intercepts all disk writes.
  2. Changes are written to a cache storage account in the source region.
  3. ASR reads from the cache and asynchronously replicates changes to the replica managed disks in the target region.
  4. ASR creates recovery points at defined intervals: crash-consistent every 5 minutes, app-consistent (VSS) every 1 hour (configurable in the replication policy).
  5. The replica VM exists in the target region but is in a stopped/deallocated state — you pay for disk storage but not compute until failover.
Network mapping is mandatory before failover ASR requires you to map source VNets to target VNets before the first failover. If network mapping is not configured, the failed-over VM will have no network connectivity in the target region. Create target VNets before enabling replication, then configure the mapping in the ASR vault.

Replication Policy

The replication policy controls how ASR creates and manages recovery points. Key parameters:

ParameterDefaultRangeNotes
RPO warning threshold 30 minutes Minutes Alert fires if replication lag exceeds this threshold — does not stop replication
Crash-consistent recovery point Every 5 minutes Fixed Always retained; frequency is not configurable
App-consistent recovery point frequency Every 4 hours 1–12 hours Uses VSS — higher frequency increases performance impact on source VM
Recovery point retention 24 hours Up to 72 hours How far back you can failover to — the history of recovery points retained

Failover Types

ASR provides three distinct failover operations, each appropriate for different scenarios. Choosing the wrong one in a real incident can cause unnecessary data loss or disrupt the production environment.

Failover typeSource VM stateData lossWhen to use
Test Failover Continues running — not affected None (test network is isolated) DR drills, compliance validation, verifying the DR plan. Always test before a real incident.
Planned Failover Must be shut down before failover Zero — replication fully synchronises before failover Planned maintenance, region migrations, or any scenario where you control the timing
Unplanned Failover Unavailable (region down) Potential loss up to the last recovery point Actual disaster — the primary region is unavailable and you must fail over immediately
Test failover is the safe DR drill mechanism Test failover spins up replica VMs in an isolated test network that has no connectivity to the production environment or the replication process. Production continues running. The replication continues. The test VMs are spun up in isolation and deleted after the test. Running a test failover does not commit the failover — it is entirely non-destructive. This is the correct mechanism for DR drills, not a real failover.

Failover process for unplanned failover

  1. In the ASR vault, navigate to Replicated items → select the VM → Failover
  2. Choose the recovery point to fail over to (latest processed, latest app-consistent, or a specific point in time)
  3. Confirm you want to shut down the source VM before failover (if still accessible)
  4. ASR starts the replica VM in the target region and connects it to the target VNet (via network mapping)
  5. Update DNS to point at the new VM's IP address in the target region
  6. Validate the application in the target region
  7. Click "Commit" to finalise the failover — this discards old recovery points and severs the relationship with the source

Failback and Recovery Plans

Failback

After a failover, your production workload is now running in the secondary region. Once the primary region is restored and stable, you fail back: you reverse-replicate from the secondary region back to the primary, then perform a planned failover back to primary. ASR supports this reprotect and failback workflow natively.

Recovery plans

A recovery plan orchestrates the failover of a multi-VM application in a defined sequence with automated steps between groups. This is essential for multi-tier applications where the order of failover matters.

For a classic 3-tier web application, the recovery plan sequence would be:

Group 1 — Database tier (SQL Server must be up before app tier starts) └─ Wait step: 2 minutes for SQL to initialise Group 2 — Application tier (API servers — depend on DB being ready) └─ Azure Automation runbook: run health check script Group 3 — Web / presentation tier (only start after app tier is healthy)

Recovery plans can include:

  • Azure Automation runbooks — for complex pre/post steps (update DNS, warm up caches, disable traffic manager endpoints)
  • Manual action steps — checkpoints requiring human confirmation before proceeding
  • Wait steps — timed delays between groups
Recovery plans for exam scenarios When the exam describes a 3-tier application and asks how to ensure the database is available before the web tier starts during failover, the answer is a recovery plan with group ordering. Recovery plans are the orchestration layer that makes multi-tier ASR practical.

RTO and RPO for ASR

MetricValue for ASRNotes
RPO Typically 15–30 seconds for crash-consistent; up to 1 hour for app-consistent Measured from last recovery point to failover time. Not the same as replication lag — actual RPO depends on how recently a recovery point was created.
RTO Minutes for the VM to start; additional time for DNS propagation and application warm-up VM start time is typically 1–5 minutes. Total application RTO depends on application startup time and DNS TTL.

Part 2 — Azure Network Watcher

What is Network Watcher?

Azure Network Watcher is a regional service providing monitoring, diagnostics, and logging capabilities for Azure virtual networks. It must be enabled per region — it is not a global service. When you create a VNet in a region, Azure often auto-enables Network Watcher for that region, but it is best practice to verify this explicitly.

Regional scope Network Watcher tools operate within a single region. To diagnose network issues in East US, you use the East US Network Watcher. There is no cross-region Network Watcher instance — each region has its own, stored in the NetworkWatcherRG resource group.

Network Watcher Tools Reference

ToolWhat it doesWhen to use it
IP Flow Verify Tests whether a specific traffic flow (source IP, source port, destination IP, destination port, protocol, direction) would be allowed or denied by the NSG rules on a VM's NIC. Returns the specific NSG rule responsible for the decision. First-line NSG troubleshooting. "Why can't I connect to port 443 on this VM?" — run IP Flow Verify before reading NSG rules manually.
Next Hop Shows the effective next hop for traffic leaving a VM toward a destination IP — based on system routes, UDRs (User-Defined Routes), and BGP routes. Returns hop type (VirtualNetworkGateway, Internet, VirtualAppliance, None) and the route table entry. Diagnosing routing issues. "Traffic should go through the firewall NVA but it's being dropped." — Next Hop reveals if a UDR is sending it to None (blackhole) instead.
Effective Security Rules Displays the merged, prioritised list of NSG rules actually applied to a VM's NIC — combining both the NIC-level NSG and the subnet-level NSG in effective order. Understanding the full security posture of a VM when multiple NSGs are applied. Covered extensively in Lesson 15.
VPN Diagnostics Runs diagnostics against a VPN Gateway or VPN connection. Checks IKE negotiation logs, tunnel status, and BGP routes. Results are stored in a Storage Account blob. VPN tunnel is down or flapping. Connection is established but BGP routes are not being exchanged.
Connection Monitor Continuously monitors TCP/HTTP connectivity between a source endpoint (Azure VM, on-premises agent) and a destination (VM, URL, IP address). Provides reachability status, round-trip latency, topology view, and alert integration. Tests run on a configurable schedule. Ongoing SLA monitoring for critical connections. Validates private endpoint connectivity. Tests cross-region reachability. Provides latency baselines and alerts when connectivity degrades.
Packet Capture Captures network packets from a VM's NIC to a Storage Account blob or local file. No agent installation required — done at the Azure host level via a VM extension. Supports capture filters (IP, port, protocol). Deep packet analysis for unexplained application failures. Protocol debugging when higher-level tools are inconclusive. Requires a storage account to store captures.
NSG Flow Logs Enables per-NSG logging of every allowed and denied connection (5-tuple: source IP, source port, destination IP, destination port, protocol) to a Storage Account. V2 logs also include bytes and packet counts. Managed through Network Watcher in the portal. Security audit trails. Traffic volume analysis. Identifying which IPs are communicating with which resources. Required input for Traffic Analytics.
Traffic Analytics Processes NSG Flow Logs through a Log Analytics workspace to produce visualised dashboards: top talkers, allowed vs. denied flow distribution, geo-mapped traffic origins, hot spots, and anomaly detection. Macro-level network traffic visibility. Security reviews. Identifying unexpected cross-region traffic or public internet ingress patterns at scale.

IP Flow Verify — The NSG Diagnostic Tool

IP Flow Verify is the most frequently used Network Watcher tool for day-to-day Azure administration. It answers the exact question NSG troubleshooting always starts with: "Is this specific connection being blocked, and by which rule?"

How to use it

In the Azure portal, navigate to Network Watcher → IP Flow Verify, then specify:

  • Subscription, Resource Group, VM, NIC: the target VM's network interface
  • Direction: Inbound or Outbound
  • Protocol: TCP or UDP
  • Local port: the port on the VM's NIC
  • Remote IP address: source IP (inbound) or destination IP (outbound)
  • Remote port: source port (inbound) or destination port (outbound)

IP Flow Verify evaluates the effective NSG rules (NIC-level and subnet-level) and returns:

  • Access: Allow or Deny
  • Rule name: the specific NSG rule that made the decision (e.g. DenyAllInbound, Port_8080)
  • NSG name and resource group: which NSG contains the rule
IP Flow Verify vs. Effective Security Rules IP Flow Verify tests a specific hypothetical traffic flow and returns a binary allow/deny with the responsible rule — it simulates a packet. Effective Security Rules shows you the complete merged ruleset as a list. Use IP Flow Verify when you know the specific flow you want to test. Use Effective Security Rules when you want to audit the full NSG configuration for a VM.

Next Hop — Routing Diagnostics

Next Hop diagnoses routing issues by showing the effective route for a specific source VM and destination IP combination. Azure evaluates system routes, UDRs, and BGP-advertised routes to determine the effective next hop.

Common Next Hop types and what they mean

Next Hop typeMeaningTypical scenario
Internet Traffic exits to the public internet via Azure's default internet gateway Expected for public endpoint destinations
VirtualNetwork Traffic stays within the VNet (direct routing to another VM in the same VNet) Expected for intra-VNet communication
VirtualNetworkGateway Traffic is routed through a VPN or ExpressRoute Gateway Expected for on-premises bound traffic via S2S VPN
VirtualAppliance Traffic is directed to a Network Virtual Appliance (NVA) — Azure Firewall or third-party firewall VM Expected in hub-spoke topologies with forced tunnelling
None No valid route — traffic is blackholed and dropped Problem indicator — a misconfigured UDR is sending traffic to a non-existent next hop
None means blackhole When Next Hop returns None, traffic to that destination is silently dropped. This is almost always caused by a UDR that routes traffic to a next hop IP address that is unreachable, deleted, or on a deallocated NVA. Fix the UDR to point to the correct NVA IP, or delete the UDR to fall back to system routes.

Connection Monitor — Continuous Connectivity Testing

Connection Monitor is distinct from the point-in-time diagnostic tools (IP Flow Verify, Next Hop). It runs continuously on a schedule, testing TCP or HTTP connectivity between defined source and destination endpoints. This makes it appropriate for ongoing SLA validation, not just one-time troubleshooting.

Connection Monitor architecture

  • Sources: Azure VMs with the Network Watcher agent extension installed, or on-premises machines with the Log Analytics agent
  • Destinations: Azure VMs (by NIC), Azure service endpoints, public URLs, or IP addresses with specific ports
  • Test frequency: every 30 seconds to 5 minutes
  • Metrics collected: checks failed (%), round-trip latency (ms), topology path

Use cases

  • Private endpoint validation: continuously prove that your Azure SQL private endpoint is reachable from the application subnet — and alert immediately if it is not
  • Cross-region reachability: verify that VNet peering between East US and West US is operational
  • Baseline SLA monitoring: document the normal latency between your app tier and database tier, and alert when it exceeds threshold
  • Third-party SaaS connectivity: continuously verify outbound connectivity to external APIs from your VMs
Connection Monitor vs. a simple ping A ping is a one-time manual test. Connection Monitor runs automatically every 30–300 seconds, logs results to a Log Analytics workspace, provides topology visualisation showing the exact path of the connection, generates Azure Monitor alerts when connectivity drops, and gives you SLA reporting over time. These capabilities make Connection Monitor appropriate for production monitoring, not just ad-hoc troubleshooting.

NSG Flow Logs and Traffic Analytics

NSG Flow Logs and Traffic Analytics form a traffic observability pipeline. They were covered in Lesson 15 from an NSG perspective — here we focus on the Network Watcher management layer.

NSG Flow Logs

Enable per NSG. Each allowed or denied connection generates a log entry containing the 5-tuple (source IP, source port, destination IP, destination port, protocol), direction, action, and (in V2) byte and packet counts. Logs are written to a Storage Account in JSON format.

Version 2 is the current standard — it adds throughput data (bytes/packets) that V1 lacks. Always configure V2 for new deployments.

Traffic Analytics

Traffic Analytics processes NSG Flow Log data through Log Analytics to produce visualised intelligence. It aggregates flows at configurable intervals (10 or 60 minutes) and produces:

  • Top talkers (source/destination pairs by volume)
  • Geo-mapped traffic origin dashboards
  • Allowed vs. denied flow ratios
  • Hot spots — workloads receiving the most traffic
  • Malicious IP detection via Microsoft Threat Intelligence integration
Traffic Analytics requires a Log Analytics workspace Enabling Traffic Analytics requires routing NSG Flow Logs to a Log Analytics workspace. There is an additional per-GB processing cost on top of the Log Analytics ingestion cost. For large environments with many NSGs, this can be significant — evaluate against the observability value before enabling on every NSG in the environment.

Check Your Understanding

Click any option to see immediate feedback.

1. A critical application with an RPO requirement of 2 minutes is running on Azure VMs. Which service is the correct solution?

Azure Backup supports only daily or weekly backup schedules for VMs — it cannot meet a 2-minute RPO. Azure Site Recovery provides continuous replication with crash-consistent recovery points created every 5 minutes, resulting in RPO typically measured in seconds to low minutes. ASR is designed for disaster recovery with tight RPO requirements; Azure Backup is designed for operational recovery from accidental loss or corruption.

2. Your team wants to run a DR drill to validate the ASR failover configuration without affecting production workloads or the ongoing replication process. Which failover type should you use?

Test Failover is the purpose-built DR drill mechanism in ASR. It spins up replica VMs in an isolated VNet that has no connectivity to the production environment, the source VMs continue running, and replication continues uninterrupted. After the drill, you clean up the test VMs. Test Failover is non-destructive and should be run at least quarterly to validate your DR plan.

3. You are configuring ASR for a 3-tier application: web servers, application servers, and SQL Server. How do you ensure that during failover, the SQL Server VMs are started before the application servers, and application servers before the web servers?

ASR Recovery Plans are the built-in orchestration mechanism for multi-VM failover ordering. You define groups (Group 1, Group 2, Group 3) and assign VMs to each group. ASR fails over Group 1, waits for all VMs in that group to start, then proceeds to Group 2, and so on. Groups can also include Azure Automation runbook steps and manual confirmation checkpoints between groups.

4. An engineer reports they cannot connect from their VM (10.1.0.4) to a web server VM (10.1.1.10) on port 443. You need to quickly determine whether an NSG rule is blocking the connection and which rule it is. Which Network Watcher tool do you use?

IP Flow Verify is the correct tool for this exact scenario. You specify the target VM (10.1.1.10's NIC), the direction (inbound), source IP (10.1.0.4), port 443, and protocol TCP. It returns "Allow" or "Deny" and the specific NSG rule name responsible. This is far faster than manually reading all NSG rules. Connection Monitor would work for ongoing monitoring but requires setup time and does not immediately return which rule is responsible.

5. Traffic from an application VM is not reaching the Azure Firewall NVA as expected — it appears to be going directly to the internet instead. Which Network Watcher tool identifies the cause?

Next Hop directly answers routing questions. If a UDR is supposed to route traffic through the firewall NVA (next hop type: VirtualAppliance) but the UDR is missing or misconfigured, Next Hop will return "Internet" (falling back to system route) or "None" (blackhole). The output includes the specific route table entry responsible, pointing you directly to the UDR that needs fixing.

6. You need to continuously monitor the TCP connectivity between your application VMs in East US and your Azure SQL private endpoint, with automatic alerting if connectivity drops and SLA reporting over 30 days. Which tool provides this?

Connection Monitor is the correct solution for continuous end-to-end connectivity monitoring with SLA reporting. It tests TCP connectivity on a schedule (down to every 30 seconds), logs results to Log Analytics, generates topology diagrams showing the full path, and integrates with Azure Monitor alerts. It provides the reachability percentage and latency metrics needed for 30-day SLA reporting. IP Flow Verify and NSG Flow Logs are point-in-time or historical tools — they cannot provide continuous proactive monitoring.
Primary source for this lesson About Azure Site Recovery — Microsoft Learn

For Network Watcher, the companion reference is the Azure Network Watcher overview. Walk through the IP Flow Verify and Next Hop quickstarts in the portal against a test VM — these tools require hands-on practice to develop the muscle memory for real incident response.

Questions for your teacher (the AI agent)
This lesson covered ASR for disaster recovery and Network Watcher for network diagnostics. Go deeper on:
  • Walk me through the complete ASR setup process for an Azure-to-Azure replication, including pre-creating target VNets and configuring network mapping.
  • What is the difference between crash-consistent and app-consistent recovery points in ASR, and how do I tune the replication policy for a SQL Server workload?
  • How do I configure Traffic Analytics to identify unexpected internet ingress flows across all VNets in my subscription?
  • Can I use ASR to migrate a VM from one Azure region to another permanently, and if so, what is the migration procedure vs. a DR failover?
Coming up: Lesson 23 — Microsoft Defender for Cloud With monitoring, backup, and DR in place, the next lesson focuses on security posture management. Defender for Cloud provides a unified security score across all your Azure resources, identifies misconfigurations and vulnerabilities, and integrates with Microsoft Defender extended detection and response (XDR). We'll cover secure score, security recommendations, workload protection plans, and regulatory compliance dashboards.