Coordinating and executing load and stress testing on AEM as a Cloud Service
Load, stress, and volume tests against AEMaaCS environments get mistaken for malicious traffic and blocked when they aren’t coordinated with Adobe in advance. The cause is the platform’s automated, non-disableable volumetric DDoS protection, which blocks traffic patterns that resemble attacks, combined with notifications that lack the detail Support needs to prepare for the test window. Gathering the required test information, opening a Support case several days ahead, confirming the test type is allowed, and executing within the agreed window lets legitimate testing proceed without tripping platform protections.
Description description
Issue: AEMaaCS DDoS protection blocks uncoordinated load and stress test traffic
Description
Customers regularly run performance, load, stress, or volume tests against AEMaaCS environments. Without proper coordination, these tests are mistaken for malicious traffic or unintentionally violate AEMaaCS traffic protection rules, and high-volume tests are blocked automatically by the platform’s DDoS protections. Proper planning, advance notification with the required details, and an understanding of which test types are allowed keep legitimate testing from being misidentified.
Environment:
- Adobe Experience Manager as a Cloud Service (AEMaaCS)
- AEM Managed Services
- AEM as a Cloud Service — Sites
- AEMaaCS Dispatcher and CDN tiers with volumetric DDoS protection
Issue/Symptoms:
- Large volumes of test traffic are automatically blocked, with statuses such as DDOSRateLimittedRule_miss_pass_rl_tls1000rps.
- Customer-initiated load testing is rejected or disallowed when traffic exceeds AEMaaCS DDoS thresholds.
Root cause:
AEMaaCS includes automated, non-disableable volumetric DDoS protection. When load tests produce traffic patterns similar to attacks, these systems block the requests. Customers also provide insufficient information when notifying Adobe, which prevents Support from validating and preparing for the test window. Without proper coordination, legitimate testing traffic is misidentified as malicious or exceeds the platform protection thresholds.
How to confirm
- Confirm the blocked traffic correlates with your test window and originates from your load generators rather than from real users.
- Review the response statuses for DDoS rate-limiting signatures, such as DDOSRateLimittedRule values or an HTTP 601 status, which indicate the platform protection blocked the request rather than the application failing.
Resolution resolution
-
Gather the mandatory test information before notifying Adobe:
- Domains in scope.
- IP addresses of the load generators.
- Test start and end times.
- Peak expected requests per second (RPS).
- Confirmation that no DDoS attack simulation will be performed.
If the exact IPs or RPS aren’t known, delay the test until they’re confirmed — Adobe can’t approve an incomplete notification.
-
Open an Adobe Support case at least several days before the test, with a title such as
Load/Performance Test Notification – <EnvironmentID>, and include all the information from the previous step. If there’s no response within one business day, re-comment on the case to update it. -
Confirm the environment type (Stage or Production) and include the environment URL so Support classifies the request correctly:
code language-none https://publish-pXXXXX-eYYYYYY.adobeaemcloud.comIf the classification is unclear, provide the explicit program ID and environment ID.
-
Validate that the test type is allowed. Confirm the test doesn’t include any form of DDoS or volumetric flooding. If it does, redesign the test — AEMaaCS doesn’t allow that kind of testing, and DDoS protection can’t be disabled.
-
Execute the test within the planned window using your load tool (JMeter, ToughDay, or similar). Monitor the client-side performance results. If you observe blocked traffic, reduce the load or refine the request patterns.
-
Inform Adobe after the test completes by updating the case to confirm the test is finished, so Support closes the case or provides monitoring results.
Validation
- Confirm test traffic is no longer blocked by DDoS rules by reviewing your own reports or the monitoring outputs Support provides.
- Confirm no additional load-related alerts occurred during the test window.