One attack,
as the node recorded it.
Most security vendors assert capability and very few show it. This page is one real incident: a distributed flood against a production node, described with the figures the node measured while it was happening. Nothing here is modelled, projected, or rounded in our favour.
What the counters say.
Six numbers read off the node serving this page, right now. Not a case study and not a screenshot: the page polls the edge every couple of seconds, and the peak is a standing record.
These are this hostname's own counters, not the whole edge and not another customer's traffic. Distinct sources are estimated rather than counted exactly, because keeping the full set of addresses an attacker chooses would be the memory-exhaustion bug this product exists to prevent. Everything else is a plain total, and nothing has been added around it to make a better story.
605,430
requests per second, absorbed
That figure is not from the incident described above. It is the largest flood this network has taken, roughly eight times the one on this page, and we publish it as a ceiling we have actually reached rather than a capacity we estimate.
The incident above is the one documented in detail, because it is the one where every counter quoted was read while the attack was still running. A bigger number with a thinner account behind it is worth less than a smaller number you can check.
Incoming request rate
Two measurements, two minutes apartWhere it came from
Sampled during the floodWhat happened, in order.
The same event told once, from the first sign of the climb to the state of the node after it.
The rise
The rate doubled in two minutes.
Incoming requests to the node were arriving at roughly 37,000 per second. Two minutes later the sustained rate was 75,418 per second, and it stayed there. Every other measurement on this page was taken while it was holding at that level.
The shape
No single address looked abusive.
A 1,500 event sample of the traffic contained 1,206 distinct source addresses, at a median of one request per address. That is what distributed means in practice. There was no heavy hitter to find and ban, and a rule written against any one of those addresses would have removed almost nothing from the flood.
The response
The ordinary pipeline, not a special mode.
Nothing was switched on for the occasion. The traffic met the same sequence every request meets: packet filtering inside the network driver, connection admission before a handshake, and proof-of-work challenges. Two guard rules did the work, one for the site-wide under-attack posture and one for clients that had been issued a challenge and never solved it.
Meanwhile
Legitimate requests were served in 3.3 milliseconds.
Throughout the flood, real requests were answered in 3.3 milliseconds. System load average was 2.12 across 64 cores, roughly 3 percent of the CPU on the machine, and resident memory stayed flat at about 2 GB. The node was not straining against the attack, it was doing its usual job with an attack attached.
The ledger
290.4 million requests seen, most of them refused.
Lifetime counters on that node stood at 290.4 million requests seen, of which the overwhelming majority were refused rather than forwarded. Refusing is not the exception in this system. It is the majority of what the machine has ever done.
$0
Not one refused request was billable.
Nothing, and that is the billing contract.
Quota counts one thing: legitimate requests the node forwards to your origin. The flood was refused, so it was never counted. There is no surcharge for being attacked, no overage triggered by the volume, and no separate line for mitigation, because refusing traffic is the product rather than an extra.
The practical effect is that the size of an attack has no relationship to the size of the invoice. A customer on the smallest plan would have paid the same for this incident as a customer on the largest one, which is nothing.
What this incident does not prove.
One event is evidence, not a guarantee. Here is the part of the page a case study normally leaves out, because a number is only worth something when you also know what it cannot tell you.
One incident, one node
This is a single event on a single machine. It shows what the pipeline did against this attack at this size. It is not an average, not a service level, and not a promise about the next one.
75,418 is not a ceiling
It is the rate this attack reached, not the rate at which the node stops coping. The load figures suggest there was room left, but room you infer from a load average is not capacity anyone has measured. We do not know where the limit is, because this attack did not find it.
The address count is a sample
1,206 distinct addresses were counted in a 1,500 event sample, not in a census of the whole flood. The sample says the traffic was spread across at least that many sources. It does not give a total, and no total is claimed here.
Load average is a coarse instrument
2.12 across 64 cores says the machine was nowhere near saturation at that moment. It does not describe the shape of the curve at ten times the rate, and an average can hide a short spike inside it.
Your traffic is not this traffic
A flood of requests that are individually expensive at the origin behaves differently from this one. What generalises is the mechanism, filtering below the socket, admission control and proof of work, not these particular numbers.
Anonymity cuts both ways
Because the customer is not named, you cannot call them and check. That is a real cost of publishing an anonymised incident, it is the right trade for the customer, and you should weigh this page accordingly.
Ask harder questions than this page answers.
What the pipeline does against a flood shaped like yours, how challenge difficulty behaves under sustained pressure, what the counters look like on a node carrying your traffic profile. An engineer will answer with specifics, and will say so plainly where the honest answer is that we have not measured it.