Azure DDoS Protection: Fix Setup & Config Issues Fast
Why Azure DDoS Protection Keeps Causing Headaches
If you've just moved a workload to Azure and are trying to get Azure DDoS Protection configured correctly, you're probably staring at a portal screen wondering why nothing is behaving the way the docs suggest it should. I've walked through this setup with dozens of teams , enterprise architects, small shop DevOps engineers, and solo cloud admins , and the confusion almost always comes from the same handful of misunderstandings baked into how Azure presents DDoS protection options.
Here's the core issue: Azure actually has two distinct protection tiers, DDoS Network Protection and DDoS IP Protection, and many people don't realize they work differently from each other until something breaks or they get an unexpected bill. DDoS Network Protection works at the virtual network level and requires you to create a dedicated DDoS protection plan resource. DDoS IP Protection, on the other hand, is a pay-per-protected-IP model that you enable directly on a public IP resource, no separate plan needed. Picking the wrong one for your architecture leads to gaps in coverage that are invisible until an attack surfaces them.
Another common source of pain: people assume that enabling Azure DDoS Protection on a VNet means all traffic is immediately, actively filtered. What actually happens is the system goes into a learning phase first. The adaptive real-time tuning feature needs time to build a traffic profile for your specific workload before it can intelligently distinguish between a surge in legitimate traffic and a volumetric flood attack. If you flip protection on and then immediately run a load test, you may hit unexpected mitigation that throttles your own traffic, and there's no obvious error code or notification that explains why.
Then there's the layer confusion. Azure DDoS Protection covers Layer 3 and Layer 4, that's network and transport layer attacks like UDP floods, SYN floods, and reflection amplification attacks. It does not cover Layer 7 application-layer attacks on its own. A slow HTTP POST flood, for example, won't be caught by DDoS Protection alone. You need a Web Application Firewall (WAF), either Azure Application Gateway WAF or a third-party option from the Azure Marketplace, to handle those. Teams often find out about this gap only after an app-layer attack gets through, which is a rough way to learn.
Microsoft's portal error messages and diagnostic alerts in this area are genuinely unhelpful. When mitigation kicks in, you typically see a metric spike in your Azure Monitor dashboard labeled something like Under DDoS attack, but there's no contextual explanation of what type of attack is being mitigated, what thresholds were crossed, or what remediation steps you should take. The detailed attack analytics that DDoS Network Protection does provide, five-minute increment reports and post-attack summaries, are buried in the diagnostic logging configuration, which is not enabled by default.
I know this is frustrating, especially when production traffic is affected and your on-call team is circling. Let's break down the exact steps to get everything configured correctly. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're in a hurry and you just need Azure DDoS protection active on a virtual network right now, this is the fastest path. This is the DDoS Network Protection route, which is the right choice for protecting multiple resources across one or more VNets under a single tenant.
Start by navigating to the Azure portal at portal.azure.com. In the top search bar, type DDoS protection plans and select it from the results. Click + Create. On the creation form, fill in your subscription, resource group, and a name for the plan, something like ddos-plan-prod works fine. Choose the region closest to your workloads. Click Review + create, then Create.
Once the plan is provisioned (takes under a minute), navigate to your Virtual Network. In the left-hand menu of the VNet blade, scroll to Settings and click DDoS protection. You'll see a toggle that says Enable. Switch it on. The portal will then prompt you to associate a DDoS protection plan, select the plan you just created from the dropdown. Hit Save.
That's it for basic enablement. Every public IP resource on that VNet is now under Azure DDoS Network Protection. No agent installs, no code changes, no reboots. Protection is active at the network edge.
If you're protecting a single public IP resource rather than an entire VNet, say, a standalone public IP attached to a VM or load balancer, use DDoS IP Protection instead. Go to your Public IP address resource in the portal, select DDoS protection from the left menu, choose IP as the protection type, and save. Done.
After enabling either tier, go to Azure Monitor → Metrics, search for your protected resource, and add the metric Under DDoS attack. Set the chart to a 24-hour window. A flat line reading zero is exactly what you want to see, it means protection is active and no mitigation is currently running.
Before you touch a single setting, you need to make a decision that will affect your architecture and your invoice: which Azure DDoS Protection tier is right for your deployment? Getting this wrong early means either over-paying or leaving gaps in your coverage.
DDoS Network Protection is the right choice when you have multiple virtual machines, load balancers, or application gateways sitting behind one or more VNets. You create one protection plan (billed at a fixed monthly rate) and associate it with as many VNets as you want across your entire tenant. Every public IP on those VNets gets protected automatically, no additional configuration per resource. This tier also includes value-added services: access to the DDoS Rapid Response team during an active attack, cost protection credits for scale-out events caused by a documented attack, and discounts on WAF services.
DDoS IP Protection suits smaller deployments or scenarios where you need to protect one or two specific public IPs without buying a full protection plan. It's priced per protected IP, so for a low number of resources it can be more cost-effective. The core engineering protection is the same as Network Protection, same traffic monitoring, same adaptive tuning, same mitigation policies, but you don't get DDoS rapid response support, the cost protection credit, or the WAF discount.
To check the current tier comparison in the portal, search for DDoS protection plans, then click Tier comparison in the left blade. This table is updated regularly as Microsoft adjusts tier features, so always check it before committing to an architecture.
If you make the wrong choice here, correcting it is straightforward: disable the current protection on your resource or VNet, then enable the other tier. No downtime, no traffic interruption.
Once you know which tier fits, here's the exact portal path for DDoS Network Protection. Go to portal.azure.com → Virtual networks and select the VNet you want to protect. In the left-hand menu, under Settings, click DDoS protection.
You'll see two radio button options: Basic and Network. Basic is the default infrastructure-level protection that every Azure customer gets for free. It handles common, large-scale volumetric attacks at the platform edge, but it is not tuned to your specific traffic patterns and does not include any analytics, alerting, or Rapid Response access. Selecting Network upgrades you to the full protection tier.
After selecting Network, the portal prompts you to choose a DDoS protection plan. If you haven't created one yet, click the Create new link inline, you don't have to leave the VNet blade. Name the plan, pick your subscription and resource group, click OK. Once the plan is created, it auto-selects in the dropdown. Click Save.
You'll see a notification banner at the top right that reads "DDoS protection plan updated successfully". At that point, protection is live. There is no propagation delay you need to wait for, the always-on traffic monitoring starts immediately.
To verify via Azure CLI:
az network vnet show \
--resource-group myResourceGroup \
--name myVNet \
--query "ddosProtectionPlan"If protection is active, this returns the resource ID of your DDoS protection plan. A null response means the plan is not associated, go back and check your save step.
This step is where most teams drop the ball. You've enabled protection, but without alerts, you won't know an attack is happening until your users start complaining. Configuring DDoS protection alerts in Azure Monitor takes less than ten minutes and gives you immediate notification when mitigation activates.
Go to Azure Monitor → Alerts → + Create → Alert rule. Under Scope, click Select resource and choose your public IP address (not the VNet, alerts are set per public IP). Under Condition, click Add condition and search for Under DDoS attack in the signal list. Select it.
Configure the alert logic: set the operator to Greater than, the threshold value to 0, and the aggregation type to Maximum. Set the evaluation frequency to 1 minute and the lookback period to 5 minutes. This means the alert fires within a minute of mitigation starting.
Under Actions, attach an action group. If you don't have one, create it now, add an email address, a webhook to your Slack or PagerDuty endpoint, or an Azure Function for automated response. Click Review + create, then Create.
Azure DDoS Protection supports three auto-tuned mitigation policies that run in parallel across each protected public IP: TCP SYN, TCP, and UDP. Each policy threshold is machine-learning configured against your traffic baseline. You can also set alerts on the metric DDoS mitigation policies if you want to monitor when those thresholds are being approached but not yet crossed, useful for baselining during high-traffic events like product launches.
Test the alert setup works by temporarily setting the threshold to -1 (which always triggers), confirming you receive the notification, then resetting it to 0.
The real investigative power of Azure DDoS Protection comes from its diagnostic logs. These logs give you five-minute-increment attack reports during an active incident and a full post-attack summary when mitigation ends. By default, none of this data is stored anywhere, you have to turn it on manually.
Go to your Public IP address resource → Monitoring → Diagnostic settings. Click + Add diagnostic setting. Give it a name like ddos-diag-prod.
Under Category groups, you'll see three relevant log types:
- DDoSProtectionNotifications, fires at attack start and stop
- DDoSMitigationFlowLogs, granular per-flow data during mitigation, best for SIEM integration
- DDoSMitigationReports, aggregated 5-minute summaries and full post-attack analysis
Check all three. For the destination, select Send to Log Analytics workspace and pick your workspace. If you're also running Microsoft Sentinel, you can route the DDoSMitigationFlowLogs to Sentinel by enabling the Azure DDoS Solution for Microsoft Sentinel, this gives your SOC team near-real-time attack visibility directly inside the Sentinel incident queue.
Click Save. After an attack or simulated event, run this Kusto query in Log Analytics to pull the mitigation report:
AzureDiagnostics
| where Category == "DDoSMitigationReports"
| where ResourceId contains "YOUR-PUBLIC-IP-NAME"
| order by TimeGenerated desc
| take 20If rows return, your logging pipeline is working. No rows after a known attack means the diagnostic setting wasn't saved correctly, go back and verify the destination workspace ID.
Here's the fix that a lot of teams miss: Azure DDoS Protection stops at Layer 4. HTTP floods, slowloris attacks, malformed API request storms, all of those live at Layer 7 and pass straight through DDoS Protection untouched. To close that gap, you need a Web Application Firewall in front of your internet-facing apps.
The two most common pairings in Azure are Azure Application Gateway with WAF v2 SKU for HTTP/HTTPS workloads, and Azure Front Door with WAF policy for globally distributed apps. Both integrate directly with Azure DDoS Network Protection at the network layer, giving you the multi-layered protection that Microsoft recommends.
To enable WAF on an existing Application Gateway, go to your Application Gateway resource → Settings → Web application firewall. If the current SKU is Standard v2, you'll need to upgrade to WAF v2 first, click Upgrade. Once on WAF v2, toggle the WAF status to Enabled and set the tier to Prevention (Detection mode logs attacks but doesn't block them, useful for initial tuning, but don't leave it there in production). Select the OWASP 3.2 ruleset as your baseline.
After saving, your application now has protection at both L3/L4 via Azure DDoS Protection and L7 via the WAF. Microsoft explicitly designs this as a combined defense model, and it's the architecture you want for any public-facing web app in Azure.
To confirm both layers are active, check the Application Gateway's WAF logs (under Diagnostic settings, similar to the DDoS logs above) and verify that the associated VNet has DDoS Network Protection or that the Application Gateway's public IP has DDoS IP Protection enabled. Running both without confirming the link is a common oversight.
Advanced Azure DDoS Protection Troubleshooting
Mitigation Firing on Legitimate Traffic
If you're seeing legitimate requests getting dropped and you suspect DDoS mitigation is the cause, the first thing to check is whether your traffic profile has had time to stabilize. The adaptive real-time tuning system learns your traffic patterns over time, if you recently enabled protection or significantly changed your traffic volume (new product launch, marketing campaign, batch job that hammers an endpoint), the system's baseline may be temporarily miscalibrated.
Pull the mitigation flow logs from Log Analytics using the query from Step 4 and look at the type field in the DDoSMitigationFlowLogs. You want to identify whether the mitigation is firing on TCP SYN, TCP, or UDP traffic, that tells you which of the three auto-tuned policies is triggering. If the traffic being dropped matches your legitimate workload's profile exactly, the next step is to contact the DDoS Rapid Response team (available to DDoS Network Protection customers through the Azure portal under Help + support). They can manually review the policy thresholds applied to your specific IP and adjust if needed.
DDoS Protection Plan Not Associating with VNet
If you're getting an error when trying to link a protection plan to a VNet, typically something like "The resource group location does not match", check that the DDoS protection plan and the VNet are in the same Azure region. This is an easy mistake when you create the plan in a different region than intended. The fix is to delete the mismatched plan and recreate it in the correct region.
Also check that your account has the Network Contributor role or higher on both the VNet and the resource group containing the DDoS plan. Read-only or custom roles that don't include Microsoft.Network/ddosProtectionPlans/join/action will silently fail to save the association, it looks like it worked, but the plan never attaches.
Sentinel Integration Not Receiving DDoS Events
If you've connected the Azure DDoS Solution for Microsoft Sentinel but attack events aren't appearing in your Sentinel workspace, verify that the diagnostic setting on your public IP is pointing to the same Log Analytics workspace that Sentinel is connected to. They must be the same workspace. A second common issue: the DDoSMitigationFlowLogs category must be explicitly checked in the diagnostic setting, the AllLogs option does not always capture all DDoS-specific log types depending on your workspace configuration.
Pricing and Subscription Scope Confusion
Under a single Azure tenant, one DDoS protection plan covers multiple subscriptions. I've seen teams running three or four plans across different subscriptions in the same tenant, incurring the fixed monthly charge multiple times. Go to your DDoS protection plan resource → Protected resources to see all VNets linked to it. Then go to each subscription and confirm they're all referencing the same plan. Consolidating down to one plan is a straightforward configuration change with no protection gap during the transition.
Prevention & Best Practices for Azure DDoS Protection
Getting Azure DDoS Protection enabled is just the start. The teams that weather real attacks best are the ones who treat DDoS defense as an ongoing practice, not a one-time checkbox. Here's what actually makes the difference.
Design for redundancy first. Azure DDoS Protection mitigates attacks at the network edge, but mitigation is never instantaneous, there's a detection window of seconds to minutes before the system confirms an attack and ramps up countermeasures. During that window, your application needs to absorb the spike. Build with auto-scaling enabled, use Azure Load Balancer or Application Gateway to distribute traffic across multiple instances, and keep your health probes tuned to remove unhealthy instances quickly. An app that scales horizontally buys you time that a single-instance deployment doesn't have.
Tune your WAF rules before you're under fire. Most teams enable WAF in Detection mode and mean to switch it to Prevention mode later, and then never do. Set a calendar reminder for two weeks after enablement, review the WAF logs from Detection mode to identify any false positives on your legitimate traffic, create exclusion rules for those patterns, and then switch to Prevention mode. Doing this while everything is calm means you're not making configuration changes under pressure during an attack.
Run a test simulation with an approved partner. Azure DDoS Protection has a list of approved testing partners you can use to simulate real DDoS attack traffic against your environment, this is the only sanctioned way to test mitigation without violating Azure's terms of service. Testing reveals whether your alerts fire correctly, whether your diagnostic logging captures the expected data, and whether your application stays healthy under mitigation. Schedule this test quarterly for high-traffic production systems.
Keep your network security architecture integrated. Azure DDoS Protection works best when it's part of a layered security stack. Combine it with Azure Firewall for east-west traffic control, WAF for application-layer protection, and Azure network security groups for granular inbound filtering. The attack surface you expose to the internet should be as small as possible, DDoS Protection is your last line of defense, not your first.
- Enable diagnostic logging on every protected public IP immediately after turning on DDoS protection, it's off by default and you'll want the data when an attack happens
- Set up the Under DDoS attack metric alert with a 1-minute evaluation frequency so your on-call team knows within minutes of an attack starting
- Review your DDoS protection plan's Protected resources blade monthly, removed or redeployed resources can leave the plan without associated VNets, wasting the fixed monthly cost
- For WAF-protected workloads, review WAF logs weekly during the first month after deployment to catch misconfigured rules before they affect real users
Frequently Asked Questions About Azure DDoS Protection
What exactly is Azure DDoS Protection and do I need it if I'm already on Azure?
Every Azure subscription gets basic infrastructure-level DDoS protection at no charge, this handles very large, well-known volumetric attack patterns at the platform edge. But it's not tuned to your specific application's traffic patterns, and it doesn't include attack analytics, alerting, or access to the Rapid Response team. Azure DDoS Protection (either Network or IP tier) adds intelligent, always-on monitoring that learns your specific traffic baseline and auto-tunes its mitigation policies against it. If you have any internet-facing workloads that need to stay available, APIs, web apps, game servers, anything with an SLA, the enhanced protection is worth having. The default infrastructure protection is a safety net, not a defense strategy.
What's the difference between DDoS Network Protection and DDoS IP Protection?
Both tiers run the same core mitigation engine, adaptive traffic profiling, auto-tuned policies for TCP SYN, TCP, and UDP attack types, and real-time mitigation. The differences are in how they're activated and what extras you get. DDoS Network Protection requires creating a DDoS protection plan resource and linking it to a VNet, which then covers all public IPs on that VNet. It includes DDoS Rapid Response team access, cost protection credits for documented attacks, and WAF discounts. DDoS IP Protection skips the plan entirely, you enable it directly on individual public IP resources and pay per protected IP. It doesn't include the Rapid Response access or the cost protection credits. For most production environments with multiple resources, Network Protection is better value. For one or two isolated public IPs, IP Protection keeps things simple.
Does Azure DDoS Protection cover Layer 7 application attacks like HTTP floods?
No, and this is one of the most common misconceptions I run into. Azure DDoS Protection covers Layer 3 (network) and Layer 4 (transport) attacks: volumetric floods, protocol attacks, SYN floods, UDP amplification, and similar. Application-layer attacks at Layer 7, things like HTTP GET/POST floods, slowloris, and malformed API request storms, pass through DDoS Protection without being mitigated. To cover Layer 7, you need a Web Application Firewall. In Azure, the most common choices are Azure Application Gateway WAF v2 SKU for traditional web apps and Azure Front Door with WAF policy for globally distributed apps. Microsoft explicitly recommends running both together: DDoS Protection at L3/L4 and WAF at L7 for full-stack coverage.
Why is my legitimate traffic getting dropped after I enabled Azure DDoS Protection?
This usually happens when the adaptive tuning system hasn't had enough time to establish an accurate baseline for your traffic patterns. Right after enablement, the system starts learning, if you have bursty traffic, run batch jobs that generate large request volumes, or recently launched a marketing campaign that spiked traffic, the system may temporarily misclassify legitimate traffic as attack traffic. Pull your DDoSMitigationFlowLogs from Log Analytics to confirm mitigation is the actual cause, then check which policy type is triggering (TCP SYN, TCP, or UDP). If legitimate traffic is being incorrectly mitigated, contact the DDoS Rapid Response team (for Network Protection customers) through Azure Support with a Severity A ticket, they can review and manually adjust the policy thresholds applied to your IP.
How do I know if Azure DDoS Protection is actually working or doing anything?
Go to Azure Monitor, search your protected public IP resource, and add the metric Under DDoS attack. Set the chart time range to 24 hours and the aggregation to Maximum. A flat line at zero means protection is active and no mitigation is running, which is exactly what you want. You can also check DDoS mitigation policies metrics (InboundTCPPacketsToDropDDoS, InboundUDPPacketsToDropDDoS, InboundSYNPacketsToDropDDoS) to see the current threshold values that the machine learning model has set for your traffic. If diagnostic logging is enabled and pointed at a Log Analytics workspace, run the Kusto query against the AzureDiagnostics table with the category filter for DDoSProtectionNotifications, any past attack events will appear there with timestamps and attack types.
What is Azure DDoS Rapid Response and how do I access it during an attack?
Azure DDoS Rapid Response is a dedicated Microsoft engineering team that DDoS Network Protection customers can engage during an active attack. They provide real-time attack investigation, help interpret the mitigation data, and can make manual adjustments to policy thresholds if the automated mitigation isn't optimal for your specific situation. They also provide post-attack analysis when things settle down. To engage them, go to Azure portal → Help + support → New support request, set the issue type to Technical, service to DDoS Protection, and severity to A (Critical). DDoS IP Protection customers do not have direct DRR access, it's exclusive to the Network Protection tier. If you're expecting to be a DDoS target (financial services, gaming, media streaming), that Rapid Response access alone can justify the tier difference.