Microsoft Azure — DDoS Protection & Network Watcher

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers ddos protection & network watcher with production-ready configurations, best practices, and hands-on examples.

Why Azure DDoS Protection and Network Watcher Are Inseparable

In production, DDoS attacks are not a matter of 'if' but 'when'. Azure DDoS Protection provides always-on traffic monitoring and automatic mitigation at the network edge, but it's only half the story. Without Network Watcher, you're blind to the attack's impact on your application. Network Watcher gives you packet-level diagnostics, flow logs, and topology views that let you correlate a DDoS event with latency spikes, packet drops, or routing anomalies. Together, they form a feedback loop: DDoS Protection blocks the attack, Network Watcher tells you what happened and why. I've seen teams deploy DDoS Protection alone and then scramble during an attack because they couldn't isolate the affected subnet. Don't be that team. Integrate both from day one.

az network ddos-protection create \
  --resource-group prod-rg \
  --name prod-ddos \
  --location eastus \
  --vnets prod-vnet

az network watcher configure \
  --resource-group prod-rg \
  --location eastus \
  --enabled true

Azure DDoS Protection Tiers: Basic vs Standard – What You Actually Get

Azure DDoS Protection Basic is free and always-on, but it only protects Azure infrastructure. It's like a bouncer at the door who checks IDs but doesn't care about your VIP list. Standard costs ~$3,000/month per resource (plus data egress), but it's the only tier that adapts to your application's traffic patterns. Standard uses adaptive tuning: it learns your baseline traffic and only triggers mitigation when anomalies exceed thresholds. In production, Basic is fine for dev/test, but for any customer-facing service, Standard is non-negotiable. I've seen a startup hit by a 100 Gbps attack that Basic didn't mitigate because it only protects infrastructure, not the tenant. They lost 4 hours of uptime. Standard would have mitigated within seconds.

az network ddos-protection create \
  --resource-group prod-rg \
  --name prod-ddos-standard \
  --location eastus \
  --vnets prod-vnet \
  --protection-plan-id Standard

az network vnet update \
  --resource-group prod-rg \
  --name prod-vnet \
  --ddos-protection-plan /subscriptions/.../ddosProtectionPlans/prod-ddos-standard

Network Watcher Topology: Your First Line of Defense in Incident Response

When a DDoS attack hits, you need to know exactly which resources are affected. Network Watcher Topology gives you a real-time map of your VNet, subnets, NICs, and their relationships. In production, I use it to quickly identify if the attack is targeting a specific VM or a load balancer. Topology also shows you NSG and route table associations, which are critical for understanding if your mitigation rules are in place. Without Topology, you're guessing. I've seen teams spend 30 minutes tracing connections manually during an outage. With Topology, you can export the diagram and share it with your incident response team in seconds.

az network watcher topology \
  --resource-group prod-rg \
  --location eastus \
  --target-resource-group prod-rg \
  --output json > topology.json

cat topology.json | jq '.resources[] | {name: .name, type: .type, associations: .associations}'

NSG Flow Logs: The Forensic Evidence You Need After an Attack

NSG flow logs capture all traffic allowed or denied by Network Security Groups. They're stored in a storage account and can be queried with Log Analytics or Traffic Analytics. In production, flow logs are your best friend for post-mortem analysis. They tell you exactly which IPs were hitting your resources, at what rate, and whether they were allowed or blocked. I've used flow logs to identify a DDoS attack that was coming from a botnet of 10,000 IPs, each sending a low rate of traffic to evade threshold-based detection. Without flow logs, we would have missed it. Enable flow logs on every NSG attached to production subnets.

az network watcher flow-log create \
  --resource-group prod-rg \
  --name prod-nsg-flowlog \
  --nsg prod-nsg \
  --storage-account prodflowlogs \
  --retention 90 \
  --enabled true \
  --format-type JSON \
  --format-version 2

Connection Monitor: Proactive Health Checks for Your Application

Connection Monitor in Network Watcher lets you test connectivity from Azure VMs to any endpoint (on-premises, internet, or other Azure resources). It's like a synthetic transaction that checks latency, packet loss, and routing. In production, I use Connection Monitor to validate that my DDoS mitigation rules aren't blocking legitimate traffic. For example, after enabling DDoS Protection, I set up a Connection Monitor from a test VM to my application endpoint. If latency spikes or packets drop, I know the mitigation is too aggressive. Connection Monitor also helps during an attack: you can see if your backup region is reachable.

az network watcher connection-monitor create \
  --resource-group prod-rg \
  --name prod-conn-monitor \
  --location eastus \
  --source-resource /subscriptions/.../virtualMachines/prod-vm-01 \
  --dest-address app.contoso.com \
  --dest-port 443 \
  --protocol TCP \
  --interval 60

Packet Capture: Deep-Dive Diagnostics When Logs Aren't Enough

Sometimes flow logs and metrics aren't enough. You need to see the actual packets. Network Watcher's packet capture lets you capture traffic on a VM for up to 5 hours. In production, I use it to diagnose application-layer DDoS attacks that bypass network-level mitigation. For example, a slow HTTP POST attack that sends data at 1 byte per second won't trigger DDoS Protection, but it will tie up your application threads. Packet capture reveals the pattern. You can also use it to verify that your WAF rules are working. Packet capture is a heavy operation; use it sparingly and only when you have a hypothesis.

az network watcher packet-capture create \
  --resource-group prod-rg \
  --name prod-pcap-01 \
  --vm prod-vm-01 \
  --storage-account prodpcap \
  --time-limit 3600 \
  --filters '[{"protocol":"TCP","localPort":"443","remoteIPAddress":"0.0.0.0/0"}]'

Traffic Analytics: Turning Flow Logs into Actionable Intelligence

Raw NSG flow logs are verbose. Traffic Analytics aggregates them into a dashboard that shows top talkers, inter-VNet traffic, and geo-distribution. In production, I use Traffic Analytics to detect DDoS attacks early. For example, a sudden spike in traffic from a single country or a new IP range is a red flag. Traffic Analytics also helps with capacity planning: you can see which subnets are saturated. It's not free—it costs per GB of flow logs processed—but it's worth it for any production environment with more than 10 VMs. Without it, you're drowning in raw data.

az network watcher flow-log create \
  --resource-group prod-rg \
  --name prod-nsg-flowlog-ta \
  --nsg prod-nsg \
  --storage-account prodflowlogs \
  --retention 90 \
  --enabled true \
  --traffic-analytics true \
  --workspace /subscriptions/.../workspaces/prod-law

Automating DDoS Mitigation with Azure Policy and Network Watcher Alerts

Manual response to DDoS attacks is too slow. You need automation. Use Azure Policy to enforce DDoS Protection Standard on all VNets. Then, set up Network Watcher alerts on flow logs or metrics to trigger an Azure Function that blocks offending IPs via NSG rules. In production, I've built a pipeline: when DDoS Protection detects an attack, it sends a metric to Azure Monitor, which triggers a Logic App that adds a deny rule to the NSG. This reduces mitigation time from minutes to seconds. But be careful: aggressive automation can block legitimate traffic. Always test with a canary.

$rule = New-AzMetricAlertRuleV2Criteria `
  -MetricName "DDoSProtectionTriggered" `
  -TimeAggregation Total `
  -Operator GreaterThan `
  -Threshold 0

Add-AzMetricAlertRuleV2 `
  -ResourceGroupName prod-rg `
  -Name "ddos-attack-alert" `
  -WindowSize 00:05:00 `
  -Frequency 00:01:00 `
  -TargetResourceId /subscriptions/.../virtualNetworks/prod-vnet `
  -Condition $rule `
  -ActionGroupId /subscriptions/.../actionGroups/prod-ddos-action

Cost Optimization: Running DDoS Protection and Network Watcher Without Breaking the Bank

DDoS Protection Standard costs ~$3,000/month per protected resource (VM, LB, etc.). Network Watcher features like flow logs and Traffic Analytics add storage and ingestion costs. In production, you can optimize by only enabling Standard on critical VNets, not all. Use Basic for dev/test. For Network Watcher, enable flow logs only on NSGs attached to production subnets, and set retention to 30-90 days. Traffic Analytics is expensive; enable it only on high-traffic NSGs. I've seen teams spend $10k/month on flow logs because they enabled it on every NSG. Be selective.

# Estimate DDoS Protection Standard cost for 10 VMs
az cost management query \
  --scope /subscriptions/... \
  --timeframe MonthToDate \
  --dataset aggregation='{"totalCost":{"name":"Cost","function":"Sum"}}' \
  --dataset grouping='{"type":"Dimension","name":"ServiceName"}' \
  --query 'rows[?contains([0],"DDoS Protection")]'

Real-World Incident Response Playbook: DDoS Attack with Network Watcher

Here's a playbook I've used in production. Step 1: DDoS Protection triggers an alert. Step 2: Check Network Watcher Topology to identify affected resources. Step 3: Analyze NSG flow logs in Traffic Analytics to see source IPs and traffic patterns. Step 4: If attack is application-layer, start a packet capture on the target VM. Step 5: Use Connection Monitor to verify failover to DR region. Step 6: Automatically block offending IPs via NSG rules (if not already). Step 7: After attack, review packet capture and flow logs for forensic analysis. Step 8: Tune DDoS Protection thresholds if needed. This playbook has saved us hours of downtime.

# Step 1: Check DDoS Protection metrics
az monitor metrics list \
  --resource /subscriptions/.../virtualNetworks/prod-vnet \
  --metric "DDoSProtectionTriggered" \
  --interval 1m

# Step 2: Get topology
az network watcher topology --resource-group prod-rg --location eastus

# Step 3: Query flow logs for top talkers
az monitor log-analytics query \
  --workspace prod-law \
  --query "FlowLogs_CL | summarize count() by SourceIP_s | top 10 by count_"

Integrating with Azure Firewall and WAF for Layered Defense

DDoS Protection handles volumetric attacks, but application-layer attacks need a Web Application Firewall (WAF) and Azure Firewall for stateful inspection. In production, I place Azure Firewall behind DDoS Protection, then route traffic through WAF. Network Watcher helps validate this chain: use Connection Monitor to test end-to-end connectivity, and flow logs to see traffic passing through each hop. I've seen teams rely solely on DDoS Protection and get hit by a SQL injection attack that bypassed it. Layer your defenses. Network Watcher is the glue that lets you see the entire path.

az network watcher show-next-hop \
  --resource-group prod-rg \
  --vm prod-vm-01 \
  --source-ip 10.0.0.4 \
  --dest-ip 203.0.113.5 \
  --nic prod-nic-01

az network watcher show-security-group-view \
  --resource-group prod-rg \
  --vm prod-vm-01 \
  --nic prod-nic-01

Monitoring and Alerting: The Final Piece of the Puzzle

You can't fix what you don't measure. Set up Azure Monitor alerts on DDoS Protection metrics (e.g., DDoSProtectionTriggered, InboundPacketsDropped) and Network Watcher metrics (e.g., ConnectionMonitorLatency, FlowLogBytes). In production, I have a dashboard that shows real-time DDoS status, top talkers from Traffic Analytics, and connection health from Connection Monitor. Alerts are routed to PagerDuty with severity levels. Without this, you'll only know about an attack when customers complain. Proactive monitoring is the difference between a 5-minute outage and a 5-hour one.

$dashboard = @{
  "properties" = @{
    "lenses" = @{
      "0" = @{
        "order" = 0
        "parts" = @{
          "0" = @{
            "position" = @{ "x" = 0; "y" = 0; "rowSpan" = 2; "colSpan" = 2 }
            "metadata" = @{
              "type" = "Extension/HubsExtension/PartType/MonitorChartPart"
              "settings" = @{
                "content" = @{
                  "options" = @{
                    "chart" = @{
                      "metrics" = @(
                        @{ "resourceMetadata" = @{ "id" = "/subscriptions/.../virtualNetworks/prod-vnet" }; "name" = "DDoSProtectionTriggered"; "aggregationType" = 1 }
                      )
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

New-AzResourceGroupDeployment -ResourceGroupName prod-rg -TemplateObject $dashboard

DDoS IP Protection: Pay-Per-Protected-IP Model

Azure DDoS Protection now offers two tiers: DDoS Network Protection (per-VNet, ~$3,000/month per resource) and DDoS IP Protection (per-public-IP, pay-as-you-go). DDoS IP Protection is a newer, more flexible model where you enable protection on individual public IP resources rather than an entire VNet. This is ideal for scenarios where you only need to protect specific endpoints, not every resource in a VNet. The core protection features are identical: adaptive real-time tuning, always-on monitoring, and L3/L4 mitigation. However, DDoS IP Protection differs in value-added services — it does not include DDoS Rapid Response (DRR) support, cost protection, or WAF discounts. Use DDoS IP Protection for: dev/test environments where full Network Protection is cost-prohibitive, protecting specific public IPs in a shared VNet, or burstable workloads that need baseline DDoS defense. For production customer-facing services, DDoS Network Protection remains the recommended tier due to the included DRR support and cost guarantees. In production, consider a hybrid approach: enable DDoS Network Protection on critical VNets and DDoS IP Protection on less critical endpoints. Both tiers can coexist in the same subscription. Monitor costs via Azure Cost Management — DDoS IP Protection billing is based on the number of protected IP addresses.

# Enable DDoS IP Protection on a public IP address
az network public-ip ddos-protection enable \
  --resource-group prod-rg \
  --name my-public-ip \
  --protection-mode Enabled

# Verify protection status
az network public-ip show \
  --resource-group prod-rg \
  --name my-public-ip \
  --query "{DdosSettings:ddosSettings.protectionMode, DdosPlan:ddosSettings.ddosProtectionPlan}"

Network Watcher Rule Impact Analyzer: Safe NSG Changes

Making changes to Network Security Group (NSG) rules or security admin rules in production is risky — a misconfigured deny rule can cause an outage. The Network Watcher Rule Impact Analyzer, now generally available (May 2026), lets you assess the potential impact of NSG or security admin rule changes on live network traffic before applying them. It analyzes your current traffic patterns and predicts which flows would be affected by the proposed rule changes. This includes both explicit allows/denies and implicit default-deny rules. In production, integrate Rule Impact Analyzer into your CI/CD pipeline: before deploying NSG changes via ARM/Bicep/Terraform, run the analyzer to validate that the new rules won't break legitimate traffic. Common scenarios: adding a deny rule for a suspicious IP range, changing a service tag, or modifying port ranges. The analyzer shows affected source/destination IPs, protocols, and ports so you can make informed decisions. Without this tool, teams often discover NSG misconfigurations during incident response. Use it proactively as a pre-deployment validation step.

# Start NSG rule impact analysis
az network watcher nsg-diagnostic \
  --resource-group prod-rg \
  --location eastus \
  --target-resource /subscriptions/.../networkSecurityGroups/prod-nsg \
  --direction Inbound \
  --protocol TCP \
  --source-address-prefixes 10.0.0.0/8 \
  --destination-port-ranges 443

# Analyze proposed rule change via ARM template
# Use Azure CLI to validate before deployment
az deployment group what-if \
  --resource-group prod-rg \
  --template-file nsg-update.json \
  --parameters @nsg-params.json

Continuous Packet Capture: Persistent Network Monitoring

Standard Network Watcher packet capture sessions have a time limit (up to 5 hours) and stop when the file size limit is reached. For diagnosing intermittent or long-tail network issues, Continuous Packet Capture (preview) provides a ring buffer-based mechanism that runs over extended durations — up to 7 days. The ring buffer keeps the most recent data by overwriting old captures when the size limit is reached. You configure the maximum bytes per packet, total files, bytes per file, and session duration. For example, you can run a continuous capture for 7 days with 100 MB per file and up to 10,000 files, capturing only TCP traffic on port 443. This is ideal for: debugging sporadic connectivity issues that occur once a week, capturing attack patterns during low-and-slow DDoS attacks, or analyzing application behavior during peak load cycles. When the issue occurs, you can extract the relevant segment from the ring buffer before it's overwritten. Continuous capture uses the same Network Watcher Agent extension. Performance impact is minimal — limit capture to the specific 5-tuple you need to avoid CPU spikes. Set up alerts to trigger a full packet capture dump when a specific condition is met (e.g., latency > 500ms).

# Start continuous packet capture (preview)
az network watcher packet-capture create \
  --resource-group prod-rg \
  --name prod-continuous-pcap \
  --vm prod-vm-01 \
  --storage-account prodpcap \
  --time-limit 604800 \
  --file-count 100 \
  --file-size 104857600 \
  --max-bytes-per-packet 0 \
  --filters '[{"protocol":"TCP","localPort":"443","remoteIPAddress":"0.0.0.0/0"}]' \
  --capture-type Continuous

# Check capture status
az network watcher packet-capture show \
  --resource-group prod-rg \
  --name prod-continuous-pcap \
  --query "{Status:provisioningState, BytesCaptured:totalBytesPerSession, StartTime:timeStamp}"