Front Door WAF rate-limit rule: groupBy 'None' rejected with "allowlisted for Developer Preview" error

Question

Front Door WAF rate-limit rule: groupBy 'None' rejected with "allowlisted for Developer Preview" error

Oscar Pairazaman 20

I'm deploying an Azure Front Door Standard WAF policy via Bicep (Microsoft.Network/FrontDoorWebApplicationFirewallPolicies@2024-02-01, sku Standard_AzureFrontDoor) with a RateLimitRule custom rule that uses groupBy: [{ variableName: 'None' }] to share one counter across all IPs matching the rule (rate-limiting a known crawler's published IP range as a backstop against an abnormal flood, not a per-client throttle).

Deployment fails with:

WebApplicationFirewallPolicy validation failed. "Group by dimension 'None' is only available to subscriptions allowlisted for Developer Preview. Rule Name: RateLimitGooglebot"

This isn't documented anywhere I could find:

The ARM/Bicep schema reference for GroupByVariable.variableName lists 'GeoLocation' | 'None' | 'SocketAddr' with no preview note (https://learn.microsoft.com/en-us/azure/templates/microsoft.network/frontdoorwebapplicationfirewallpolicies).
The WAF rate-limiting and custom-rules Learn articles don't mention any restriction on groupBy values.
A Microsoft Q&A thread (2337012) shows another user being told the acceptable groupBy values are "SocketAddr, GeoLocation, None" with no caveat.

This looks like the same pattern as a previously confirmed platform bug where a stale DeveloperPreview flag check was left on a feature meant to be GA (Microsoft_DefaultRuleSet_2.2, confirmed and fixed by the product team, see https://learn.microsoft.com/en-us/answers/questions/5646066).

Questions:

Is groupBy: 'None' actually gated behind an allowlist today, or is this the same kind of leftover DeveloperPreview validation as the DRS 2.2 case?
If it's an intentional restriction, how can a subscription request allowlisting?
If it's a bug, is there a tracked timeline for the fix?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

The deployment error is the important signal here: ‘None’ is present in the resource schema, but the Front Door WAF control plane is still enforcing a subscription allowlist for that grouping mode. A schema enum means the API can parse the value; it does not by itself mean the feature is enabled for every subscription.

I would therefore treat this as a feature-gating issue rather than a Bicep syntax problem. The DRS 2.2 incident is a useful precedent to raise with Support, but it is not enough to conclude that this is the same defect.

There does not appear to be a documented self-service registration path or public delivery date for ‘groupBy: None’ on Front Door WAF. Open an Azure support request and include the full validation error, subscription ID, WAF policy resource ID, SKU, API version, deployment timestamp, and correlation ID. Ask the Front Door WAF product team to confirm whether the subscription is eligible for that Developer Preview and, if not, whether there is a supported alternative or planned GA path. That is the only reliable route for an allowlist decision.

For a deployable workaround today, use ‘SocketAddr’ grouping (or omit the grouping only if your tested policy resolves to that supported default) and keep the match as narrow as possible: the crawler’s published CIDRs and, where appropriate, the expected request characteristics. That is not equivalent to a single shared counter—each source address gets its own counter—but it is the supported per-client protection model.

If you genuinely need one aggregate budget across every matching address, enforce that budget at a layer that owns shared state, such as the origin/application, API Management, or a dedicated rate-limiting component. Also avoid treating a Front Door WAF rate-limit threshold as a precise quota: Front Door processes traffic on distributed edge infrastructure, so it is intended for abuse mitigation rather than exact request accounting.

Useful references:

I would not switch to ‘GeoLocation’ for this use case unless a country-level shared bucket is actually acceptable; it changes the protection semantics and can block unrelated legitimate traffic from the same geography.