VNet Has No DDoS Protection: Securing Azure Virtual Networks

Azure gives every public endpoint a basic level of DDoS defense for free, but that baseline is shared infrastructure protection, not a guarantee for your specific workloads. The network_noddos check looks for Virtual Networks that have no DDoS Network Protection plan attached. If your VNet hosts public IPs serving real traffic, that gap is worth closing.

---

What this check detects

The check inspects each Azure Virtual Network in scope and reports any VNet that is not associated with a DDoS Protection Plan (the tier Microsoft now calls DDoS Network Protection, formerly DDoS Standard). When a VNet has no plan attached, the public IP resources inside it fall back to DDoS Infrastructure Protection, the free default.

The distinction between the free and paid tiers matters because they protect different things:

• Infrastructure Protection (free): Defends the Azure platform as a whole. It only kicks in when an attack threatens the broader fabric, not necessarily when your single application is being hammered.
• Network Protection (paid): Tuned to your application's traffic patterns, with always-on monitoring, automatic mitigation triggered by your actual baseline, attack telemetry, and a financial SLA.

---

Why it matters

A volumetric DDoS attack does not need to breach anything. It just needs to send more traffic than your endpoint can absorb. Without a tuned mitigation policy, the free tier may let a large flood reach your load balancer, application gateway, or VM before the platform decides to intervene.

Here is what that looks like in practice:

• Public APIs and web apps go dark. A SYN flood or UDP reflection attack saturates your public IP, and legitimate users get timeouts. Revenue-generating endpoints become unreachable.
• Autoscaling becomes a weapon against you. If your app scales on request volume, attack traffic can trigger massive scale-out. You absorb the attack but get a five-figure compute bill for the privilege.
• Collateral damage on shared subnets. An attack aimed at one public IP can degrade other resources sharing the same VNet path.

The free tier has no SLA, no per-application tuning, and no detailed attack analytics. When an incident hits at 2 a.m., the difference between "we have Azure Monitor metrics showing the mitigation in progress" and "the site is down and we have no idea why" is exactly the difference this check is pointing at.

---

How to fix it

Remediation is two steps: create a DDoS Protection Plan, then associate your VNet with it. A single plan can protect up to 100 public IP resources across multiple VNets in the same region or peered regions, so you usually create one plan per environment, not one per VNet.

Option 1: Azure CLI

Create the plan once:

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

Then attach it to an existing VNet. Grab the plan ID and update the VNet:

PLAN_ID=$(az network ddos-protection show \
  --resource-group rg-network-prod \
  --name ddos-plan-prod \
  --query id -o tsv)

az network vnet update \
  --resource-group rg-app-prod \
  --name vnet-app-prod \
  --ddos-protection-plan "$PLAN_ID" \
  --ddos-protection true

The --ddos-protection true flag enables protection on the VNet, and --ddos-protection-plan binds it to your plan. Both are required.

Option 2: Azure Portal

1. Search for DDoS protection plans and click Create. Pick the resource group and region, name it, then create.
2. Navigate to your Virtual Network.
3. Under Settings, select DDoS protection.
4. Choose Network protection, then select the plan you created.
5. Click Save.

Option 3: Terraform

resource "azurerm_network_ddos_protection_plan" "prod" {
  name                = "ddos-plan-prod"
  resource_group_name = azurerm_resource_group.network.name
  location            = azurerm_resource_group.network.location
}

resource "azurerm_virtual_network" "app" {
  name                = "vnet-app-prod"
  resource_group_name = azurerm_resource_group.app.name
  location            = azurerm_resource_group.app.location
  address_space       = ["10.20.0.0/16"]

  ddos_protection_plan {
    id     = azurerm_network_ddos_protection_plan.prod.id
    enable = true
  }
}

---

How to prevent it from happening again

Enabling protection once is easy. Keeping every new VNet covered as your footprint grows is the real problem. Bake the requirement into the layers where VNets get created.

Enforce with Azure Policy

Azure ships a built-in policy definition, "Virtual networks should be protected by Azure DDoS Network Protection," that audits or denies non-compliant VNets. Assign it at the subscription or management group scope:

az policy assignment create \
  --name require-vnet-ddos \
  --display-name "Require DDoS Network Protection on VNets" \
  --scope "/subscriptions/<subscription-id>" \
  --policy "a7aca53f-2ed4-4466-a25e-0b45ade68efd" \
  --params '{"ddosPlan":{"value":"/subscriptions/<sub>/resourceGroups/rg-network-prod/providers/Microsoft.Network/ddosProtectionPlans/ddos-plan-prod"}}'

Gate it in CI/CD

For teams deploying infrastructure as code, fail the pipeline before a non-compliant VNet ever reaches Azure. With Terraform you can use Checkov or tfsec in the pull request stage:

checkov -d ./infra --check CKV_AZURE_56

That rule flags any azurerm_virtual_network without DDoS protection enabled. Wire it into your PR checks so the conversation about cost and coverage happens at review time, not after an outage.

---

Best practices

• Protect where public IPs live, not everywhere. A purely internal VNet with no public exposure gets little benefit from the paid tier. Prioritize VNets fronting load balancers, application gateways, firewalls, and VMs with public IPs.
• Pair DDoS protection with a WAF. DDoS Network Protection handles layers 3 and 4 (volumetric and protocol attacks). Layer 7 application attacks need a Web Application Firewall on Azure Application Gateway or Front Door. They complement each other.
• Share one plan per region per environment. Because a single plan covers up to 100 public IPs, consolidate VNets onto shared plans to keep the cost predictable.
• Set up attack alerts. Configure Azure Monitor alerts on the Under DDoS attack or not metric so your team knows the moment mitigation engages.
• Test before you trust. Microsoft permits simulated DDoS testing through approved partners like BreakingPoint Cloud. Validate that your alerting and runbooks fire correctly under simulated load.
• Document the cost decision. The plan is expensive enough that someone will eventually ask why. Record which VNets are protected and the business reason, so the answer is on file before the budget review.

DDoS protection is one of those controls that costs money every month and pays off only when something goes wrong. For internet-facing production workloads, the math usually favors having it. This check exists to make sure the decision is deliberate rather than an accident of default settings.