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