Rate limiting CDN

[VishnuRa5]

I am trying to implement rate limiting at the CDN level in AEMaaCS.

I am testing this in an RDE using rules referenced in the Adobe documentation. However:

• The rate limit is not being triggered

• I tried multiple variations

• I expected a 429 Too Many Requests response, but never received it

• Is 429 the default HTTP error returned when a CDN rate limit is exceeded?

• Is there already a default rate limit applied at the CDN layer in AEMaaCS?

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/security/traffic...

kind: "CDN"
version: "1"
data:
  trafficFilters:
    rules:
    - name: limit-requests-client-ip
      when:
        reqProperty: tier
        matches: "author|publish"
      rateLimit:
        limit: 60
        window: 10
        penalty: 300
        count: all
        groupBy:
          - reqProperty: clientIp
      action: block

Any suggestions for fine-tuning the rate-limit configuration, and is there a recommended way to test it?

Thankyou very much !!

[gkalyan]

@VishnuRa5 

Adobe's default for all custom blocking rules (including WAF and rate limits) is 406 Not Acceptable

In order to receive 429, you need to add it in the "action". like below.

action:

type: block

status: 429

RDEs do not sync CDN rules from Git, You must push them manually to environment config using Adobe I/O CLI. 

Also, try hitting the page with curl instead of directly from the browser to to see if the rule is triggering.

[muskaanchandwani]

Hello @VishnuRa5 

Your rule is valid, but your threshold is too high for your tests.
limit: 60 with window: 10 means: block only when a single IP sends >600 requests in 10 seconds (average >60 rps). Light curl loops won’t ever trigger it.

limit is “requests per second”, not “requests per window”.
Effective threshold is:
rps = requests in window/window(seconds)

Rule fires when that average exceeds limit.

Use lower limits when testing.
For an RDE test, use something like:

rateLimit:
limit: 10
window: 10
penalty: 60
count: all
groupBy:
- reqProperty: clientIp
action:
type: block
status: 429

429 is not the default for your custom CDN rule.
- For traffic filter rules (cdn.yaml), action: block defaults to 406 unless you set status: 429.
- For Adobe’s built‑in Fastly DDoS limiter, 429 is the default when it’s triggered.
References:
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/security/traffic...

https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-25100

Yes, AEMaaCS has a default DDoS limiter at CDN, but not a “business” rate limit.

The global Fastly ratelimiter (Adobe‑managed) is always on and will return 429 only for very high bursts to protect infrastructure.
Your business‑specific limits (like “60 in 10 seconds per IP”) are not present by default; they only exist if you add them in cdn.yaml.

Start from Adobe’s starter rules (500 rps edge, 100 rps origin per IP) and deploy in log mode:
https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/security/traffic-f...

Check CDN logs to see if they would block legitimate traffic; adjust limit and window.
Switch to action: block once you’re confident.

Recommended way to test:
- Don’t rely on serial curl loops; they rarely reach >10 rps.

Use a load tool (vegeta as in the docs) to generate enough parallel requests from one IP, for example:

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/security/traffic-f...

[lavishvasuja]

@VishnuRa5 -

For CDN rate limiting in AEMaaCS:

• Thresholds: Limits are evaluated in requests per second, not per window. Use lower thresholds when testing to reliably trigger the rule.

• HTTP status: Blocked requests default to 406; set status: 429 explicitly if you want the standard “Too Many Requests” response.

• Defaults: Adobe’s CDN provides DDoS protection, but per-IP rate limits must be configured via your traffic filter rules.

• Testing: Generate parallel requests from a single IP using tools like curl or load generators. Push RDE rules via Adobe I/O CLI; CLI-based tests give clearer visibility than browser testing.