Compare always-on and on-demand scrubbing diversion: what does each cost on a quiet day and expose during a flood?

## The two postures When you rent mitigation capacity, the first architectural decision is whether your traffic goes through the provider **all the time** or **only when you are under attack**. Everything else — cost model, latency, exposure window, blast radius — follows from that one choice. ### Always-on Your traffic is steered into the provider's network permanently. Inspection and filtering are running before an attack begins, so the mitigation posture during an attack is identical to the posture five minutes earlier; there is nothing to switch on. What it costs: - **A standing bill.** Pricing is normally anchored to a committed level of *clean* traffic — the legitimate volume you push through them month after month. Exceed the commit and you are billed for the overage; the attack volume itself is usually not what you pay for, but your own growth is. - **Latency, every day, forever.** Every ordinary request takes whatever path their edge implies. This may be modest, or even negative if their edge is closer to your users than your origin is — but it is a permanent tax you are paying on the 364 days a year when nothing is attacking you, and it must be defended as such. - **A dependency in the critical path.** A provider outage, a misconfiguration on their side, or a filtering rule that misjudges your traffic is now a production incident for you. You have swapped a rare, severe risk (a flood) for a constant, small one (someone else's network in your path). - **Their vantage, not yours.** The control that decides which clients are real is operated by a third party. During an incident you raise a ticket; you do not run a query. ### On-demand Traffic follows its normal path. When an attack is detected, diversion is triggered — the provider begins attracting your traffic, scrubs it, and returns it to you. What it costs: - **A gap.** The exposure window is the sum of several delays, and only one of them is technical: 1. **Detection** — someone or something must notice. If it is a human noticing an alert, this alone can be minutes. 2. **Decision and authorisation** — diverting changes your traffic path; many organisations require a person to approve it. 3. **Activation** — the provider begins attracting traffic and stands up the return path. 4. **Convergence** — the change has to take effect everywhere, which is not instantaneous. Realistically this totals minutes, not seconds. That is the whole game: **an adversary who understands your posture sends bursts shorter than your activation time.** A nine-minute burst against an eleven-minute activation means the service was down, the mitigation arrived after the event, and the provider's dashboard will honestly show that it scrubbed almost nothing. - **A per-event charge.** On-demand contracts commonly pair a lower retainer with a fee each time mitigation is invoked, sometimes with a minimum billing duration far longer than the attack. Frequent short attacks can make on-demand more expensive than always-on while protecting you less. - **A cold path.** The return path and the diversion mechanism are exercised rarely, so they are exactly the kind of thing that turns out to be broken when you finally need it. If you choose on-demand, you must test the diversion on a schedule, in production, during a change window — and that test is itself a small planned outage risk. ## Comparing them honestly | | Always-on | On-demand | |---|---|---| | Exposure at attack start | none | minutes | | Everyday latency | permanent tax | none | | Cost at rest | higher, predictable | lower retainer, per-event fee | | Dependency | constant | only during events | | Path exercised | continuously | rarely, must be tested | | Beats a short burst | yes | frequently no | ## The hybrid, and why it is usually the real answer Most mature estates do not choose one. They put the small number of prefixes or services that genuinely cannot tolerate a multi-minute gap behind always-on protection, and leave everything else on-demand. This is a deliberate trade of money and latency for exposure, made service by service rather than once for the whole estate. The decision needs an explicit statement of what a gap costs. If a nine-minute outage during business hours is survivable and rare, on-demand is defensible and cheaper. If the service is a payment path or a real-time system where a nine-minute gap is a reportable event, the standing bill and the latency tax are the price of not having a gap — and that is the sentence to say out loud in the interview, because it is the sentence that gets the budget approved or refused. ## The failure to name The most common wrong answer is that on-demand is strictly better because it costs less and adds no latency. It costs less *at rest*. It buys you an exposure window that a competent adversary will measure and then send bursts underneath — and the invoice still arrives afterwards for a mitigation that ran after the outage ended.