Introduction

Azure Web Application Firewall (WAF) is a cloud-native service that actively protects web applications from common vulnerabilities and exploits. It also supports custom rules that allow fine-grained control over traffic. Among these custom rules is the rate-limiting feature available in both Azure Application Gateway and Azure Front Door. Rate limiting helps mitigate denial-of-service (DoS) attacks, prevents abuse from misconfigured clients sending excessive requests, and controls traffic from specific geographies. By limiting requests per client in a set time window, WAF keeps your app available and responsive even under heavy load.

While rate limiting is a powerful tool for safeguarding web applications, some users struggle with configuring appropriate thresholds and durations. These two values often require tuning based on actual traffic patterns. Without proper planning or visibility into real traffic patterns, rate limit settings often end up being:

• Too strict – Blocking legitimate users and degrading user experience.
• Too lenient – Failing to stop abusive or malicious traffic.

This blog is the first in a two-part series designed to help users configure rate limiting in Azure Web Application Firewall (WAF). In this first part, we focus on Azure Front Door WAF and demonstrate how to use diagnostic logs to make informed, data-driven decisions about rate limit thresholds and durations. By analyzing real traffic patterns, you can configure rate limits that strike the right balance between security and usability, protecting your application without disrupting legitimate users.

Understanding rate limiting in Azure Front Door WAF

At its core, rate limiting is a mechanism that restricts the number of requests a client can make to a web application within a specified period. This helps prevent issues like brute-force login attacks, automated bots scraping data, or sudden traffic spikes. Azure Front Door WAF applies rate limiting through custom rules that monitor incoming requests according to specific match conditions.

Key characteristics of rate limiting in Azure Front Door WAF include:

• Duration: Can be set to 1 or 5 minutes.
• Threshold: Number of requests allowed in the time window.
• Customizability match conditions: You can match based on country (geolocation), IP address (remote address or socket address) request URI, HTTP method, and more.
• Action: What to do when the threshold is exceeded e.g., deny, log, redirect, JS Challenge (preview), CAPTCHA (preview).

Below is an example of a rate limit rule configured in Azure Front Door WAF:

Using diagnostic logs to configure WAF rate limiting

To configure effective rate limiting policies in Azure Front Door WAF, it is important to understand how users are accessing your application. Diagnostic logs from Azure Front Door provide this visibility. In this section, we’ll walk through:

1. Enabling diagnostic logs
2. Querying traffic patterns with KQL
3. Using insights to define smart thresholds and durations

Enable diagnostic logs

In Azure Front Door:

• Go to your Front Door profile.
• Under Monitoring, select Diagnostic settings.
• Click + Add diagnostic setting.
• Add a new setting to capture:
  • FrontDoor Access Log – request level data.
  • FrontDoor WebApplicationFirewall Log – WAF rule matches.
• Send logs to:
  • Log Analytics workspace (recommended for querying),
  • Storage account, or
  • Event Hub.
• Save the settings.

When configuring rate limit rules in Azure Front Door WAF, you can choose either a 1-minute or 5-minute time window. While both options are supported, using a 5-minute window with a higher threshold can improve detection accuracy by reducing false positives. Rate limiting is applied per socket IP - the source IP as seen by Azure Front Door. If there's another CDN or proxy in front of Front Door, this IP may not represent the original client, which can affect how rate limits are enforced. Please refer to Web application firewall rate limiting for Azure Front Door | Microsoft Learn.

Analyze traffic behavior with KQL

With diagnostic logs flowing into your log analytics workspace, you can begin to understand actual request volumes, IP behavior, and trends across time. These insights form the basis for defining effective rate limits.

Query 1: Average requests per IP (5-minute intervals)

This first query provides the average number of requests each client IP sends over 5-minute windows. It helps establish a baseline of expected activity per user. Understanding the average request rate helps you distinguish between normal and abnormal behavior. It’s your starting point for setting a rate limit that won’t block legitimate users.

Usage: Set your initial rate limit slightly above the observed average to allow for minor bursts while still preventing abuse.

The screenshot below shows the average number of requests per IP in 5-minute intervals from our Azure Front Door demo environment within a 7-day period. Most intervals fall between 1 to 5 requests per IP, indicating normal user behavior. However, there are occasional spikes, such as 15.5 requests at 4:10 PM and a significant burst of 459 requests at 4:15 AM. This highlights the importance of using real data to set thresholds. While a baseline of 20–30 requests per 5 minutes would cover typical traffic, it would still catch outlier spikes like these that may indicate abuse or automation.

 

Query 2: Max requests seen from a client IP (5-minute window)

This query surfaces the maximum number of requests observed from any individual IP address in a single 5-minute time window. This helps you understand peak load behavior, which could be from a legitimate spike or a potential abuse/bot.

Usage: Use this to define an upper threshold for rate limiting. To avoid overfitting outliers, consider setting your limit near the 95th percentile of these max values.

The screenshot below shows the results of the KQL query executed in my demo environment using Azure Front Door diagnostic logs within a 7-day period. As observed, the most active IP (35.X.X.X) recorded a peak of 459 requests within a 5-minute window, which is significantly higher than the rest. The second highest IP peaked at 106 requests, and most of the client IPs fell well below 30 requests per 5 minutes. This distribution highlights an important insight: while most users exhibit moderate request behavior, a few outliers can generate large bursts. These outliers could be misconfigured clients, aggressive bots, or potential abuse cases.

 

When configuring rate limits, it’s advisable to base your threshold not on the absolute maximum (459), but rather on a statistical percentile such as the 90th or 95th percentile. In this case, a reasonable threshold might be around 120–150 requests per 5 minutes, allowing headroom for legitimate high-traffic users while still blocking abnormal spikes.

Query 3: Most active IP per country (Geo-aware limit tuning)

This query identifies the top-requesting IP address per country for each 5-minute window. Seeing regional traffic patterns allows you to detect suspicious activity from specific geographies or apply geo-based rate limits.

Azure Front Door:

 

Usage: Use this to justify stricter thresholds for high-traffic countries or create region-specific custom WAF rules.

The screenshot below shows the output of the geo-based query, which identifies the most active IP address per country in 5-minute intervals. As observed, some IPs consistently generate higher request volumes than others, indicating regional traffic concentration or potential anomalies. This pattern can help inform geo-specific rate limiting strategies, where regions with higher activity may warrant stricter thresholds or additional monitoring to mitigate localized abuse without impacting global user experience.

 

Query 4: Request trends per URI segment

This query breaks down requests by the first segment of the URI path (e.g., /api, /assets). It helps identify which parts of your app are most accessed.

Azure Front Door:

 

Usage: Endpoints such as /login or /register are often targets for abuse. Segment-level analysis helps you target rate limits to specific parts of your app.

The screenshot below shows the request distribution across the first URI segment (or resource) in 5-minute intervals. From the data, it’s clear that certain endpoints such as those serving static files (e.g., /styles.css) or known paths like /favicon.ico have consistent but low traffic. However, there are sudden spikes, such as 27 requests to /styles.css and 56 requests to /checkout.html, which could indicate automation, scraping, or testing behavior. Tracking usage by URI segment helps you identify which parts of your app are under heavy or suspicious load. You can use this insight to apply URI-specific rate limiting rules, especially for sensitive or high-traffic paths (e.g., /checkout, /login, /debug). This minimizes the risk of abuse without throttling static content or safe endpoints.

 

Query 5: Average requests per full URI

This query calculates the average number of requests per full URI across all 5-minute intervals. It helps identify high-traffic endpoints. Endpoints with consistently high traffic may need dedicated rate limits.

Azure Front Door:

 

Usage: Use this to create path-specific rules; for example, /login may need a stricter threshold than /homepage.

The screenshot below shows the results of the query, highlighting which full URIs receive the highest average number of requests over 5-minute intervals. The results show frequent access to specific assets (e.g., /favicon.ico, /styles.css), REST API endpoints, and one suspicious XSS injection attempt with unusually high traffic. This insight helps identify abuse patterns, automated scans, or popular resources, guiding you to apply rate limits more precisely either globally or per path to protect critical or vulnerable endpoints.

Guidance and Considerations

The KQL queries and thresholds shared in this blog are intended as guidance based on common patterns and demo environments. Traffic behavior varies across applications, and you should validate results against your own environment and adjust thresholds accordingly. Always test custom rules in Detection mode before enforcing them in Prevention mode to avoid disrupting legitimate traffic.

It’s also important to consider the scalability of the application or backend service behind Azure Front Door. Rate limiting controls traffic, but if your app runs on a single instance or doesn’t scale well, it may still fail under load. As a best practice, ensure your services can auto scale or handle spikes gracefully in tandem with WAF rate limiting rules.

Conclusion

Configuring effective rate limiting in Azure Front Door WAF is not just about setting arbitrary thresholds. It requires understanding how your application is accessed and where traffic patterns indicate potential abuse or anomalies. By leveraging diagnostic logs and analyzing real-world traffic with KQL, you can create rate limit rules that are both protective and practical. This data-driven approach helps you to reduce noise, prevent misuse, and maintain a smooth experience for legitimate users.

References

What is Azure Web Application Firewall on Azure Front Door? | Microsoft Learn

Web application firewall custom rule for Azure Front Door | Microsoft Learn

Web application firewall rate limiting for Azure Front Door | Microsoft Learn

Azure Web Application Firewall monitoring and logging | Microsoft Learn