Azure DDoS Protection is one of those services that sounds simple on paper but becomes confusing once you try to implement it properly with Infrastructure as Code.
Microsoft Learn walks you through the concepts in the portal, but if you’re serious about Terraform, you quickly discover that not everything shown in the UI is exposed through APIs.
In this lab, I set out to build Azure DDoS Network Protection the way you would in a real environment, using Terraform wherever it makes sense, and understanding where Terraform simply cannot replicate portal-only behaviour.
This post walks through what I built, what worked, and the key limitations you need to be aware of.
The goal of the lab
The aim was to implement Azure DDoS Network Protection on a virtual network, protect a public endpoint, and understand how telemetry and alerting really work behind the scenes.
Specifically, the lab covered:
- Creating a resource group
- Deploying a virtual network and subnet
- Creating a DDoS Protection Plan
- Enabling DDoS protection at the VNet level
- Deploying a Standard, static Public IP
- Exploring telemetry and alerting options
- All infrastructure was deployed using Terraform
Why DDoS protection starts at the VNet
One of the most important things to understand is that Azure DDoS Network Protection is applied at the virtual network level, not directly on individual public IPs.
You create a DDoS Protection Plan and then attach it to the VNet. Any supported public resource (for example, a Public IP) that lives inside that VNet automatically inherits DDoS protection, provided it uses the Standard SKU.
This is why Basic public IPs are not supported and why Standard, static public IPs are mandatory for protected workloads.
Terraform handles this part very cleanly. The DDoS Protection Plan is created once and then referenced directly inside the virtual network configuration.
Public IPs and DDoS inheritance
After the VNet is protected, the next step is to deploy a Standard, static Public IP. Once this IP exists inside the protected VNet, Azure automatically sets its DDoS protection mode to VirtualNetworkInherited.
This is an important validation step. Even without attaching the IP to a VM or load balancer, you can already see that Azure recognises it as DDoS-protected.
Terraform exposes this clearly in the plan output, which is a nice way to confirm that protection is correctly applied.
Telemetry is real, alerts are… complicated
This is where most labs gloss over the reality.
In the Azure Portal, you’ll see signals like “Under DDoS attack or not” and DDoS-specific graphs. Microsoft Learn also references these signals when explaining alerting.
However, these signals are not exposed as standard Azure Monitor metrics or Activity Log events.
What that means in practice is:
- You can see DDoS detection in the portal
- You can explore telemetry visually
- But you cannot reliably create Terraform-managed alerts based on those signals
Metric alerts for DDoS-specific counters fail because the metrics are not consistently queryable. Activity Log alerts also fail because DDoS mitigation events are not published as supported Activity Log operations.
This isn’t a Terraform limitation. It’s an Azure platform limitation.
In real environments, teams either:
- Configure DDoS alerts directly in the portal, or
- Alert on downstream impacts (traffic anomalies, service health events, application saturation)
Understanding this limitation is arguably the most important takeaway from the lab.
What this lab actually teaches (and why it matters)
This exercise isn’t just about ticking off a checklist. It teaches several real-world lessons:
- DDoS Network Protection is a VNet-level control
- Standard Public IPs are mandatory for protected resources
- Not everything visible in the Azure Portal is automatable
- Terraform can deploy the infrastructure cleanly, but alerting has platform limits
- Knowing what cannot be automated is just as important as knowing what can
These are exactly the kinds of nuances that matter in architecture and design discussions.
Source code
The full Terraform configuration used in this lab is available here.