Azure DDoS Protection Standard: When You Need It and How to Configure It

What Azure DDoS Network Protection Does Not Block

Azure DDoS Network Protection does not protect against HTTP floods, Slowloris attacks, or TLS exhaustion targeting your Application Gateway. Those are Layer 7 attacks. DDoS Network Protection operates at Layers 3 and 4: it absorbs volumetric attacks (UDP floods, SYN floods, amplification attacks such as DNS reflection and NTP amplification) before they saturate your virtual network's ingress capacity.

If 80% of the DDoS attacks targeting web applications are Layer 7, and you deployed DDoS Network Protection as your primary web defense, you've spent approximately $35,000 per year on protection that doesn't cover your actual attack surface. The right control for Layer 7 protection is Application Gateway WAF combined with Azure Front Door's Bot Protection and Layer 7 DDoS mitigation.

This distinction drives the entire purchase decision. Understanding the layer separation before configuring anything is the only way to avoid misaligned security spend.

DDoS Protection Tiers: Choosing the Right Level

Azure provides four DDoS protection options. Each tier has a specific use case, and the differences are not just price:

The free Infrastructure Protection tier is not nothing. Microsoft absorbs volumetric attacks targeting Azure's network fabric before they reach your VNet whether or not you have a paid plan. A 500 Gbps UDP flood against an Azure public IP is handled by Microsoft's backbone. What the basic tier doesn't provide: traffic telemetry during a mitigation event, adaptive tuning for your workload's traffic baseline, the SLA credit program, and notifications when mitigation is active.

When DDoS Network Protection Is Worth the Cost

The $2,944/month price point is defensible in four specific scenarios. Outside those scenarios, the spend is not justified: 1. You have a compliance requirement.

PCI DSS 4.0 (Requirement 6.4), FedRAMP Moderate, and several HIPAA implementation guides explicitly require documented DDoS mitigation controls with telemetry and SLA commitments. Infrastructure Protection provides none of those elements in auditable form. DDoS Network Protection provides all three: documented configuration, Azure Monitor telemetry during mitigation, and a Microsoft-backed SLA with a credit program. 2. You operate infrastructure-level services without an HTTP layer.

VPN gateways, Azure Firewall, ExpressRoute gateways, and network load balancers have public IPs but cannot benefit from Application Gateway WAF. If an attacker targets your VPN gateway's public IP with a SYN flood, WAF has no visibility into non-HTTP traffic. DDoS Network Protection absorbs that attack. Protection is most cost-effective here because these resources typically represent a small number of critical public IPs. 3. You need post-mitigation forensics for incident response.

During an active mitigation, DDoS Network Protection exposes per-protocol drop rates, packet rates, and forwarding rates as Azure Monitor metrics. Without the plan, you see nothing during a mitigation event: no evidence, no telemetry, no timeline for the post-incident review or SLA credit claim. For incident response, these metrics are required evidence. 4. You have more than 10 public IP addresses requiring protection.

At that scale, per-IP protection ($199/IP) exceeds the plan cost ($2,944/month covers up to 100 public IPs across all linked VNets). The plan is the more efficient choice for larger deployments. Do not deploy DDoS Network Protection when:

• Your only public endpoints are Application Gateway or Azure Front Door: use WAF and Front Door Bot Protection for L7, Infrastructure Protection handles L3/L4
• You're in a dev/test subscription with no compliance requirement and no sensitive public endpoints
• Your architecture routes everything through Azure Firewall DNAT and exposes only one public IP: one DDoS IP Protection license at $199/month covers it at one-fifteenth the plan cost

Configuration in Bicep

// DDoS Protection Plan: one plan per tenant, deployed in the hub subscription
resource ddosPlan 'Microsoft.Network/ddosProtectionPlans@2023-11-01' = {
  name: 'ddos-protection-plan-prod'
  location: resourceGroup().location
  properties: {}
}
// Link the plan to the hub VNet
resource vnetHub 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-hub-prod'
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    enableDdosProtection: true
    ddosProtectionPlan: {
      id: ddosPlan.id
    }
  }
}
// Link a spoke VNet (can be in a different subscription via plan ID reference)
resource vnetSpoke 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-spoke-workload'
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.1.0.0/16']
    }
    enableDdosProtection: true
    ddosProtectionPlan: {
      id: ddosPlan.id
    }
  }
}

Both enableDdosProtection: true and a valid ddosProtectionPlan.id are required. Setting the boolean without the plan reference fails silently in older API versions and produces a VNet that shows DDoS protection as "Enabled" in the portal while actually being unprotected. Validate after deployment:

az network vnet show \
  --name vnet-hub-prod \
  --resource-group rg-hub-prod \
  --query "{DDoSEnabled: enableDdosProtection, DDoSPlan: ddosProtectionPlan.id}" \
  --output table

If DDoSPlan returns null with DDoSEnabled true, the VNet is in the broken configuration and is not protected by the paid plan. This is more common than expected because the Azure portal accepts saves on a VNet with protection enabled but no plan linked. Link additional VNets to an existing plan across subscriptions:

# Get the plan resource ID from the hub subscription
PLAN_ID=$(az network ddos-protection show \
  --name ddos-protection-plan-prod \
  --resource-group rg-hub-prod \
  --query id -o tsv)
# Link a spoke VNet in a different resource group
az network vnet update \
  --name vnet-spoke-workload \
  --resource-group rg-workload \
  --ddos-protection true \
  --ddos-protection-plan $PLAN_ID

A single DDoS Protection Plan protects VNets across resource groups and subscriptions within the same Entra ID tenant. The standard enterprise architecture: one plan in the hub subscription, linked to all spoke VNets through hub-spoke peering. Each spoke team does not need their own plan.

Adaptive Protection: What It Actually Does

Adaptive Protection is the feature most prominent in Microsoft marketing, and the one least understood by teams deploying the plan. It is not a machine learning system that learns to distinguish attack traffic from normal traffic in real time. The actual mechanism:

Azure continuously monitors the baseline traffic profile for each protected public IP: average packets per second, average bytes per second, and protocol distribution across TCP, UDP, and ICMP. When an attack begins, the mitigation pipeline references that IP-specific baseline rather than relying on generic volumetric thresholds.

The practical implication: if your IP serves a workload with legitimately high UDP traffic (a game server, a media streaming origin, or a VPN gateway handling many concurrent tunnels), Adaptive Protection avoids triggering mitigation during legitimate load spikes that would fire against generic thresholds. The baseline learning window is approximately 30 days from when the VNet is first linked to the plan.

You cannot inspect or modify the adaptive baselines directly. What you can observe during an attack: the IfUnderDDoSAttack metric (0 or 1, indicating active mitigation) and PacketsDroppedDDoS. If PacketsDroppedDDoS is increasing while your application error rate is also rising, the mitigation may be dropping legitimate traffic. Open a P1 support case immediately: Microsoft's mitigation team can adjust the policy in near-real-time during an active event.

Monitoring, Metrics, and Alerts

Enable DDoS metrics on each public IP resource. Navigate to Public IP > Diagnostic Settings > Add diagnostic setting and send all categories to a Log Analytics workspace. Without this step, the metrics exist in Azure Monitor but are not queryable in KQL.

Create an alert for active DDoS mitigation:

az monitor alert create \
  --name "DDoS-Mitigation-Active-AppGW" \
  --resource-group rg-hub-prod \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-hub-prod/providers/Microsoft.Network/publicIPAddresses/pip-appgw-prod" \
  --resource-type "Microsoft.Network/publicIPAddresses" \
  --condition "avg IfUnderDDoSAttack > 0" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-group "/subscriptions/<sub-id>/resourceGroups/rg-hub-prod/providers/microsoft.insights/actionGroups/security-critical-ag" \
  --severity 0 \
  --description "Active DDoS mitigation on production App Gateway public IP: P1 response required"

KQL: correlate DDoS mitigation with application failure rate:

AzureMetrics
| where MetricName == "IfUnderDDoSAttack"
| where Maximum > 0
| project MitigationTime = TimeGenerated, Resource, ResourceGroup
| join kind=inner (
    AppRequests
    | summarize
        FailedRequests = countif(Success == false),
        TotalRequests = count()
      by bin(TimeGenerated, 1m)
) on $left.MitigationTime == $right.TimeGenerated
| project
    MitigationTime,
    Resource,
    FailedRequests,
    TotalRequests,
    FailureRate = round((toreal(FailedRequests) / toreal(TotalRequests)) * 100, 2)
| where FailureRate > 5
| order by MitigationTime desc

If mitigation is active and failure rate is near zero, the protection is working. If failure rate exceeds 5% during mitigation, the attack is either bypassing Network Protection (likely a Layer 7 attack not covered by the plan) or the mitigation is dropping legitimate traffic and requires a P1 support escalation. KQL: detect high SYN packet rates indicating a potential SYN flood:

AzureMetrics
| where MetricName == "InboundSYNPackets"
| summarize MaxSYN = max(Maximum) by bin(TimeGenerated, 5m), Resource
| where MaxSYN > 100000
| project TimeGenerated, Resource, MaxSYN
| order by TimeGenerated desc

DDoS Diagnostic Logs for SLA Credit Claims

When a mitigation event results in disruption to legitimate traffic, Microsoft's SLA provides a service credit. Claiming it requires three elements:

1. The time window when IfUnderDDoSAttack = 1 for the affected public IP
2. Evidence of legitimate traffic disruption from PacketsForwardedDDoS drop or application error rate increase during that window
3. A support case opened during or immediately after the event (not days later)

Retrieve mitigation event history:

az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-hub-prod/providers/Microsoft.Network/publicIPAddresses/pip-appgw-prod" \
  --metric "IfUnderDDoSAttack" \
  --start-time "2026-06-01T00:00:00Z" \
  --end-time "2026-06-09T00:00:00Z" \
  --interval "PT1M" \
  --output json \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
events = [d for ts in data['value'][0]['timeseries'] for d in ts['data'] if d.get('maximum', 0) > 0]
for e in events:
    print(e['timeStamp'], 'IfUnderDDoSAttack:', e['maximum'])
"

DDoS mitigation flow logs (detailed per-flow data) are retained for 30 days in the storage account the plan creates automatically. After 30 days they are deleted permanently. Configure the storage account lifecycle policy immediately after plan provisioning if compliance requires longer retention:

az storage account management-policy create \
  --account-name <ddos-flow-logs-storage-account> \
  --resource-group rg-hub-prod \
  --policy '{
    "rules": [{
      "name": "extend-ddos-log-retention",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {"blobTypes": ["blockBlob"]},
        "actions": {
          "baseBlob": {
            "tierToCool": {"daysAfterModificationGreaterThan": 30},
            "delete": {"daysAfterModificationGreaterThan": 365}
          }
        }
      }
    }]
  }'

Layering DDoS Protection with Azure Firewall and Application Gateway

DDoS Network Protection and Application Gateway WAF address different attack layers and are complementary rather than alternatives. The complete enterprise architecture layers them:

Internet
  |
  v
Azure Front Door (L7 WAF + Bot Protection + global anycast)
  |
  v
Application Gateway v2 (L7 WAF, regional, TLS termination)
  |
  v
Azure Firewall Premium (IDPS, TLS inspection, FQDN filtering)
  |
  v
Internal VNets (DDoS Network Protection plan covers all linked VNets)

DDoS Network Protection absorbs volumetric attacks before they consume the capacity of Azure Firewall and Application Gateway, preserving those resources for legitimate traffic inspection. Azure Firewall and Application Gateway then handle the application-layer attacks that DDoS Network Protection is not designed to stop.

A common misconfiguration: enabling DDoS Network Protection on VNets that contain only internal load balancers with no public IP addresses. Internal load balancers use RFC 1918 addresses and cannot be targeted by external DDoS attacks. The plan charge still applies because the VNet is linked, but no protection is being provided. Audit public IPs before linking VNets to the plan:

az network public-ip list \
  --query "[].{Name:name, RG:resourceGroup, IP:ipAddress, AssociatedTo:ipConfiguration.id}" \
  --output table

Only link VNets that contain public IP addresses receiving internet-routable traffic.

Common Deployment Mistakes

Per-VNet plans in a multi-subscription hub-spoke architecture. Each spoke team creates their own DDoS Protection Plan because they don't know about the hub plan. Result: each spoke pays $2,944/month independently. The correct architecture is one plan in the hub subscription with spoke VNets linked to it. The plan covers public IPs across all linked VNets regardless of their subscription. Not validating plan link persistence after VNet updates. Updating a VNet via Bicep without including the ddosProtectionPlan reference removes the plan link silently. If your VNet Bicep resource doesn't include the DDoS plan reference on every deployment, the link can be dropped. Include the reference in every VNet resource definition, or use an Azure Policy remediation task to continuously enforce the link. Expecting DDoS protection to cover Azure PaaS services directly. Azure App Service, Azure SQL, and Azure Cosmos DB do not have VNet-linked public IPs that the DDoS plan covers. Their protection is handled by Microsoft's infrastructure-level controls. DDoS Network Protection applies specifically to Microsoft.Network/publicIPAddresses resources in your VNets.

For the broader network security architecture context, the zero trust security guide covers how network segmentation, identity-based access, and DDoS protection fit together across the full zero trust model.

Hardening Checklist

• [ ] Architecture review completed: confirmed actual attack surface is L3/L4 volumetric before purchasing DDoS Network Protection
• [ ] Application Gateway WAF enabled for all public HTTP/HTTPS workloads: DDoS Network Protection does not block Layer 7 attacks
• [ ] Azure Front Door with Bot Protection configured for globally distributed web workloads
• [ ] VNet plan link verified post-deployment: both enableDdosProtection: true and valid ddosProtectionPlan.id on every protected VNet
• [ ] Public IP audit completed before linking VNets: no VNets with only internal IPs linked to the plan
• [ ] Diagnostic settings enabled on all protected public IP resources: streaming metrics to Log Analytics workspace
• [ ] Alert rule deployed for IfUnderDDoSAttack = 1 with Severity 0 action group and P1 SLA response
• [ ] KQL correlation query scheduled: alert when mitigation is active and application failure rate exceeds 5%
• [ ] Adaptive Protection baseline period observed: 30 days after initial VNet link before traffic patterns are fully learned
• [ ] DDoS flow log storage lifecycle policy configured: retention extended beyond the 30-day default if compliance requires it
• [ ] SLA credit claim process documented: team knows which metrics to capture and how to open a support case during a mitigation event
• [ ] Spoke VNets linked to hub subscription plan: one plan covers all linked VNets, no redundant per-VNet plans in multi-subscription architectures
• [ ] DDoS IP Protection evaluated for single-IP deployments: at $199/IP, preferable to the $2,944/month plan for fewer than 10 public IPs without compliance requirements
• [ ] Bicep templates include DDoS plan reference on every VNet resource: plan link cannot be dropped by incremental deployments