Microsoft announced on July 23, 2026 that Azure DDoS Protection custom policy is available in public preview.

The new capability gives customers more control over when DDoS mitigation triggers for supported workloads. Teams can configure protocol-specific detection thresholds and apply different policies to individual resources while continuing to use Azure's global mitigation infrastructure and existing monitoring.

What Changed?

Azure DDoS Protection normally analyzes traffic patterns and automatically tunes mitigation behavior for protected resources.

That hands-off model remains the default. Custom policy adds an optional override for workloads with unusual but well-understood traffic patterns.

During the public preview, customers can configure custom detection thresholds for:

• TCP traffic

• UDP traffic

• TCP SYN traffic

Policies can be applied per supported resource, allowing different environments or applications to use different settings.

Existing Azure Monitor metrics and DDoS Protection telemetry continue to work with custom policies.

Current Preview Scope

The initial public preview supports:

• Standard Load Balancer frontend IP configurations

• TCP, UDP, and TCP SYN threshold customization

• Azure portal management

• ARM and REST API deployment

Microsoft states that the current preview is limited to Standard Load Balancer frontend IPs and does not include PowerShell support.

The supported scope may change before general availability, so teams should confirm the latest documentation before designing automation or production controls around the feature.

Why Customers Asked for More Control

Automatic adaptive protection works for most Azure workloads, but some applications have traffic behavior that is difficult to represent with a generic pattern.

Examples include:

• Gaming platforms with scheduled launches or live events

• Ticketing systems with predictable high-demand windows

• High-throughput services with sustained packet rates

• Latency-sensitive applications

• Workloads that need different settings across development, test, and production

Custom policy allows those teams to align mitigation thresholds with a measured operational baseline.

The benefit is greater precision. The tradeoff is that the customer becomes responsible for choosing and maintaining the static value.

The Most Important Behavior

When a custom threshold is configured for a protocol, Azure disables the automatic tuning trigger for that protocol and uses the static value supplied by the customer.

Autotuning continues for protocols that do not have a custom override.

This means a custom policy should not be treated as a simple preference setting.

A threshold set too low could interfere with a legitimate traffic surge. A threshold set too high could delay mitigation compared with adaptive behavior. Both outcomes can affect availability.

Teams need representative traffic history, change control, monitoring, ownership, and a rollback plan before introducing an override.

Per-Resource Policy Management

Custom policy allows separate mitigation settings across supported frontend IP resources.

This can help organizations isolate configuration by application, environment, or operational need rather than using one threshold everywhere.

For example, a production gaming service with a known launch profile may require a different policy from a development environment or a business application with steady traffic.

Per-resource control also makes ownership more important. Every policy should identify the application owner, threshold source, review date, monitoring window, and removal process.

Monitoring Remains Available

Azure Monitor and existing DDoS Protection telemetry continue to provide visibility when custom policies are used.

Teams can use that telemetry to review:

• Normal packet rates

• Known legitimate peaks

• Mitigation activity

• Policy changes

• Application health

• Alert routing

Monitoring should begin before the threshold is changed. Without a reliable baseline, teams cannot explain why a static value is appropriate or determine whether it is working as intended.

Who Should Care?

Network engineers should review the preview because it changes how supported load-balancer frontends can be protected.

Security operations teams should care because threshold changes affect detection and incident behavior.

Application owners should care because legitimate traffic patterns, release events, and scale behavior determine whether a custom policy is safe.

Platform and governance teams should care because per-resource overrides need consistent ownership, review, monitoring, and lifecycle controls.

Practical Cloud Engineer Takeaway

Keep Azure's adaptive protection as the default unless a workload has a measured reason for a custom threshold.

If the preview is relevant, begin with a non-production Standard Load Balancer frontend IP.

Review normal and peak packet rates, choose only one protocol for the first evaluation, document the proposed threshold, and define conditions that require immediate rollback.

After configuration, verify the exact frontend association, policy value, Azure Monitor metrics, alerts, and application health.

Do not generate unapproved attack traffic. DDoS simulations should use Microsoft-approved testing partners, explicit authorization, defined limits, and the official Azure testing guidance.

Operational Checklist

Before moving beyond a limited evaluation, confirm:

• The resource is supported by the current preview.

• The threshold is based on representative traffic evidence.

• The selected protocol and packets-per-second value are documented.

• The owner understands that adaptive trigger tuning is disabled for that protocol.

• Azure Monitor and DDoS telemetry are validated.

• Alerts reach the correct team.

• A rollback owner and maintenance window exist.

• Preview terms and support expectations are accepted.

• The policy has a review or expiry date.

Custom values copied from another application are not a safe baseline. Packet patterns and failure costs vary by workload.

What to Watch

The most important developments to watch are expansion beyond Standard Load Balancer frontend IPs, additional management tooling, API changes, support guidance, and the path to general availability.

Teams should also track whether policy changes improve operational predictability without increasing false mitigation risk or weakening protection during an actual attack.

Bottom Line

Azure DDoS Protection custom policy adds optional, per-resource threshold control for supported Standard Load Balancer frontends.

The preview is relevant for high-throughput, event-driven, gaming, and latency-sensitive workloads with unusual but well-understood traffic behavior.

For most applications, Azure's automatic adaptive model remains the safer default. Custom policy should be used only when the workload has a measured need, a documented owner, validated telemetry, and a tested rollback path.

Sources

Microsoft announcement: https://techcommunity.microsoft.com/t5/azure-networking-blog/announcing-public-preview-of-azure-ddos-protection-custom-policy/ba-p/4538963

Azure DDoS Protection documentation: https://learn.microsoft.com/azure/ddos-protection/

Azure preview terms: https://azure.microsoft.com/support/legal/preview-supplemental-terms/

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz