Authorized DDoS testing is a test practice in which every party that owns or carries the traffic has agreed, in writing and in advance, to the targets, vectors, rates and window of the attack being simulated. That agreement is the only thing separating a DDoS test from an offence, since the packets are built to look the same. (UK documents usually spell it "authorised DDoS testing"; the requirement is identical.) This page describes how the permissions fit together; it is not legal advice, and a real engagement should be checked with your own counsel.
Who has to say yes
Unauthorized denial of service is a crime in most jurisdictions: in the UK it falls under section 3 of the Computer Misuse Act 1990, in the US under the Computer Fraud and Abuse Act. Neither offers an exception for a sender who meant well. What makes a test lawful is permission from the people entitled to give it, and there are usually more of them than the team running the test expects.
The asset owner
The legal owner of the target signs, through someone with real authority over it. An engineer's approval of their own service is not that, and neither is a managed service provider's, unless its contract says so. A tenant of a SaaS platform owns its data, not the platform, so it cannot authorize a flood against the vendor's endpoints.
Every third party in the path
Traffic reaches the target through networks the owner does not control, and each can be harmed or can react:
- The transit carrier or ISP, whose automatic defenses may black-hole the prefix and turn the test into a real outage.
- The CDN or edge provider. A hostname behind a CDN resolves to shared anycast addresses that also serve many other customers. Authorizing the hostname is not authorizing those addresses; only the provider can do that.
- Hosting, colocation and scrubbing providers, whose shared equipment carries the flood before it reaches you.
- SaaS services in the request path (a hosted identity provider, a payment page, a third-party API). These are outside the scope unless that vendor itself agrees, which is rare. A test plans around them.
The cloud provider's published policy
AWS, Azure and Google Cloud each publish rules for testing workloads on their platforms, and each treats simulated DDoS differently from ordinary penetration testing. Azure allows simulated attacks only through its approved testing partners. AWS requires a pre-approved partner working inside published limits, and other vendors must request an exception at least 14 days before the test. Google Cloud asks for no notice for penetration tests that affect only your own projects, but that guidance does not mention denial-of-service testing, so raise any simulated flood with Google first. Thresholds and procedures change, so the authority is always the provider's current published policy, read before every engagement rather than remembered from the last one.
What the authorization has to pin down
A signature on a vague document authorizes very little. The useful version names the exact destination addresses as well as hostnames, the vectors, a peak for each rate dimension, the window with its time zone, the source ranges the generators will use (so the carrier and the SOC can recognize them), and the people with standing authority to stop the test.
Addresses deserve a second check on the day. Cloud IPs are recycled: an elastic or public address released during a migration can be reassigned to another tenant within hours. A test aimed at the address that was in scope last week can land on a stranger. Re-resolving every target and confirming ownership just before the window closes that gap.
What authorization means for the result
Permission defines what a test can prove. The authorization is drawn around the blast radius the owner accepts, and a finding is only as wide as the scope that allowed it, and a dependency the test was not permitted to touch is an unknown, not a pass. A sound report lists what the authorization excluded next to what it measured, so nobody reads a clean result as covering the shared identity service nobody was allowed to flood.
The scope also has to be enforced by the tooling, not just written down. Generators that refuse any destination outside a loaded allowlist make an addressing mistake harmless; a scope that exists only in a PDF relies on nobody mistyping. If you are deciding how much of this applies to a workload in one of the major clouds, the provider's gate and the two lanes of testing it leaves you are set out in cloud DDoS testing.