DDoS Testing Sign-Off: AWS vs Cloudflare

The short answer

AWS Shield Advanced and Cloudflare gate authorized DDoS testing through two different mechanisms. AWS's sign-off is a technical threshold: an approved DDoS Test Partner can run a simulation without extra approval as long as it stays under 20 Gbps, 50,000 requests per second, and a packet-rate cap — go above that, and you need an exception request filed at least 14 days ahead, or a Shield Response Team (SRT) firedrill instead. Cloudflare's sign-off is an ownership check, not a permission gate: its published policy says you don't need Cloudflare's approval to test your own onboarded, non-shared property at all. For a crypto exchange, that means the provider you're behind determines whether test day is blocked by a form or blocked by nothing — and either way, the sign-off that actually matters most is internal: who owns abort authority, and who confirms the test window doesn't collide with custody or settlement operations.

Who this is for

This is written for whoever is trying to schedule an authorized DDoS stress test against a crypto exchange's production edge and has hit the same question from two directions at once: "what does our cloud/edge provider require before we can send this traffic," and "who internally has to say yes first." It assumes you already know why you're testing — for the RoE mechanics, baseline capture, and abort-condition discipline that apply regardless of provider, see scoping DDoS stress testing for an online casino, which this post does not repeat. It is specifically about the sign-off chain: two external tracks that differ by provider, and one internal track that doesn't appear in either provider's documentation at all.

Two sign-off tracks, not one

Teams scoping their first authorized DDoS test tend to treat "provider approval" as a single checkbox. It isn't. There are two separate tracks, and conflating them is how a test gets scheduled and then blocked the week of:

• External, provider-side. What AWS or Cloudflare require — or don't — before traffic you generate against your own resource is treated as legitimate rather than a real attack.
• Internal, exchange-side. Who inside your organization has to approve the test window, independent of what the provider requires, because the test can still collide with something the provider has no visibility into — a scheduled settlement batch, a custody-key rotation, an on-call handoff.

The two tracks run on different clocks. Provider-side approval (when required) can take weeks; internal sign-off can take a single Slack thread if the right people are looped in early, or weeks if they aren't.

External track: AWS Shield Advanced's sign-off is a threshold

AWS publishes its DDoS simulation testing policy directly, and the constraint is quantitative, not conversational. There are two paths:

Path	Who runs it	Approval needed	Ceiling
Partner-run simulation	An AWS-approved DDoS Test Partner, against your own Shield Advanced–protected resource	No separate approval if under threshold	20 Gbps bit volume; 5M pps (CloudFront) or 50,000 pps (other resources); 50,000 requests/sec
SRT firedrill	AWS's own Shield Response Team, as a synthetic simulated event	Requires existing Shield Advanced onboarding	No fixed public ceiling — scoped directly with SRT
Above-threshold or non-partner test	Any vendor exceeding the partner-path ceiling	Exception request required	Must be submitted at least 14 days before the proposed test date, to AWS's DDoS testing review process

The target itself has to qualify too: it must already be registered as a Protected Resource in an AWS account subscribed to Shield Advanced, or be an Amazon API Gateway edge-optimized endpoint in such an account. Skip that step and there's no path to a compliant partner-run test at all, regardless of volume.

For a crypto exchange, the practical read is this: if the test is meant to validate resilience against something resembling a real, motivated attacker — not a light synthetic check — 20 Gbps and 50K rps are not generous ceilings against a well-resourced target. That pushes many realistic exchange test plans onto the exception-request track (14-day minimum lead time) or the SRT firedrill path, both of which need to be in the project timeline from day one, not discovered the week before.

External track: Cloudflare's sign-off is ownership, not permission

Cloudflare's published documentation states plainly that customers do not need Cloudflare's permission to run a DDoS simulation against their own Internet property. There is no partner program, no volume ceiling, and no advance-notice form in the official policy — the requirement is that the target is your own, is not shared with another organization, and is onboarded to Cloudflare under an account you own.

That is a materially different shape of gate than AWS's. It removes the external approval step entirely for a qualifying property, which means the rate-limiting factor for a Cloudflare-fronted exchange shifts almost entirely to the internal track below — there is no provider-side clock to build lead time around.

Two things this doesn't cover, and where teams get it wrong:

• A shared or multi-tenant Cloudflare setup (common if the exchange sits behind an agency, reseller, or shared enterprise account) doesn't qualify under "your own Internet property" — that ownership question needs a real answer before assuming the no-permission policy applies.
• "No permission needed" is not "no coordination needed." Even without a formal approval gate, a large test can still trip Cloudflare's own automated mitigation the same way an unannounced real attack would, which can quietly invalidate the test's results without producing an outage severe enough to notice mid-test.

Internal track: the sign-offs neither provider's policy mentions

Neither AWS's threshold nor Cloudflare's ownership check has any visibility into what's actually running on a crypto exchange during the proposed test window. That's the exchange's own responsibility to line up, and in AnySec's experience scoping these engagements, three roles come up every time:

1. RoE and abort authority — usually the CISO or Head of Infrastructure. One named person on each side who can halt the test immediately, reachable by phone, not a ticket queue. This is the same discipline scoping DDoS stress testing for an online casino covers for authorization generally — it applies unchanged here.
2. Custody and security-ops on-call — the person who can confirm the test window doesn't overlap a withdrawal-processing batch, a custody-key rotation, or a scheduled cold-to-hot wallet transfer. A DDoS test that degrades the API layer during one of those operations turns a controlled experiment into an actual incident, independent of whether the provider's mitigation held.
3. The banking or liquidity-partner relationship owner, if the exchange's uptime is contractually tied to a partner's SLA. Some banking and liquidity partners have their own notification expectations for planned load against systems they depend on — that's a business relationship, not a technical requirement from AWS or Cloudflare, and it doesn't show up in either provider's testing policy.

Miss any of these and the provider-side approval — however smooth — doesn't protect you from a test-day collision with something the provider was never in a position to see.

Sequencing: which sign-off to chase first

The order that avoids the most wasted weeks:

1. Identify which provider actually sits in the traffic path being tested, and at what realistic volume. If it's AWS Shield Advanced and the planned volume is anywhere near or above the partner-path ceiling, start the exception-request or SRT conversation immediately — its 14-day-minimum clock is the longest lead time in the whole process and should run in parallel with everything else, not after it.
2. Confirm the target's eligibility on whichever provider — Shield Advanced registration and account ownership for AWS, non-shared account ownership for Cloudflare — before assuming either policy applies.
3. Line up the three internal roles above in parallel, not sequentially. The RoE owner, the custody/security-ops on-call, and the partner-relationship owner (if applicable) can all be looped in the same week the provider conversation starts.
4. Only then pick the test window, once both tracks confirm they're clear — provider approval (or its absence) plus every internal stakeholder's "no conflict" on that specific date.

Skipping straight to picking a date and working backward is the most common way this slips: a date gets set, the AWS exception request turns out to need two more weeks than expected, or the custody team flags a conflicting settlement batch, and the whole engagement reschedules.

What this doesn't cover

This is specifically about the sign-off chain — who has to say yes, on what clock, before an authorized DDoS test can run. It does not cover how to scope which layers, endpoints, and vectors belong in the test itself; that's the RoE and scoping discipline in scoping DDoS stress testing for an online casino, which applies to a crypto exchange the same way. It also does not cover whether a DDoS stress test is the right engagement at all versus an ordinary load test — see load testing vs DDoS stress testing if that's still an open question. And it doesn't replace scoping a penetration test for a crypto exchange, which covers custody and application-layer testing outside the DDoS scope entirely.

Getting the sign-off chain scoped

If you know which provider sits in your traffic path but haven't mapped the internal side yet, tell us your setup and we'll help sequence the provider conversation and the internal sign-offs so neither one blocks the other on test week.

Sources and review

AWS testing thresholds and the partner/SRT/exception-request structure are drawn directly from AWS's published DDoS simulation testing policy and security blog (aws.amazon.com/security/ddos-simulation-testing/ and the AWS Security Blog's "Understanding DDoS simulation testing at AWS"). Cloudflare's no-permission policy and ownership requirements are drawn directly from Cloudflare's official DDoS Protection documentation (developers.cloudflare.com/ddos-protection/reference/simulate-ddos-attack/). Internal sign-off roles reflect AnySec's own engagement-scoping methodology; no third-party numbers are cited for that section. Author: AnySec Engineering. Published 2026-08-24.

---

Related reading

• Scoping DDoS stress testing for an online casino — the RoE, provider-coordination, and abort-condition discipline this post assumes and doesn't repeat.
• Load testing vs DDoS stress testing — how to tell which engagement you need before you scope either one.
• Scoping a penetration test for a crypto exchange — custody and application-layer testing outside the DDoS scope covered here.