Sizing for the Peak You Already Have: DDoS Capacity Planning Around National Event Windows

Almost every DDoS sizing exercise asks the same question: how large an attack should this design survive? It is a reasonable question and it produces a number, and the number is wrong for a particular case that a Saudi operations team faces on a known schedule.

The case is not a larger attack. It is an ordinary attack arriving while legitimate load is already at its annual maximum — the Hajj period, the Ramadan and Eid retail and payment peaks, a national event window. What makes it worth its own guide is not that traffic is high. It is that four things which normally fail independently fail together, and the design that handled each of them separately handles none of them at once.

Nothing below depends on any statistic about how much traffic a particular event generates. The argument is structural, and the only numbers that matter in it are your own.

Four things that break together

Your headroom is already spent. An on-premise appliance protects you while your access circuit is not full; above that, the circuit is saturated before the appliance sees anything useful. During a peak, legitimate traffic is consuming an unusual share of that circuit — so the attack volume needed to fill it is smaller, by exactly the amount the peak is consuming. An attack that your March sizing exercise classified as comfortably absorbable can be, in this window, an attack that saturates the link.

Your baselines are describing a different service. Behavioural detection learns what normal looks like from recent history, and recent history in most products means days. Peak traffic is genuinely different — in volume, in time-of-day distribution, in geography, in device mix, in which endpoints get hit. The detector does what it was built to do and concludes that a large fraction of your real users are anomalous. Its worst false-positive rate coincides precisely with the period in which a false positive is most expensive.

You cannot tune your way out of it. The implicit plan behind most thresholds is we will adjust during the incident. During these windows a change freeze is usually in force — often the strictest of the year, and correctly so. The plan is unavailable at the only moment it was needed.

The runbook has never met this traffic. The diversion procedure has been exercised, if at all, against ordinary weekday traffic. It has never been exercised against a shape that occurs once a year, with volumes the team sees once a year, in a period when the people who know the procedure are on a rota that is also different from usual.

Each of the four is manageable. Together they describe a scenario where every mitigation you had planned is either unavailable or mis-tuned.

The fix is mostly process, and it is cheap

Three of the four are process problems, which is good news: process is far cheaper than capacity.

Rehearse against peak baselines, not average ones. This requires having peak baselines, which requires capturing the peak. The single highest-return action an operations team can take during one of these windows is to store a representative capture of it — full or sampled, whatever the storage budget allows. That capture becomes next year’s test corpus: for tuning, for exercising the runbook, and for putting a candidate appliance through a proof of concept against traffic that actually resembles the hard case rather than against synthetic floods.

Pre-authorise diversion before the freeze window opens. Not the technical steps, which are already documented, but the decision. Who may trigger it, on what observed condition, with what notification and what time limit. If that is settled in writing a fortnight before the window, then the action during the window is the execution of an existing decision rather than a new decision requiring an exception to a freeze. This costs one meeting and removes the most common source of delay.

Set thresholds for the window in advance, and set them deliberately. If the detector cannot hold a seasonal profile, then the honest response is to choose, before the window, which way you would rather be wrong — and to write down why. A team that has consciously accepted reduced sensitivity for a defined period, with compensating monitoring, is in a different position from a team that discovers mid-incident that it cannot change anything.

Hold packet-level evidence locally. The post-event review of an incident during a national window will involve people who were not in the operations centre — executives, regulators, sometimes the public. The questions will be specific and will arrive weeks later. Producing the answer from your own storage, on a retention period you set, is a query; requesting it from a third party is a support ticket answered inside their retention window. This is the same argument the licence-obligation guide makes for operators, arriving here by a different route.

The one thing that is a purchasing requirement

The fourth problem — baselines learned from a rolling window — is not fixable by process, and it is the item worth putting in a tender.

The requirement is that the device can retain and apply a traffic profile learned from a period other than the immediately preceding days. Phrased for a specification: the system shall support retention and selective application of a learned baseline captured during a defined historical window, and shall permit that profile to be applied as the reference for anomaly detection during a nominated future period.

That is testable. Give a candidate a stored capture from last year’s peak, replay it as current traffic, and observe what the detector concludes — with and without the seasonal profile applied. The difference between products here is large, it separates appliance classes rather than models, and it almost never appears in a datasheet because the buyers who need it are a minority of the market.

Two related properties are worth checking at the same time, because they interact with the freeze problem. Whether policy can be scheduled — a profile that activates on a date, without a human making a change during the window — and whether detection depends on anything outside your network, since an external dependency is one more thing that can behave unexpectedly during a period of unusual regional load. HARPP DDoS Mitigator runs its detection on the customer’s own infrastructure, which means the tuning done against a stored peak capture stays applicable regardless of what any external service is doing; whether its baselining supports a seasonal profile in the form you need is exactly the thing to put in the proof of concept rather than to take on trust. Radware DefensePro has a strong behavioural pedigree and is the other obvious candidate to test this way.

Appliance	Sized for the average week	Sized for the coincident peak
Headroom assumed	Circuit utilisation at a typical level	Circuit already carrying its annual maximum
Detection baseline	Rolling window, retrained continuously	Seasonal profile, held from the previous cycle
False positives at the worst moment	Highest, because normal looks abnormal	Contained, because this normal was learned
Tuning during the incident	Assumed available	Unavailable — change freeze in force
Diversion authority	Decided when needed	Pre-authorised before the freeze window opens
Runbook rehearsal	Against ordinary traffic	Against a replay of last year's peak
What the vendor must demonstrate	Throughput at line rate	That baselining can hold a seasonal profile

The last row is the one that separates appliance classes, and it is almost never in a tender. Everything above it is process, and process is cheaper than capacity.

A calendar-shaped checklist

Working backwards from a known window:

Twelve weeks before. Confirm the freeze dates. Identify which services carry the peak. Retrieve last year’s capture if one exists; if not, schedule this year’s.

Six weeks before. Rehearse the diversion runbook against the stored peak capture, not against ordinary traffic. Measure decision-to-mitigation on your own network rather than accepting the upstream provider’s published figure.

Two weeks before. Pre-authorise diversion in writing: trigger condition, authority level, notification list, time limit, review point. Apply or schedule the seasonal detection profile. Confirm with the upstream provider what their behaviour is if many of their customers in the region divert simultaneously.

During. Capture. Whatever else happens, capture — this window is the only source of the corpus that makes next year cheaper.

Four weeks after. Review with the capture in hand. What fired, what should have, what did the detector call wrong, and what would you have changed if the freeze had allowed it. That list is next year’s tuning plan, and it is worth more than any vendor’s tuning recommendation because it is about your traffic.

The honest limit

None of this creates capacity. If the coincident volume exceeds your access circuit, the local tier has lost before it sees a packet, and the answer is upstream capacity engaged through a procedure that was agreed before the freeze. The value of everything above is that it moves the point at which you need that upstream tier, makes the handover deliberate rather than panicked, and stops the detector from creating a second incident inside the first one.

And a team that already runs seasonal profiles, rehearses against captured peaks and pre-authorises diversion does not need this guide. In our experience that team is rarer than the practice deserves — the analysis is not difficult, it simply belongs to a calendar rather than to a project, and calendars have no budget owner.

Sources and further reading

The relevant inputs here are all internal: your own flow records at the border, your own circuit utilisation history, your own freeze calendar. For the sizing question in general, see the architecture comparison; for what changes when the service is sold to subscribers under a licence, see DDoS as a licence obligation.