Azure DDoS Protection Standard should be enabled

What does the recommendation "Azure DDoS Protection Standard should be enabled" check?

Flags any virtual network that contains a subnet belonging to an Application Gateway with a public IP but is not linked to a DDoS Network Protection plan. The scope is narrow on purpose: it only looks at VNets fronting an Application Gateway public endpoint, so it does not assess standalone public IPs, individual VMs or load balancers outside such a VNet, and it does not check whether the always-on free DDoS Infrastructure Protection is working. It is a configuration check on plan association, not a measure of whether an attack is currently being mitigated.

Why does "Azure DDoS Protection Standard should be enabled" matter?

Every Azure subscription gets free network-layer DDoS Infrastructure Protection, but that tier offers no per-resource tuning, no attack telemetry and no cost guarantee. A public Application Gateway is a prime volumetric target, and without a DDoS Network Protection plan an L3 or L4 flood can saturate the endpoint and take the application offline before anyone notices. The Standard plan adds adaptive tuning to your real traffic baseline, attack alerts, mitigation reports and cost protection that credits the scale-out charges an attack triggers. The business consequence of leaving it off is a public front door that can be knocked down cheaply, with no evidence afterwards of what hit you.

How do I fix "Azure DDoS Protection Standard should be enabled"?

1. Create a DDoS Network Protection plan once per organisation: 'az network ddos-protection create --resource-group <rg> --name <plan-name>'. A single plan can cover virtual networks across subscriptions in the same Microsoft Entra tenant, so you do not need one per VNet.
2. Associate the virtual network that hosts the Application Gateway: 'az network vnet update --resource-group <rg> --name <vnet> --ddos-protection-plan <plan-name> --ddos-protection true'. In Bicep, set 'enableDdosProtection: true' on the virtual network resource and reference the plan ID under 'ddosProtectionPlan.id'.
3. To enforce this at scale, assign the built-in policy by looking up its definition ID rather than hardcoding a GUID: 'pid=$(az policy definition list --query "[?displayName=='Virtual networks should be protected by Azure DDoS Protection'].name" -o tsv)' then 'az policy assignment create --name require-ddos --policy "$pid" --scope <scope>'. Note that this Modify-effect policy evaluates every VNet in scope, broader than the recommendation's focus on VNets fronting an Application Gateway, so expect it to flag VNets the recommendation itself does not.

# Create one shared DDoS protection plan, then bring the internet-facing
# virtual networks under it. A single plan can be shared across every
# subscription in the tenant; its fixed monthly charge covers up to 100
# public IP addresses.
RG=net-hub-rg
LOC=uksouth
az network ddos-protection create \
  --resource-group "$RG" \
  --name ddos-plan-shared \
  --location "$LOC"

for vnet in vnet-payments-prod vnet-web-prod; do
  az network vnet update \
    --resource-group "$RG" \
    --name "$vnet" \
    --ddos-protection true \
    --ddos-protection-plan ddos-plan-shared
  echo "$vnet: associated with shared DDoS Network Protection plan"
done

# Stand up a Premium Azure Firewall policy in the hub with IDPS and
# threat intelligence both in Deny mode (deploy the firewall + route
# 0.0.0.0/0 to its private IP from each spoke to complete the path).
az network firewall policy create \
  --resource-group "$RG" \
  --name hub-fw-policy \
  --location "$LOC" \
  --sku Premium \
  --threat-intel-mode Deny \
  --idps-mode Deny

# Ratchet it shut: assign the built-in policy that requires DDoS protection
# on virtual networks. Look the definition up by its exact display name so
# no GUID is hardcoded.
pid=$(az policy definition list \
  --query "[?displayName=='Virtual networks should be protected by Azure DDoS Protection'].name" -o tsv)
az policy assignment create \
  --name require-vnet-ddos \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"