Edit

Secure your Azure DDoS Protection deployment

Azure DDoS Protection provides enhanced DDoS mitigation features to defend against distributed denial-of-service (DDoS) attacks. It automatically tunes to protect your specific Azure resources in a virtual network, with always-on traffic monitoring, adaptive real-time tuning, and layer 3/layer 4 attack mitigation for supported public IP resources.

This article provides security recommendations for Azure DDoS Protection. Implementing these recommendations helps you fulfill your security obligations and improves the overall security posture of your deployment. For an overview of Azure's network security services and how they work together, see What is Azure network security?.

The security recommendations in this article implement Zero Trust principles: "Verify explicitly", "Use least privilege access", and "Assume breach". For comprehensive Zero Trust guidance, see the Zero Trust Guidance Center.

Service-specific security

Service-specific security for Azure DDoS Protection focuses on choosing a supported tier and deployment model so protection applies to the intended resources.

  • Validate supported deployment models before enabling protection: Confirm that your resources use a supported public IP and deployment model. DDoS Protection doesn't support NAT Gateway public IPs, classic VM deployments, Azure Virtual WAN, or Azure API Management deployment modes other than API Management with virtual network integration. For more information, see About Azure DDoS Protection tier comparison.

Network security

Network security for Azure DDoS Protection focuses on ensuring comprehensive coverage of your supported public IP resources, reducing your attack surface, and layering DDoS protection with other Azure security services for defense in depth.

  • Choose the right DDoS Protection tier for your deployment: Evaluate whether DDoS Network Protection or DDoS IP Protection best fits your environment. DDoS Network Protection covers supported public IP resources in a virtual network and includes cost protection, DDoS Rapid Response access, and WAF discounts. DDoS IP Protection is a per-IP model suited for smaller deployments with fewer public IPs. For more information, see About Azure DDoS Protection tier comparison.

  • Enable DDoS protection on all virtual networks with public IP resources: Associate a DDoS protection plan with every virtual network that contains public IP addresses. Unprotected virtual networks are exposed to volumetric and protocol attacks without the adaptive tuning and mitigation that DDoS Protection provides. For more information, see Quickstart: Create and configure Azure DDoS Network Protection.

  • Reduce your attack surface with Azure Private Link: Use Azure Private Link and private endpoints to access PaaS services over a private connection rather than a public IP. Fewer exposed public IPs means fewer targets for DDoS attacks. For more information, see Azure Private Link.

  • Restrict traffic with Network Security Groups: Apply NSGs on subnets behind DDoS-protected public IPs to allow only required ports and protocols. Use service tags and application security groups for granular filtering. This limits the traffic that reaches your resources even during an attack. For more information, see Network security groups.

  • Layer DDoS Protection with Azure Firewall: Deploy Azure Firewall behind DDoS-protected public IPs for layer 3/layer 4 stateful inspection in addition to DDoS mitigation. Azure Firewall provides threat intelligence filtering and IDPS that complement DDoS Protection's volumetric attack defense. For more information, see Secure your Azure Firewall deployment.

  • Add layer 7 protection with Web Application Firewall: DDoS Protection handles layer 3/layer 4 attacks but doesn't inspect application-layer traffic. Deploy Azure WAF on Application Gateway or Azure Front Door to protect against layer 7 attacks such as SQL injection, cross-site scripting, and HTTP floods. For more information, see Secure your Azure Web Application Firewall deployment.

  • Protect all public IP resource types: Ensure that all supported resource types with public IPs are covered, including virtual machines, load balancers, Application Gateways, Azure Bastion hosts, VPN Gateways, and Azure Firewall instances. Review the list of supported resources periodically as your deployment grows. For more information, see Azure DDoS Protection features.

  • Use reference architectures for new deployments: Follow Azure's validated reference architectures that incorporate DDoS Protection, including load-balanced VMs, n-tier applications with WAF, hub-and-spoke topologies, and PaaS web applications with Traffic Manager failover. For more information, see Azure DDoS Protection reference architectures.

Identity and access management

Identity and access management for Azure DDoS Protection controls who can create, modify, and associate DDoS protection plans and who can view attack telemetry.

  • Assign the least privilege role for DDoS management: Use the built-in Network Contributor role for users who need to manage DDoS protection plans. For view-only access to DDoS plans and policy configuration, use the built-in Reader role or a custom role that includes Microsoft.Network/ddosProtectionPlans/read. Avoid assigning broader roles like Contributor or Owner when only network management is needed. For more information, see Manage Azure DDoS Protection permissions.

  • Create a custom RBAC role for DDoS operations: If Network Contributor is too broad, create a custom role that includes only the required DDoS actions: Microsoft.Network/ddosProtectionPlans/read, Microsoft.Network/ddosProtectionPlans/write, Microsoft.Network/ddosProtectionPlans/delete, and Microsoft.Network/ddosProtectionPlans/join/action. Include the appropriate Microsoft.Network/virtualNetworks/* actions when the role must enable or associate DDoS protection on virtual networks. For more information, see Azure custom roles.

  • Grant the join action for virtual network operations: Ensure that users who manage virtual networks associated with a DDoS plan have the Microsoft.Network/ddosProtectionPlans/join/action permission. Without this permission, virtual network operations fail after DDoS protection is enabled on the network. For more information, see Manage Azure DDoS Protection permissions.

  • Restrict DDoS plan creation to authorized personnel: Limit the ability to create DDoS protection plans to a small set of administrators. A single DDoS Network Protection plan can cover multiple subscriptions and regions, so unnecessary plan creation leads to uncontrolled costs. Use Azure Policy or role assignments to enforce this restriction. For more information, see About Azure DDoS Protection tier comparison.

  • Use Microsoft Entra Conditional Access for management operations: Require multifactor authentication and compliant devices when administrators access the Azure portal or Azure Resource Manager APIs to manage DDoS protection plans. This prevents unauthorized modifications even if credentials are compromised. For more information, see Microsoft Entra Conditional Access.

Data protection

Data protection for Azure DDoS Protection covers securing the telemetry, mitigation logs, and flow data that the service generates during attack detection and mitigation.

  • Secure Log Analytics workspaces that receive DDoS data: DDoS diagnostic logs, mitigation flow logs, and mitigation reports can contain source IP addresses, port information, and protocol details. Restrict access to the Log Analytics workspace that receives this data using workspace-level RBAC. For more information, see Manage access to Log Analytics workspaces.

  • Encrypt diagnostic log storage: If you archive DDoS diagnostic logs to an Azure Storage account, enable storage encryption with customer-managed keys for full control over the encryption lifecycle. By default, Azure Storage encrypts data at rest with Microsoft-managed keys, but customer-managed keys provide additional control. For more information, see Azure Storage encryption.

  • Restrict access to mitigation flow log data: DDoS mitigation flow logs contain per-flow details including source and destination IPs, ports, and protocols for traffic processed during an attack. Limit access to this data to your security operations team using RBAC on the diagnostic settings destination. For more information, see View and configure DDoS diagnostic logging.

  • Secure Event Hubs used for log streaming: If you stream DDoS logs to Event Hubs for SIEM integration, configure the diagnostic setting with an Event Hubs shared access policy that has Manage, Send, and Listen claims (required to create and update the diagnostic setting). When the Event Hubs namespace has network rules enabled, also enable Allow trusted Microsoft services so Azure Monitor can write log data. Limit who can manage that authorization rule, use a dedicated namespace when possible, and restrict the namespace with network rules. For more information, see Diagnostic settings in Azure Monitor.

Logging and monitoring

Logging and monitoring for Azure DDoS Protection ensures that you have visibility into attack events, mitigation actions, and traffic baselines, enabling rapid detection and response.

  • Enable diagnostic settings on all protected public IPs: Configure diagnostic settings to send DDoSProtectionNotifications, DDoSMitigationFlowLogs, and DDoSMitigationReports to a Log Analytics workspace. These logs provide critical details about attack timing, traffic volume, attack vectors, and mitigation effectiveness. For more information, see View and configure DDoS diagnostic logging.

  • Configure metric alerts for the "Under DDoS attack or not" signal: Create an Azure Monitor metric alert on the "Under DDoS attack or not" metric for every protected public IP address. This metric transitions to 1 when an attack is detected and triggers immediate notification to your security team. For more information, see Configure Azure DDoS Protection metric alerts.

  • Deploy enriched alert templates: Use the provided ARM templates to deploy alerts for protected public IP addresses that have diagnostic logging enabled. The enrichment template emails details about the IP address under attack, the associated resource, the resource owner and security team, and a basic application availability test. For more information, see Configure Azure DDoS Protection diagnostic alert templates.

  • Enforce diagnostic logging with Azure Policy: Assign the built-in policy "Public IP addresses should have resource logs enabled for Azure DDoS Protection" to audit or automatically deploy diagnostic settings across your environment. This prevents gaps where new public IPs are deployed without logging. For more information, see Azure DDoS Protection policy reference.

  • Stream logs to Microsoft Sentinel for correlation: Forward DDoS diagnostic logs to Microsoft Sentinel to correlate DDoS attack data with other security events. This helps identify whether a DDoS attack is a diversion tactic covering more targeted intrusions. For more information, see Monitor Azure DDoS Protection.

  • Monitor mitigation reports for attack analysis: Review both incremental (every 5 minutes during an attack) and post-mitigation reports. These reports include attack vectors, traffic statistics, drop reasons, and top source countries and ASNs, which inform defensive tuning and incident response. For more information, see View and configure DDoS diagnostic logging.

  • Enroll in DDoS Rapid Response for critical workloads: If you use DDoS Network Protection, engage the DDoS Rapid Response (DRR) team during active attacks for specialized investigation and post-attack analysis. Create a severity A support request when mitigation is ineffective or when an attack causes severe performance degradation. For more information, see Azure DDoS Rapid Response.

  • Establish a DDoS response team and runbook: Create a dedicated response team with defined roles and escalation procedures before an attack occurs. Document how to engage DRR, which metrics and logs to review, and how to communicate status to stakeholders. For more information, see Azure DDoS Protection response strategy.

Compliance and governance

Compliance and governance for Azure DDoS Protection helps ensure consistent protection across your organization and alignment with regulatory and architectural requirements.

  • Enforce DDoS protection on virtual networks with Azure Policy: Assign the built-in policy "Virtual networks should be protected by Azure DDoS Protection" with the Modify effect to automatically enable DDoS protection on noncompliant virtual networks, or use the Audit effect to report gaps. For more information, see Azure DDoS Protection policy reference.

  • Centralize DDoS protection under a single plan: Use a single DDoS Network Protection plan across multiple subscriptions and regions to maintain consistent protection and simplify management. A single plan can cover up to 100 protected public IPs (with overage charges beyond that). Consolidating plans prevents configuration drift and uncontrolled costs. For more information, see About Azure DDoS Protection tier comparison.

  • Inventory all public IP addresses and their protection status: Maintain a current inventory of supported public IP resources across your subscriptions. For DDoS Network Protection, verify that each public IP is in a virtual network associated with a DDoS protection plan. For DDoS IP Protection, verify that protection is enabled on each public IP resource that needs per-IP coverage. Use Azure Resource Graph queries to identify protection gaps. For more information, see Azure DDoS Protection optimization guide.

  • Use the cost guarantee for DDoS Network Protection: DDoS Network Protection customers can receive data-transfer and application scale-out service credits for resource costs incurred as a result of documented DDoS attacks. This safeguards your budget against unexpected costs during attacks. For more information, see Azure DDoS Protection features.

  • Conduct regular DDoS simulation testing: Validate your DDoS protection configuration and response procedures by running simulation tests through approved testing partners. Testing reveals misconfigurations, measures actual mitigation effectiveness, and trains your response team. For more information, see Test through simulations.

  • Review and optimize DDoS costs quarterly: Evaluate whether each protected public IP still requires protection and whether IP Protection or Network Protection is more cost-effective for your current deployment. Remove unnecessary public IPs and consider Private Link or CDN consolidation to reduce your protected IP count. For more information, see Azure DDoS Protection optimization guide.

Backup and recovery

Backup and recovery for Azure DDoS Protection focuses on maintaining service availability and protection continuity during attacks and regional failures.

  • Design multi-region architectures with DDoS protection at each region: Deploy resources in multiple Azure regions with DDoS protection enabled on virtual networks in each region. Use Azure Traffic Manager or Azure Front Door for failover so that if one region is overwhelmed by an attack, traffic routes to a healthy region. For more information, see Azure DDoS Protection reference architectures.

  • Use autoscaling to absorb attack traffic: Configure Virtual Machine Scale Sets or App Service autoscaling rules to scale out during traffic spikes caused by DDoS attacks. While DDoS Protection mitigates most attack traffic, some legitimate traffic increase and pass-through traffic during mitigation ramp-up require additional capacity. For more information, see Azure DDoS Protection fundamental best practices.

  • Distribute workloads behind load balancers: Place application instances behind Azure Load Balancer, Application Gateway, or Azure Front Door to distribute traffic across multiple instances and availability zones. This reduces the impact of any single point of failure during an attack. For more information, see Azure DDoS Protection fundamental best practices.

  • Plan for DDoS Protection plan recovery: A DDoS protection plan can't be moved between subscriptions or resource groups. If you need to recover or restructure your plan, you must delete and recreate it, then reassociate your virtual networks. Document your current plan-to-VNet associations and RBAC assignments so they can be restored quickly. For more information, see Azure resource types for move operations.

  • Include DDoS scenarios in your disaster recovery drills: Test that your failover mechanisms work correctly when a DDoS attack targets your primary region. Verify that secondary-region virtual networks also have DDoS protection enabled and that monitoring and alerting are configured identically. For more information, see Azure DDoS Protection response strategy.

Next steps