Configuring and verifying AEM Cloud Service WAF, traffic filter, and DDoS protections
Customers configuring or validating WAF rules, IP blocking, rate limiting, or DDoS protection in AEM often lack visibility into the protections the Adobe Managed CDN and dispatcher layers already enforce. When no custom rules are deployed, only Adobe’s default filter rules apply, and without explicit configuration and monitoring through AEMaaCS logs or Cloud Manager pipelines, the protections look disabled even when they aren’t. Confirming the default protections, deploying traffic filter rules through the Cloud Manager config pipeline, and validating the behavior in CDN logs establishes and proves the security controls.
Description description
Environments:
- Adobe Experience Manager as a Cloud Service (AEMaaCS)
- Adobe Experience Manager On-Premises Software
- Adobe Managed CDN and dispatcher layers
- Cloud Manager config pipeline
Issue/Symptoms:
- Customer security teams observe suspicious or high-volume traffic, such as new DDoS patterns.
- There’s no way to confirm whether rate limiting or automatic blocking is occurring, even after simulated high-volume requests.
Root cause:
Customers often lack visibility into the default traffic protection enforced by the Adobe Managed CDN and dispatcher layers, which include rate limiting, DDoS absorption, and optional WAF rules. When no custom rule configurations are deployed, only Adobe-provided default filter rules apply. Without explicit configuration and monitoring via AEMaaCS logs or Cloud Manager pipelines, customers can’t validate the protections and assume they’re disabled.
How to confirm
- Confirm the default protections are active. Review Adobe’s documentation on the built-in protections — CDN-level DDoS absorption, baseline rate limits, and automatic mitigation when thresholds are exceeded — and confirm with your internal security team that the CDN protections align with their expectations.
- If suspicious activity is observed, collect the timestamps, suspected IPs, and request patterns so Adobe Support can analyze the CDN logs.
Resolution resolution
- Block a specific IP using traffic filter rules. Create a YAML traffic filter rule in your Git repository under the Cloud Manager config pipeline’s traffic-filter rules folder, with a deny action for the target IP. Deploy it via the Cloud Manager config pipeline and confirm the rule appears in the CDN logs. If deployment fails, confirm the YAML formatting follows the documented examples.
- Apply or update rate-limit rules. Define IP-based thresholds for requests per second in YAML following the documented rate-limit structure, redeploy via the config pipeline, and monitor the logs during simulated high-request traffic. If the rules don’t behave as expected, send your YAML configuration to Adobe Support for validation.
- Enable the OWASP ModSecurity CRS on the AEMaaCS dispatcher or on-premises. Apply the latest stable CRS version recommended by Adobe unless its plugins are untested, then trigger benign test payloads to confirm the rules execute in the dispatcher/ModSecurity logs. For CRS versions with untested DoS plugins, revert to a validated CRS version.
- Determine whether a reverse proxy or WAF can sit in front of AEMaaCS. Review your architecture to confirm whether an external reverse proxy or firewall is needed — Adobe allows this when it’s properly configured and points to the Adobe Managed CDN. Perform a load test before production cutover, and confirm the proxy forwards Host headers and TLS configuration correctly.
Validation
- Confirm traffic filter rules are active by viewing the CDN logs for block or deny events associated with the rule change.
- Run a controlled test from a known IP to confirm rate limiting or blocking behavior, and check the dispatcher or CDN logs for matching entries.