One short spoofed query returns a reply tens or hundreds of times its size. That asymmetry is the whole of an amplification attack, and it is why a modestly resourced attacker can throw terabit-scale volume that a DDoS test has to reproduce without a matching botnet behind it. The attacker never sends the flood directly; a fleet of innocent third-party servers sends it for them, each one answering a tiny request with a large response aimed at the victim.
How an amplification attack works
The mechanism rides on connectionless protocols. These services run over UDP, which never establishes a session, so the responder gets no chance to check that the return address on a request belongs to whoever actually sent it. It answers the stated source. Put the victim's address in that field and the entire conversation is redirected: the victim receives replies to questions it never asked. That forged-source step is reflection: using a third party to bounce traffic and hide its origin. Amplification is the second ingredient, the size gap between the request and the reply. Most public UDP services do both at once, which is why the two terms are so often used interchangeably even though they name different properties, one about direction and one about magnitude.
The number that quantifies it is the amplification factor, the response bytes divided by the request bytes. It varies enormously by protocol: a DNS ANY query returns tens of times its size, NTP's monlist command hundreds, and an exposed memcached server can return a five-figure multiple. The higher the factor, the less outbound traffic the attacker needs to commit, so the entire economics of the attack live in that ratio.
Why it matters under attack
Amplification is the reason volumetric floods reach magnitudes no origin link can absorb, so the burden falls on upstream capacity rather than anything the target can configure. The traffic arriving at the victim is not obviously hostile: it is well-formed responses from thousands of real, legitimately operated servers, so filtering by source reputation buys little and the volume has to be soaked up rather than blocked.
The root cause sits on networks the victim does not run. Two things would end it: carriers validating that packets leaving their network carry a real source address (BCP 38), and operators closing the open services that act as reflectors. Neither is under the target's control and neither is uniformly deployed, which is precisely why the technique has outlived every prediction of its demise. The archetype and highest-volume member of the family is DNS amplification.
The reflector pool is not static, which shapes how the threat evolves. When a protocol is caught being abused at scale, operators react: after memcached was used for record-setting floods in 2018, distributions began shipping it with UDP disabled by default and networks filtered its port, and the usable pool shrank quickly. Attackers then move to whatever high-factor service is still widely exposed, so the specific protocol in fashion changes from year to year while the underlying arithmetic does not. A test that hard-codes yesterday's reflector misses today's; what stays constant is the ratio and the fact that the flood is legitimate traffic from real servers.
What a DDoS test measures
Because prevention lives elsewhere, a test of the receiving side is a test of absorption. It drives a controlled load shaped like reflected UDP traffic and measures how much of it the edge or scrubbing tier swallows before goodput starts to fall, plus how long the flood keeps reaching the origin before mitigation cuts over.
There is a second question worth putting on the test plan, aimed the other way: is your own infrastructure a usable reflector? An exposed resolver, NTP daemon, or memcached instance turns your network into someone else's weapon and into a source of outbound traffic that can get your prefixes throttled. Whether a given protocol is exercised as a reflector or a target is worked through in DNS Infrastructure Under DDoS.