DDoS overflow + scrubber sizing
A distributed denial-of-service attack is a flood of junk traffic from thousands of sources, all pointed at your front door at once. None of it is a real customer; all of it costs you bandwidth. The attack does not try to break in — it just tries to fill the pipe so completely that nothing legitimate can get through.
If you have a scrubber appliance racked, it absorbs attack traffic up to its rated size and lets the clean traffic pass. Whatever the attack throws over that rating spills past the scrubber, sails straight to your uplinks, and crowds out genuine customer requests. Their slowest requests get slower, your p99 dashboards flash red, and your uptime promises start to break.
The hard truth: you cannot install your way out of an attack in progress. Racking a scrubber while the flood is landing does not undo the damage already done — the capacity has to exist before the first packet arrives. The lever is foresight. Size your scrubbing ahead of demand, watch which customers attract attention, and treat the calm days as the only time you get to prepare.
Detailed explanation
A DDoS is an DdosStarted { gbps, hours } event. Scrubber appliances soak attack traffic up to their combined rated Gbps; overflow = max(attack_gbps - total_scrubber_gbps, 0) lands on the uplinks and steals capacity from real arrivals. While the attack is live the engine drops a fixed fraction of incoming requests — the overflow does not merely add latency, it removes serviceable throughput, so the tail latency you see is the symptom of dropped and re-queued work.
Scrubbers rack like any other appliance — they must be mounted, powered and reachable to count. There is no in-attack remediation path: an appliance installed after DdosStarted fires contributes nothing to the burst it missed. Sizing is a capacity-planning exercise driven by your exposure (public-facing services, high-profile tenants) rather than a runbook step you execute when the alert pages you.