A UK retail platform takes a two minute burst of junk traffic at 19:40 on a Friday, another at 19:52, another at 20:06, each one heavy enough to fill the transit link and drop checkout sessions, and by the time the on-call engineer has read the alert, opened a ticket and asked the provider to divert the prefix, the traffic has stopped again. Nothing to mitigate. The provider’s report the following week shows three mitigation events, total duration eleven minutes, all of them starting after the bursts ended. That is the always-on vs on-demand DDoS question in its real form, and it is not the abstract “always-on is faster, on-demand is cheaper”trade-off that most vendor comparisons stop at.
The useful question is not which model is better. It is which model belongs on each surface you are protecting, and who is contractually on the hook to pull the trigger at 03:00.
What Each Model Actually Does To Your Traffic
Always-on: permanently behind the mitigation layer
Always-on means your traffic never touches the origin directly. In practice that is one of two architectures. Either a reverse proxy sits in front of your web estate, with your public DNS records pointing at the provider’s anycast addresses and TLS terminated at their edge, or the provider permanently announces your IP prefix over Border Gateway Protocol (BGP) and returns clean traffic to you over a GRE tunnel or a private cross-connect. Detection and mitigation happen in the same path the packets already take, so the decision to act is a policy change, not a routing change.
On-demand: direct to origin until something triggers diversion
On-demand leaves traffic flowing straight to your network on normal days. When an attack is identified, the path changes: you announce your prefix to the scrubbing provider (or ask them to announce it), or you update DNS records to point at their proxy, or you phone their security operations centre and ask them to do it. Clean traffic then comes back to you. The mitigation itself is usually identical to the always-on service. What differs is everything that has to happen before the first packet reaches a scrubber.
On-demand is not one product, and this is where buyers get caught
Three quite different things are sold under the same label:
- Customer-triggered diversion. You notice, you decide, you call or click. Response time is your response time, plus propagation.
- Provider-triggered diversion. Their SOC watches your links and acts under an agreed authority. Faster, but only if the authority is written down and does not require your sign-off per event.
- Flow-monitored auto-diversion. NetFlow, sFlow or IPFIX exported from your border routers feeds a detector that announces the prefix automatically once thresholds trip. Fastest of the three, and the only one that has a chance against short attacks.
Flow-based detection has a floor built into it. Flow records are sampled and exported on a timer, commonly in the tens of seconds, and the detector then needs several intervals to distinguish an attack from a traffic spike. That floor is a property of the telemetry, not of the vendor’s marketing.
Where hybrid genuinely fits
“Hybrid”almost always means an on-premises mitigation appliance handling smaller floods locally, with a signalling channel to a cloud scrubbing centre when the attack exceeds your transit capacity. It suits organisations with their own address space, their own routers, staff who understand BGP, and a real reason to keep inspection on site (regulated traffic, latency-sensitive protocols, private interconnects). If you do not have engineers who can tune an appliance, a hybrid deployment becomes an expensive box that alerts.
Time To Mitigate: The Timeline Nobody Puts In The Sales Deck
Four gaps, not one
An on-demand response has four separate delays, and the marketing figure usually covers only the last one. Attack onset to detection. Detection to human decision. Decision to route change. Route change to stable sessions, because TCP connections and TLS handshakes have to re-establish through a new path.
The human decision step is the one vendors rarely quantify, and it is often the whole outage. Ask exactly where the SLA clock starts: at attack onset, at detection, or at the moment diversion is authorised. A promise of “mitigation within 15 minutes”measured from authorisation tells you nothing about how long authorisation takes at 02:30 on a bank holiday.
BGP minutes versus DNS TTL hostage-taking
BGP diversion is quick by internet standards and slow by attack standards. A new announcement propagates across the global routing table in minutes, subject to route dampening, upstream filtering and prefix-length policies (many networks will not accept anything longer than a /24, which quietly rules out diverting a single address).
DNS-based diversion is worse, and less predictable. Redirecting a hostname to a scrubbing proxy is limited by the record’s time to live, and by resolvers, application runtimes and browsers that cache well beyond it. Java’s default DNS caching behaviour has caught out more than one API integration. If DNS is your diversion mechanism, lower the TTLs on the relevant records now, while nothing is on fire, and accept that a stubborn tail of clients will keep hitting the old address for hours.
Where always-on wins outright
Short, repeated bursts. Imperva’s researchers labelled the pattern “pulse wave”DDoS in 2017 research, and it is designed precisely to defeat the on-demand cycle: bursts of a few minutes, gaps between them, no single event lasting long enough for detection, authorisation and propagation to complete. Against that pattern an on-demand layer never carries the attack traffic at all. It just documents it afterwards.
The Always-On vs On-Demand Decision Changes By Surface
Network and transport
Volumetric floods against a whole prefix, UDP reflection and amplification, SYN floods, garbage to random ports. This is the one place where on-demand BGP scrubbing is genuinely defensible: you own the address space, you have flow monitoring on the border, thresholds are tuned, and the traffic profile is stable enough that a real attack looks nothing like a busy Tuesday. If your addresses come from your hosting provider and you cannot announce them yourself, on-demand BGP is not available to you regardless of what the quote says.
Application layer
HTTP request floods, cache-busting query strings, credential-stuffing patterns from residential proxy pools. These attacks rarely move enough bits to trip a volumetric threshold, and they are frequently indistinguishable from a marketing email landing, which is exactly why on-demand detection handles them badly. Layer 7 mitigation also depends on state the provider has to build over time: request baselines, cookie and JavaScript challenge behaviour, bot classification, rate-limit tuning per endpoint. None of that exists if the proxy only sees your traffic during incidents. For web and API estates, always-on reverse proxy is normally the only honest answer.
Authoritative DNS
Authoritative DNS breaks the framing entirely. There is nothing to divert once resolution is already failing, because the diversion instruction is itself a DNS change that nobody can look up. The surface is either permanently hardened or it is not: anycast across multiple networks, several nameservers in different ASNs, response rate limiting, and a provider whose capacity you have actually asked about.
It is also the surface UK buyers most often leave on whatever their hosting or domain bundle included, while paying separately for network and application protection. An always-on proxy in front of the website does not help when the zone that resolves the hostname goes dark. Check who is authoritative for your domains today, then check whether that arrangement was a decision or an accident.
A mixed estate, sensibly split
A realistic answer for a mid-sized UK platform: always-on reverse proxy for the public web and API hostnames, on-demand BGP scrubbing for the wider /24 if you own it and have flow monitoring, permanently hardened anycast DNS with a specialist, and origin ranges locked so nothing reaches them except the proxy. Single-model decisions across a mixed estate are where buyers manage to overpay and stay exposed at the same time. Our comparison of how to judge vendor claims against real attacks goes further into the questions each surface demands.
Why Always-On Still Fails: Origin IP Leakage
Proxy bypass can cause more downtime than capacity exhaustion. The mechanism is dull: the attacker finds your real origin address and sends traffic straight to it, and the always-on layer you are paying for never sees a packet. Capacity is irrelevant when the traffic is not in the path.
Where origins leak
- Outbound mail headers. Transactional email sent from the application server stamps its address in Received headers. Trigger a password reset, read the headers.
- Historical DNS records. Passive DNS databases keep what your A records pointed at before onboarding, sometimes for years.
- Certificate transparency logs. Every publicly trusted certificate is logged under the framework described in RFC 6962, so staging, admin and internal hostnames you never advertised are searchable.
- Forgotten subdomains. vpn., mail., legacy., dev., cpanel., monitoring. Pointing straight at the origin because proxying them broke something once.
- Direct-connect endpoints. Partner API integrations and payment callbacks whitelisted by IP address, bypassing the proxy by design.
The lockdown list
Onboarding that stops at “change your DNS records”leaves the subscription decorative. What it should include: origin firewall or security group rules that accept HTTP and HTTPS only from the provider’s published ranges; re-addressing the origin after cutover, because a leaked address is leaked permanently; authenticated origin pulls (client certificates or a shared secret header) so that anyone who does find the address still cannot get a response; outbound mail moved to a separate relay; and an inventory of every hostname in the zone with a decision recorded for each one. An always-on subscription with a leaked origin performs worse than a well-drilled on-demand setup, because it also gives you false confidence.
Cost, Latency And What You Are Really Buying
How UK pricing tends to be structured
Quotes usually price on a clean traffic commitment (megabits or gigabits of legitimate throughput, billed monthly, with overage), plus a count of protected prefixes or hostnames, plus service elements: onboarding and rule tuning, baselining, named escalation contacts. Always-on is typically a flat subscription. On-demand is typically a lower retainer with per-event mitigation charges. Figures move, so treat any number in a deck as current only on the day it was issued.
The costs on-demand contracts bury
Per-event fees are the visible one. The expensive ones are the minimum diversion windows, frequently measured in hours or even days rather than minutes, which means a two minute burst can bill as a day of scrubbing and can also hold your prefix on the scrubbing path (with its added latency) long after the attack ends. Then out-of-hours escalation charges. Then the cost of your own people. Our guide to managed DDoS protection pricing in the UK sets out what those service lines usually contain.
Latency and point-of-presence coverage
Always-on proxying adds a hop and terminates TLS away from your origin. For a UK audience served from a UK or Northern European point of presence, the added round trip is small and often offset by edge caching and connection reuse. For a provider whose nearest PoP to your users is in Amsterdam or Frankfurt while your customers are in Leeds, it is not. Ask for the PoP list and peering arrangements relevant to your traffic, not the headline aggregate capacity figure. Aggregate terabits tell you what the network can absorb globally; they say nothing about where your packets go on a Tuesday.
Build the case on downtime cost, not fear
Work it from your own numbers. The figures that follow are a worked illustration with round numbers rather than survey data, so substitute your own: an ecommerce operation turning over £30,000 in a trading hour would put £120,000 of gross revenue at risk in a four hour outage, of which perhaps a third is contribution margin, so call it £40,000 of real loss, plus service credits owed to your own B2B customers under their contracts, plus six engineers and a comms lead working through the night, plus whatever the abandoned baskets never come back as. Set that against the annual premium of always-on over on-demand in the two quotes on your desk. If the premium is smaller than a single plausible incident, the finance conversation is short.
How To Choose, And What To Ask Before You Sign
A short decision path
- Revenue or safety exposure per hour of downtime. High, and always-on for the web estate stops being a debate.
- Attack history. Repeated short bursts, or extortion notes? Always-on. One volumetric event in five years against a prefix you control? On-demand BGP is arguable.
- Address ownership. No portable prefix, no BGP option.
- Staffing. No 24/7 rota with authority to trigger diversion, no viable customer-triggered on-demand.
Establish who actually owns the scrubbing capacity
Many UK offerings are resold, sometimes twice, and the chain often ends at a small number of underlying scrubbing networks. Consolidation has been running for years; Akamai’s acquisition of Prolexic, which we covered at the time, is one of the reasons the list of genuinely independent scrubbing platforms is shorter than the list of logos. Ask three plain questions: whose network scrubs the traffic, what your reseller can change without raising a ticket upstream, and whether the same underlying platform sits behind the “second opinion”quote you obtained for comparison.
Evidence, not the deck
Ask for a redacted post-attack report from a real customer incident, with vector breakdown and timestamps for onset, detection and mitigation. Ask for records of diversion drills, including the last date one was run. Ask for the escalation matrix with named roles, and ask who acts at 03:00 on a Sunday without waiting for your authorisation. The NCSC’s guidance on denial of service attacks is a reasonable neutral yardstick for the preparation questions a supplier should be able to answer without hesitation. If you are still shortlisting, our notes on choosing between mitigation providers and their trade-offs cover the rest.
One thing to hold firm on. On-demand only works if a named human is genuinely on the hook to trigger it. If the “managed”scope in the contract stops at a support inbox and business-hours monitoring, you have bought an on-demand product with an office-hours response, which is the worst possible combination for pulse attacks and ransom campaigns that deliberately start out of hours. Decide always-on vs on-demand DDoS protection surface by surface, insist on origin lockdown as part of onboarding, and read the SLA for where the clock starts before anyone signs.
Frequently Asked Questions
Is always-on DDoS protection always faster than on-demand?
For time to mitigate, yes, because the traffic is already in the mitigation path and there is no detection, authorisation or routing delay to absorb. The advantage disappears if your origin address has leaked and attackers can bypass the proxy entirely. A well-instrumented on-demand setup with automatic flow-triggered diversion beats a badly onboarded always-on subscription.
How long does on-demand DDoS mitigation take to activate?
Add four intervals: detection (sampled flow telemetry usually needs tens of seconds to a few minutes), human authorisation, route propagation, and session re-establishment. BGP diversion propagates in minutes; DNS-based diversion is limited by record TTL and by caching resolvers that ignore it. Ask each provider where their SLA clock starts, because that single definition can differ by the length of your whole outage.
Does always-on DDoS protection add latency to my site?
It adds a network hop and moves TLS termination to the provider’s edge, so there is measurable overhead. With a point of presence close to your users, edge caching and connection reuse frequently offset it, and some sites get faster. Ask for the PoP locations and peering relevant to your actual audience rather than relying on global capacity figures.
Can I use always-on for web traffic and on-demand for network protection?
That combination is the sensible default for a mixed estate: always-on reverse proxy for public web and API hostnames, on-demand BGP scrubbing for the wider prefix if you own the address space and export flow data. It only holds together if the origin accepts traffic solely from the proxy ranges and someone is contractually responsible for triggering the BGP diversion out of hours.
Which model is better for protecting authoritative DNS?
Neither, as the question is normally framed. Once resolution is failing there is nothing left to divert, so DNS has to be permanently hardened: anycast, nameservers spread across separate networks and ASNs, response rate limiting, and a provider you have actually questioned about capacity. Check who is authoritative for your domains before you renew anything else.