Tag Archives: managed ddos protection uk

Always-On vs On-Demand DDOS Protection: Which Fits Your Traffic (and Budget)

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.

DDOS Time to Mitigate: What SLA Seconds Really Mean (And How to Verify Them)

A head of IT signs a mitigation contract with a 60 second time-to-mitigate figure on the front page, files it, and thinks the problem is handled. Eight months later the checkout page stalls for a quarter of an hour on a Friday evening, the provider’s portal eventually logs the event as mitigated, and the post-incident review finds no breach of contract anywhere. Both things are true. Understanding why is the whole point of reading a DDoS time to mitigate clause properly, because the figure vendors publish almost never covers the part of the attack that actually hurt you.

Time to mitigate, in plain terms, is the interval between a distributed denial-of-service (DDoS) attack affecting your service and countermeasures bringing traffic back to something usable. That definition sounds tight. In practice, every provider draws the start and end lines in a different place, and the wording in the service level agreement (SLA) is where the difference lives.

What time to mitigate actually measures, and where the clock starts

An attack does not go from launch to blocked in one step. The chain runs roughly: the attack begins; telemetry (flow records, proxy logs, appliance counters) crosses a threshold; a detection alert fires; someone or something decides to act; traffic is diverted or filtered; routes converge and the return path carries clean traffic; and finally countermeasures are tuned to the specific vector, whether that is a UDP reflection flood or an HTTP GET flood against a search endpoint.

Most published figures cover the last stretch only. They measure the automated countermeasure stage, applied to traffic that is already inside the scrubbing path. Detection thresholds, human authorisation and Border Gateway Protocol (BGP) convergence on an on-demand service sit outside the measured window. A 60 second SLA and a fifteen minute outage coexist comfortably.

Two acronyms get quoted interchangeably and should not be. Mean time to detect (MTTD) is how long the provider’s systems take to notice. Mean time to mitigate (MTTM) is how long countermeasures take once triggered. Vendors quote whichever flatters the product: an always-on proxy vendor happily quotes near-zero mitigation time because traffic is already in path, while an on-demand scrubbing vendor prefers to talk about detection speed and stays quiet about diversion.

Three questions belong in writing before signature, not in a kick-off call afterwards:

Does the clock start at attack onset, at detection by the provider’s monitoring, or at the moment your named contact raises a ticket? The third option is common and is by far the weakest for you.
What counts as the finish line: first countermeasure applied, or measured service restoration against a defined availability target?
Who supplies the timestamps used to judge compliance, and are those timestamps from the provider’s own systems only?

Define your own finish line separately for internal reporting. Mitigation started is a vendor milestone. Checkout completing inside two seconds again is your milestone. Track both, because the gap between them is the number your board will ask about.

Always-on versus on-demand: the real trade-off

Always-on reverse proxy

Traffic already traverses the scrubbing estate, so for in-scope traffic mitigation is effectively immediate. Nothing has to be switched on. The costs are real though: added latency on every request, Transport Layer Security (TLS) termination at the provider (which means handing over private keys or using a provider-managed certificate), and a hard dependency on your origin addressing staying hidden.

On-demand BGP scrubbing

Here the diversion itself is the delay. An illustrative but realistic sequence: detection threshold breached at T+2 minutes, human authorisation obtained at T+5, the more-specific prefix announced at T+6, then global BGP convergence taking a few more minutes as peers accept the change. Clean traffic starts flowing well after the “five minute mitigation”figure on the datasheet, and none of it is a breach.

The second cost nobody times in a demo is the return path. Generic Routing Encapsulation (GRE) tunnels or cross-connects have to be built, tested and kept warm. A return path that has not been exercised in twelve months is where the real delay appears, usually accompanied by a maximum transmission unit (MTU) problem that only shows up under load.

Hosting-level filtering

Included platform protection is fast against volumetric floods, because the hosting provider is defending shared infrastructure and has every incentive to act. The mechanism matters. Many platforms “mitigate”by null-routing the targeted IP address at the edge, which protects the platform and every other tenant on it. From your seat it is indistinguishable from being taken offline. The contract language to hunt for is whether blackholing counts as mitigation for SLA purposes. If it does, the response time figure tells you almost nothing about your own availability.

Hybrid patterns

A common UK arrangement puts always-on proxy protection in front of the web estate and keeps on-demand BGP diversion in reserve for the wider prefix. Sound design. The handoff is where minutes leak away, because someone has to recognise that the attack has moved off the proxied hostnames and onto the network itself, then authorise a routing change. Rehearse that decision. Write down who makes it.

Three surfaces, three different clocks

Network and transport floods

Volumetric and protocol attacks (SYN floods, DNS and NTP reflection, carpet-bombing across a prefix) are high-volume and high-signal. Detection is straightforward, signatures are well understood, and automated countermeasures do most of the work. This is the surface the published time-to-mitigate figure was written for, and the one place it usually holds up.

Application layer

Low-rate HTTP floods are the awkward case. Consider an ecommerce checkout during peak trading, hit by a few thousand well-formed requests per second spread across residential proxies, each one hitting a database-heavy search or basket endpoint. Bandwidth looks normal. Volumetric thresholds never trigger. Mitigation depends on someone identifying a request signature (a header order, a JA3 fingerprint, a URL pattern, a behavioural anomaly against baseline) and writing a rule against it. That is a human timescale, and it is why the headline SLA rarely applies as advertised at layer 7. Ask specifically what the response commitment is for application-layer events, and whether it differs from the network figure. It nearly always does.

Authoritative DNS

Authoritative Domain Name System (DNS) service is the surface most commonly left outside the managed contract in UK buys. Buyers assume proxy protection covers name resolution. It does not, unless the contract says so. If your authoritative DNS sits with a separate registrar, an on-premises BIND pair, or a hosting control panel with no dedicated DNS DDoS attack protection, there is no time to mitigate at all. There is just an outage, and it takes every service down at once: web, mail, VPN, SaaS single sign-on, monitoring.

Options exist for organisations that cannot simply move zones to a large anycast platform. Akamai’s Shield NS53, for example, is designed to sit in front of on-premises and hybrid authoritative name servers rather than only the web tier. Whatever the choice, map every surface to a named owner, a named product and a named response time before anything goes wrong. Three columns on one page. If a row is blank, that is your next purchase order, and the same discipline applies whether you are comparing platforms or reading a vendor claim against how real attacks behave.

Why fast mitigation still fails: origin leakage and scope gaps

Origin IP leakage defeats a fast SLA more often than attack size does. Historical DNS records cached in passive DNS databases, mail servers sitting on the same range as the web origin, certificate transparency logs listing every hostname you have ever requested a certificate for, staging and legacy subdomains left unproxied, direct-connect API endpoints for partner integrations: any one of them hands an attacker a path straight to the origin.

When traffic reaches the origin directly, the provider’s clock never starts. Their proxy saw nothing. A sub-minute mitigation commitment on the proxy is worth precisely nothing in that scenario, and the provider is not in breach.

Other assets routinely fall outside scope entirely: VPN concentrators, SIP trunks and voice gateways, SMTP inbound, third-party APIs your application calls synchronously, and CDN origin pull addresses. Practical hardening is unglamorous and effective: firewall the origin so it accepts traffic only from the provider’s published address ranges, rotate origin addressing after onboarding so the pre-contract history is stale, and re-test scope after every migration, DNS change or new subdomain. The scope of protection drifts quietly. Attacks find the drift.

How to verify a time-to-mitigate claim before you sign

Datasheets are not evidence. Post-attack reports are. Ask for two or three real incident reports, redacted as needed, and read the timestamps rather than the headline scrubbing capacity in terabits per second. What you want to see: attack start, first alert, authorisation, first countermeasure, vector breakdown, and the point at which traffic profile returned to baseline. A provider who cannot produce that from real events, in a format you can read, is telling you something.

Then trace the resale chain. Whose network, whose scrubbing centres, whose engineers are on the clock at 03:00? A reseller cannot be faster than its upstream. Plenty of competent UK managed service providers sit on top of Akamai Prolexic, Cloudflare, Imperva or a carrier scrubbing platform, and that is a perfectly reasonable model, but it changes what the SLA means and where escalation actually goes. Asking is procurement hygiene, not an accusation. This site has covered the industry consolidation behind that pattern since Akamai’s acquisition of Prolexic.

Test the escalation path before you need it. A named out-of-hours contact, a phone number that a human answers, and a call drill during the trial period. Decide in advance who on your side is authorised to trigger diversion at 03:00, and what happens when that person is on a flight. Pre-authorisation for automatic diversion, within agreed limits, removes the single largest human delay in the chain.

Read the credit mechanics last and without optimism. Look at exclusions, the measurement window, whose data counts as evidence, and the claim deadline. A credit worth one month of fees rarely covers an hour of lost trading, and it is not a substitute for the technical controls. The credit is a footnote in a board pack. The outage is the meeting.

Turning minutes into money

Build the business case from cost per minute of downtime, not from vendor pricing. Transaction volume at peak multiplied by average order value, staff idle cost across the affected teams, contractual penalties you owe your own customers, and recovery effort including incident overtime and customer communications. Once that number exists, the price gap between an on-demand tier and an always-on tier usually resolves itself in one direction, and the conversation with finance gets shorter. Our guidance on managed DDoS protection in the UK, including what the tiers actually cost, sets out where those price bands typically sit, and the faster tier mostly buys the removal of the human authorisation step and the diversion delay, not better filtering.

Stakes vary by sector, and so should the design. An ecommerce checkout flood on Black Friday is a revenue event measured in minutes. Healthcare and public sector disruption is a service and reputational event with regulatory attention attached. A DNS outage is the worst case, because everything stops simultaneously and your status page is often unreachable too. Aviation offers a useful case study in interlinked dependencies, which the analysis of a DDoS attack against airline systems works through in more detail.

One attacker behaviour makes response speed strategic rather than merely operational. Ransom DDoS follows a pattern: a short demonstration burst of a few minutes against a public-facing site, then an email demand and a threat of something longer. A slow, visible first response tells the sender the target is worth returning to. Both the NCSC’s denial of service guidance for UK organisations and CISA’s joint guidance for defenders advise against paying and in favour of prepared, rehearsed response. Preparation is what makes the first response quiet.

The honest position on DDoS time to mitigate is this: treat the datasheet number as the vendor’s best case for the easiest surface, then spend your procurement effort on the parts it excludes. Where the clock starts, what happens to layer 7, who protects your authoritative DNS, and whether your origin is genuinely unreachable. Those four answers determine your real recovery time. The number on the front page does not.

Frequently Asked Questions

What is a good DDoS time to mitigate?

For network and transport-layer floods on an always-on service, effectively immediate is achievable because traffic is already in the filtering path, and commitments in the tens of seconds are common. For on-demand BGP diversion, anything under about ten minutes end to end including convergence is respectable. Layer 7 events are slower and should carry their own separate commitment. Judge the figure by what it includes, not by how small it is.

Does time to mitigate start when the attack begins or when it is detected?

That depends entirely on contract wording, and it is the single most valuable clause to negotiate. Many SLAs start the clock at detection by the provider’s systems, some at the point you open a ticket, and very few at attack onset. Get the definition in writing along with confirmation of whose timestamps are used to measure compliance.

Why is application layer DDoS mitigation slower than network layer mitigation?

Low-rate HTTP floods look like legitimate users. Bandwidth stays normal, so volumetric thresholds never fire, and separating attack requests from real traffic usually requires identifying a signature or behavioural pattern and writing a rule against it. Automated bot management helps, but the difficult cases still involve an engineer, which is a human timescale rather than a machine one.

How much slower is on-demand BGP scrubbing than always-on protection?

The gap is the sum of detection threshold, authorisation and route convergence. Working through a typical sequence, detection at a couple of minutes, human sign-off a few minutes later, then announcement and global BGP convergence, you are realistically looking at several minutes to low double digits before clean traffic flows. Always-on removes all of it for in-scope traffic. An untested GRE return path can add considerably more.

What evidence should I ask a provider for to check their mitigation times?

Redacted post-attack reports from real incidents with full timestamps, a written definition of clock start and finish, confirmation of whose scrubbing centres and network operations centre sit behind the badge, and a live out-of-hours call drill during the trial. Comparing that evidence across shortlisted suppliers, as set out in this guide to choosing between mitigation providers and their trade-offs, tells you more than any capacity figure.

Best DDoS Mitigation Providers: How to Choose (With Trade-Offs)

Shortlists of the best DDoS mitigation providers tend to rank vendors by brand recognition and advertised scrubbing capacity. Incident archives rank them differently. What decides whether an organisation stays online is narrower and less glamorous: whether authoritative DNS was covered, whether the old origin IP was still reachable after the proxy migration, whether anyone answered the phone within the first ten minutes, and whether the layer 7 rules blocked the botnet without blocking the checkout.

This guide works backwards from the attack patterns that actually cause outages, then maps each one to what a provider has to demonstrate before it belongs on a shortlist. It also covers the vendor landscape as it really is: a set of acquisitions rather than a fresh market, which matters more during procurement than most buyers expect.

What actually separates DDoS mitigation providers

Advertised capacity versus usable capacity near your users

Headline figures for network capacity describe the sum of a vendor’s edge, not the capacity of the point of presence that will absorb an attack aimed at your users in London, Manchester or Dublin. A platform with enormous global capacity but thin UK and Western European peering can still deliver added latency on clean traffic and slower convergence during a diversion. Ask for the PoP and peering list for the geographies your traffic actually comes from, and for the second and third nearest sites, because that is where traffic lands when the nearest one is saturated or under maintenance.

Always-on proxy, BGP diversion or DNS redirection

Three deployment models dominate, and each has a different realistic time to mitigate.

Always-on reverse proxy. HTTP and HTTPS traffic passes through the provider permanently. Mitigation starts in seconds because there is nothing to switch. The trade-off is that every request depends on the proxy, and TLS termination sits with a third party.
BGP on-demand diversion. The provider announces your prefixes and pulls traffic into scrubbing centres, then returns clean traffic by GRE tunnel or private interconnect. Suitable for whole /24s and non-HTTP services. Realistic activation covers detection, decision, announcement and BGP convergence, so the honest number is minutes, not seconds, unless the announcement is permanent.
DNS redirection. Records are repointed to the provider. Speed is governed by your TTLs and by resolver behaviour, and some resolvers ignore short TTLs. Anyone relying on this model should already be running low TTLs as standing configuration.

Volumetric floods versus application-layer floods

Layer 3 and 4 volumetric attacks are the ones that generate the headline numbers. Layer 7 floods are the ones that quietly take e-commerce and portal estates offline. A distributed bot network sending well-formed requests to search, login or basket endpoints does not need much bandwidth to hurt. An origin sized for roughly 500 requests per second can be exhausted by a few thousand requests per second against expensive database-backed endpoints, at a traffic volume that never crosses a volumetric detection threshold. That arithmetic is why per-endpoint rate limiting and bot management matter more than terabit claims for most web estates.

Who runs the mitigation on the night

Three operating models exist: your team drives the console, the vendor’s security operations centre drives it under a managed service, or a partner MSP drives it on your behalf. Self-service is cheaper and worse at 03:00 on a bank holiday. Managed services cost more and need clear authority to act without waiting for a change approval. Decide which model you are buying before you compare prices, because the same platform sold three ways produces three very different incidents.

Map your attack surface before you shortlist

Everything with a public address, not just the website

The inventory that matters includes the public web estate, APIs and mobile back ends, authoritative DNS, VPN concentrators, mail gateways, and anything else with a routable address. Origin exposure is where most proxy-based deployments quietly fail. Teams move DNS behind an anycast provider and leave the previous origin IP reachable, still visible in historic DNS records, mail headers, certificate transparency logs or a forgotten staging hostname. Attackers look there first.

Treat origin lock as a hard requirement rather than optional hardening. Ask exactly how the provider enforces it: IP allow-lists at the edge firewall permitting only the provider’s ranges, authenticated pull between edge and origin, or private interconnect. Then verify it from outside your network, not from the change ticket.

Sector patterns

Attack motivation shapes the pattern. Financial services see credential-stuffing and layer 7 floods aimed at login and payment paths, sometimes as cover for fraud, as in incidents like the DDoS disruption at National Australia Bank. Airlines and travel platforms carry expensive search endpoints that make cheap layer 7 attacks effective, which is why carriers have invested heavily in automated defences at the edge. Public sector estates fail collectively: the March 2024 disruption of French government services, which officials described as an attack of unusual intensity, showed how dozens of domains sharing DNS and hosting go dark together, and how hacktivist campaigns arrive in waves around political events. Healthcare and law firms tend to be hit for extortion or reputational leverage rather than volume records.

Hosting and data centre protection, and the blackholing clause

For many organisations the real first line is the hosting provider’s upstream filtering, and plenty of providers do invest properly in it, as with the anti-DDoS platforms rolled out by regional data centre operators. The problem sits in the acceptable use policy. Under attack, many providers will null-route the targeted IP to protect other tenants. That counts as mitigation for the provider and as a total outage for the customer. Read the clause, get the threshold in writing, and know whether an escalation path exists to filtering rather than blackholing.

Price the downtime first

Budget follows the cost of an hour offline, and so does the acceptable failure mode. An estate where an hour costs six figures should buy always-on protection with a managed SOC and separate DNS coverage. A brochure site can accept DNS redirection and a slower clock. Working out that number before vendor calls stops the conversation being driven by whichever feature the account manager is targeted on.

The main DDoS mitigation providers and where each one fits

One point worth carrying into every vendor call: this is a market built from acquisitions. Prolexic, founded in 2003, has sat inside Akamai since 2014. Earlier appliance and scrubbing names from the previous generation, including netZentry, Webscreen and IntruGuard (whose DDoS technology went to Fortinet), were absorbed into larger vendor and carrier portfolios years ago. A “proven since 2003″claim may describe technology that has changed hands and architecture more than once. Ask which platform your traffic will traverse today, in which data centres, and under whose engineering roadmap.

Global anycast CDN and reverse proxy platforms

Cloudflare, Akamai and Fastly all operate large anycast networks that terminate HTTP and HTTPS at the edge, with WAF, rate limiting and caching alongside DDoS filtering. For web and API-heavy estates this is the strongest default: mitigation is always on, layer 7 controls sit where the traffic arrives, and caching absorbs a large share of junk requests. The limits are equally clear. Proxy platforms protect what resolves through them, so non-HTTP services, mail and VPN need separate cover, and origin lock has to be enforced rather than assumed.

Routed network-level protection for whole prefixes

Akamai Prolexic and equivalent scrubbing services from carriers and specialists protect entire /24 announcements, including non-HTTP protocols, on-prem data centres and colocation footprints. This is the right choice where the estate is not simply a website: SIP trunks, game servers, financial market connectivity, industrial protocols. Two questions decide quality here. First, is the announcement always on or on demand, and what is the measured convergence time. Second, how is clean traffic returned, and what happens to that return path when it is itself attacked.

DNS protection as its own line item

DNS remains the most under-bought layer in the stack. An attack on authoritative nameservers takes out every service behind them at once, however well the web tier is defended. Organisations that hand DNS to a managed anycast provider inherit that provider’s capacity. Those keeping their own authoritative nameservers, often for internal integration or compliance reasons, need dedicated cover in front of them. Akamai Shield NS53 exists for exactly that case, sitting in front of on-prem and hybrid authoritative DNS, and competing providers offer similar hybrid arrangements. If DNS does not appear as a separate item on the quote, it is probably not protected.

Bot management, bundled or licensed separately

Automated layer 7 abuse sits at the boundary between DDoS, scraping and credential stuffing, and vendors increasingly sell it separately. Fastly Bot Management and its peers apply behavioural scoring, fingerprinting and challenge logic that generic WAF rules miss. For retail, ticketing and any estate with a login wall, this is usually the difference between staying up and staying up profitably. Establish early whether it is included in the platform price or licensed on request volume, because the second model changes the total cost under attack. Botnet supply itself has been a policy target for years, from industry takedown initiatives to named prosecutions, but attackers rebuild capacity faster than it is removed.

ISP, transit, protected hosting and managed DDoS protection in the UK

Buying through a transit provider, a DDoS-protected host or a UK managed security partner suits organisations without a 24/7 network team. Filtering happens upstream before congestion reaches the access circuit, and the partner holds the runbook. The channel model behind this is long established: DDoS vendors have offered managed security service partner programmes for well over a decade, including the early appliance-based MSSP schemes that shaped today’s managed offerings. Weaknesses to test: whether the partner can act without your sign-off, whether their SOC covers UK out-of-hours properly, and whether they simply resell a platform they cannot tune. A broader view of the defensive options, including on-premises and hybrid designs, is set out in this rundown of DDoS attacks and the available solutions.

Comparing providers on the things that break during a real attack

Time-to-mitigate SLAs. Most are measured from vendor detection, not from the moment your users stop being able to load the site. Get the measurement start point in writing, along with the out-of-hours escalation clock and who is authorised to declare an incident. Then check the credit: it is often a fraction of one month’s fee, which is not a remedy, it is an apology. Ask for the distribution of mitigation times across recent incidents rather than a headline average, because the tail is what hurts.

False positives. The first journeys to break under aggressive rules are checkout, login and password reset, precisely the ones that generate revenue and support tickets. Ask how the provider tunes for logged-in traffic, how quickly a rule can be relaxed mid-incident, and who has authority to do it at 2am.

Challenges and accessibility. JavaScript challenges and CAPTCHA reduce automated load but also block screen readers, older clients, legitimate API consumers and price-comparison partners. Public sector buyers with accessibility obligations should test challenge pages against assistive technology before go-live, not after a complaint.

The first 30 minutes. Named contacts, a phone number that is answered, a shared channel that does not depend on your own mail domain, and an agreed authority to act. Vendors that only offer a ticket queue at silver tier are fine for a brochure site and unacceptable for a payment platform.

Contract shape. Watch burst pricing, clean-traffic overage, attack-time surcharges, per-request bot management fees and 12 to 36 month lock-ins. Insist on knowing what an unusually large attack costs, because a bill arriving after an incident is a poor way to discover the pricing model.

Procurement questions and a proof-of-value test plan

Twelve questions that separate capability from marketing:

Which PoPs will serve our UK and EU users, and who do you peer with there?
Is protection always on, BGP on demand or DNS-based, and what is the measured activation time for each?
What exactly is in scope for DNS: managed authoritative, hybrid, or nothing?
How is origin lock enforced and verified after go-live?
Is bot management included or licensed separately, and on what metric?
From what event does the time-to-mitigate clock start, and what is the credit?
Show the distribution of mitigation times over the last 12 months, not the average.
Who runs mitigation out of hours, from which location, and under what delegated authority?
What is the policy on null-routing our addresses, and at what threshold?
Which platform will our traffic traverse, and what is its acquisition history?
What are burst, overage and attack-time charges in cash terms?
Can you provide two references in our sector at a similar traffic profile?

Ask for anonymised incident reports rather than case-study prose. A report showing detection time, mitigation time, rule changes and residual impact tells you more than any capacity figure. Then run a controlled proof of value: staged failover into the mitigation path during a low-traffic window, a runbook rehearsal with the people who will actually be on call, synthetic load against a non-production endpoint if the provider permits it, and a documented, tested rollback. If a vendor will not support a rehearsal, that answer is itself the result.

Getting value from the provider you choose

The runbook is the deliverable that matters. Switchover steps agreed in advance, standing low TTLs on the records you may need to move, credentials held outside the affected estate, and an out-of-band communications channel so nobody is trying to edit DNS through a saturated VPN. CISA, the FBI and MS-ISAC set out the same fundamentals in their joint guidance on understanding and responding to distributed denial-of-service attacks (October 2024): baseline normal traffic so anomalies are visible, layer defences, and rehearse the response. Baselining is the step most often skipped, and without it nobody can tell whether 3,000 requests per second is an attack or a marketing email.

Ransom DDoS: the response order

The pattern is consistent. A short demonstration attack, often aimed at a checkout or login path so the impact is unmistakable. Then an extortion email with a payment deadline in cryptocurrency. Then a larger follow-up if the deadline passes. Payment rarely ends it, because a paying target is a proven target and the same group, or another using its name, tends to return.

The order that works: preserve logs, packet captures and the full email headers of the demand; notify the mitigation provider’s SOC and confirm rules are tightened on the endpoints hit in the demonstration; brief the executive and communications teams with a holding statement; report to Action Fraud and, for organisations in scope, to the NCSC; do not pay. Extortion campaigns are prosecuted, and have been for two decades, including custodial sentences for cyber-blackmail gangs that attacked online businesses. In the UK, denial-of-service attacks fall within the Computer Misuse Act 1990 as amended by the Police and Justice Act 2006, which put attacks that impair the operation of a computer clearly inside the criminal law.

Quarterly reviews

Attack logs, false positive reports, rule tuning and a re-test after every significant change to the estate: new domain, new API, new payment provider, new data centre. Most protection gaps found during incidents were created months earlier by a routine change that nobody put through the mitigation review. A short quarterly session with the provider’s engineers, not just the account manager, catches them.

Choosing among the best DDoS mitigation providers comes down to matching deployment model, layer 7 capability, DNS scope and support behaviour to the way your own estate fails, then proving it with a rehearsal rather than a data sheet. Further background on attack techniques and defensive options is collected across DDoSInfo’s archive of DDoS incidents and vendor coverage.

Frequently Asked Questions

Who are the best DDoS mitigation providers for UK businesses?

For web and API estates, the global anycast platforms (Cloudflare, Akamai and Fastly) are the usual shortlist because mitigation is always on at the edge. For whole prefixes, non-HTTP services and on-prem data centres, routed scrubbing such as Akamai Prolexic or a carrier equivalent fits better. Organisations without a 24/7 network team often get more from managed DDoS protection bought through a UK partner or protected host than from buying a platform direct.

What is the difference between always-on and on-demand DDoS mitigation?

Always-on means all traffic passes through the provider permanently, so filtering begins immediately and there is nothing to activate. On-demand means traffic is diverted only when an attack is detected, usually via BGP or DNS changes, which is cheaper but adds detection, decision and convergence time. On-demand can be entirely adequate if the acceptable outage window is measured in minutes, not seconds.

How much does DDoS mitigation cost, and what drives the price up?

Pricing varies too widely across estate size and deployment model for a single figure to be useful, so treat published list prices as a starting point only. The main cost drivers are clean traffic volume, number of protected prefixes or hostnames, whether bot management is licensed separately, managed SOC coverage, and burst or attack-time terms. Always ask what an unusually large attack costs under the contract before signing.

Do I still need DDoS protection if my hosting provider says it is included?

Read the acceptable use policy first. Many hosts protect the platform rather than the individual tenant, and will null-route an attacked IP address to keep other customers online, which is a complete outage for you. Included protection is genuinely useful for volumetric floods, but rarely covers application-layer attacks or your authoritative DNS.

How is DNS DDoS protection different from protecting a website?

Web protection filters HTTP and HTTPS requests at a proxy; DNS protection defends the authoritative nameservers that tell the world where your services live. If DNS goes down, everything behind it becomes unreachable regardless of how well the web tier is defended. Anyone running their own authoritative nameservers should price DNS mitigation separately, for example a hybrid service such as Akamai Shield NS53 sitting in front of on-prem DNS.

What should I do if I receive a ransom DDoS demand?

Preserve the demand with full email headers, along with logs and captures from any demonstration attack, then alert your mitigation provider’s SOC and tighten controls on the endpoints that were targeted. Report it to Action Fraud, and to the NCSC if your organisation is in scope. Do not pay: it marks you as a paying target and rarely ends the campaign.

Is a CDN with WAF enough, or do I need separate bot management?

A CDN with a tuned WAF handles volumetric floods and known exploit patterns well. It is weaker against distributed bot traffic that sends well-formed, individually plausible requests to expensive endpoints, which is how many application-layer outages happen. Estates with logins, search, basket or ticketing flows generally need dedicated bot management alongside the WAF, plus per-endpoint rate limits.

Managed DDoS Protection UK: How to Choose a Provider (With Costs)

Buying managed DDoS protection in the UK is less about picking the biggest scrubbing network and more about proving three things to whoever signs the contract: that the service covers every surface an attacker can reach, that it can actually be deployed on your IP addressing, and that the SLA and the billing schedule agree with each other. Those are the points that decide whether an incident becomes a footnote in a board pack or a week of recovery.

This guide takes the buyer’s side of that conversation: what “managed”should mean in scope, where UK estates are routinely left uneven, how pricing is built, and what to do in the first hour if an attack has already started.

What the word “managed”actually buys you

The dividing line is simple. A self-service plan gives you a dashboard, a rate-limiting engine and a set of rules you write, tune and troubleshoot yourself. A managed service means a 24/7 security operations centre watches your traffic, declares an incident, applies mitigation on your behalf and tells you afterwards what it did. If a human on the provider’s side is not empowered to change policy at 03:00 without your sign-off, you have bought monitoring, not management.

A defensible scope of work includes onboarding and initial rule tuning, always-on traffic baselining, alerting to named contacts, mitigation without waiting on your approval, attack reporting with vector breakdowns, in-event change requests (whitelisting a payment partner, loosening a rate limit for a genuine campaign spike), and a written post-incident review. Ask for the escalation matrix in the contract: named engineers, an out-of-hours bridge number, and a maximum time to human contact rather than a maximum time to automated email.

Follow the resale chain before you sign

Many offers badged as managed DDoS protection are partner-programme wrappers around somebody else’s scrubbing capacity. That pattern is old and persistent: hosting providers layered their brand over specialist mitigation appliances and networks in the mid-2000s (Layered Technologies with netZentry, and the wave of Prolexic-era hosting partnerships that followed), and vendors have long run formal channel schemes such as IntruGuard’s managed security services partnership programme to let service providers resell mitigation under their own name. For sector buyers weighing this, our look at law firm cyber attack protection beyond phishing breaks down what managed cover actually costs.

Reselling is not a fault. Opacity is. Three questions settle it: who staffs the SOC you reach at 3am, whose network physically filters the packets, and who holds authority to change policy mid-attack. If the answer to the second question is a third party, ask what the reseller’s own SLA is against theirs, because you can only be covered to the depth of the weakest link in that chain.

The three surfaces UK buyers protect unevenly: network, application and DNS

Volumetric layer 3/4 floods (UDP reflection, SYN floods, carpet bombing across a whole prefix) are the surface everyone buys for. They are also the easiest for a scrubbing centre to absorb. The harder problem is application-layer traffic and automated bots that arrive at human-plausible request rates against expensive endpoints: search, basket, login, API pagination. That behaviour sits under the volumetric alarm thresholds entirely, which is why bot-management capability (Fastly Bot Management, Cloudflare Bot Management, Akamai Bot Manager and comparable tooling) belongs in the requirements list alongside raw capacity.

Authoritative DNS: the surface most often left unmanaged

An attack on your authoritative DNS produces a total blackout even when every web server is healthy, because nothing resolves. The EveryDNS episode of December 2010 made the point plainly: a DDoS aimed at a single hosted domain led the provider to drop that domain to protect the rest of its customer base, and the site went dark despite its web tier being untouched. Hybrid designs that shield on-premise and cloud DNS together, the design intent behind Akamai Shield NS53, exist precisely because organisations keep their own resolvers for internal reasons and then expose them to the internet.

Practical requirement: either two independent authoritative DNS providers with matched zones, or a shielded/anycast authoritative service with its own DDoS posture. Do not accept “our CDN covers DNS”without confirming which nameservers actually answer for the zone.

Origin IP leakage defeats proxies more often than volume does

Proxy-based protection fails most commonly because the attacker never touches the proxy. The origin address leaks through mail records on the same host, stale A records for old subdomains (dev, staging, cpanel, legacy VPN), historical DNS archives, and certificate transparency logs that publish every hostname you ever requested a certificate for. Onboarding is incomplete until the origin firewall only accepts traffic from the provider’s published ranges, mail is moved off the web address, and the leftover records are cleaned out.

Before shopping, map the exposure: every public IP range you announce or are assigned, API endpoints, VPN and remote access gateways, payment and login paths, mail, and any third-party service that hard-codes your origin. The count of protected domains and IPs is what you will be quoted against, and coordinated hacktivist campaigns hit estates rather than single hostnames. The March 2024 attacks that disrupted multiple French government services, confirmed by the Prime Minister’s office and claimed by a hacktivist group, targeted a spread of state platforms at once.

Deployment models compared: reverse proxy, BGP scrubbing and hosting-level filtering

Reverse proxy / DNS-based mitigation. You point your DNS at the provider, which terminates and filters HTTP(S) at the edge. Fast to deploy (hours, not weeks), strong for web and API traffic, weak for non-web protocols, and only as good as your origin hygiene.

BGP diversion to a cloud DDoS scrubbing service. The provider announces your prefix during an attack (or permanently) and returns clean traffic over GRE tunnels or direct connectivity. This protects every protocol, not just web. The constraint that sales decks skate over: you must be able to announce your own /24 or larger, with your own ASN and an RIR allocation. Most UK SMEs sit on provider-assigned addresses inside somebody else’s aggregate and cannot divert at all. Establish which model your IP situation permits before you start comparing SLAs, because otherwise you are comparing capabilities you cannot buy.

Hosting and data centre included protection. Upstream filtering and blackholing bundled with colocation or cloud hosting is genuinely useful, and some UK managed service providers wrap it into a wider network contract, as with Claranet’s DDoS protection offering. The question to ask in writing is what happens at threshold: does the provider filter your traffic, or null-route your IP to protect its other tenants? A null route is a successful outage from the provider’s perspective and a total outage from yours. Whether that threshold works for or against you often hinges on always-on versus on-demand DDoS protection, a distinction worth weighing against your own traffic and budget before signing anything.

Always-on or on-demand

On-demand diversion is cheaper and adds no steady-state latency, but you pay for it in detection-to-diversion time, typically measured in minutes once BGP convergence is included. Short repeat bursts, the hit-and-run pattern favoured by extortion crews, punish that model: each burst lands, mitigation engages, traffic reverts, and the next burst lands again. Always-on removes that gap, at the cost of routing all traffic through the provider. For UK-facing services, check for a London point of presence and ask where clean traffic re-enters your network, since a mitigation path via Amsterdam or Frankfurt shows up in page timings.

How to compare UK DDoS mitigation providers without relying on the sales deck

Read the SLA clock and the billing clause together. A 60-second time-to-mitigate is close to worthless if the clock starts when you raise a ticket rather than when the provider’s detection fires, and a clean mitigation is a hollow win if attack traffic or the post-event burst lands on your bandwidth invoice. Get answers on:

Clock start and remedy. Time to notify, time to mitigate, whether measurement is from detection or from your ticket, and whether the remedy is a service credit worth a few days’ fees or something proportionate.
Capacity and architecture. Aggregate and per-PoP scrubbing capacity, PoP locations, behaviour under simultaneous multi-vector attack (layer 3 flood plus layer 7 request flood plus DNS query flood), and whether mitigation is automated or analyst-triggered.
Data residency and logging. Where request logs and TLS termination sit, retention periods, and how that reconciles with your UK GDPR position and any sector rules.
Billing. Whether attack traffic is unmetered, how clean-traffic overage is charged, per-protected-IP and per-domain counts, and whether burst charges can be triggered by an incident you did not cause.
Evidence. Sample attack reports, a redacted post-incident review, references in your sector, and a pre-agreed onboarding and failover test rather than a promise to test “at some point”.

Run the failover test before go-live and again annually. It is the only way to know whether the runbook, the contact list and the tunnels still work, and it is the artefact that satisfies auditors and boards.

What managed DDoS protection costs in the UK, and how pricing is structured

Pricing splits into four recognisable shapes:

CDN entry tiers, per domain. Published list pricing at the time of writing includes Cloudflare’s Pro plan at $20 per month and Business at $200 per month per domain. Self-service, not managed, and priced per zone, so a 30-domain estate multiplies quickly.
Fixed monthly platform subscriptions. AWS Shield Advanced is published at $3,000 per month per organisation on a 12-month commitment, plus data transfer charges; Microsoft’s Azure DDoS Network Protection is published on a similar fixed monthly basis covering a set number of public IP resources. Check current vendor pricing pages, as these change.
Clean-bandwidth commits. Scrubbing providers and carriers commonly price on committed clean Mbps/Gbps plus a per-prefix or per-protected-IP charge, with attack traffic excluded from metering (confirm that in writing).
Enterprise annual contracts with a managed service fee. A platform licence plus a separate SOC/managed line item, usually on 12 to 36 month terms.

Licence cost is rarely the whole spend. Budget separately for onboarding engineering, ASN and GRE tunnel work if you are diverting via BGP, DNS migration, WAF and bot rule tuning (the phase where false positives get found, and the one most often under-scoped), and any retained incident response hours.

Emergency onboarding while an attack is running is the most expensive way to buy. Providers price it as incident work, contract lengths get longer, and the tuning that normally takes two weeks happens under load. The rapid-response arrangements publicised in the market, including Cloudflare’s partnership with Booz Allen Hamilton to assist organisations already under attack, exist for exactly that scenario, and they illustrate the premium and the constraints attached to it.

Building the business case

Boards respond to downtime cost per hour, not attack sizes in gigabits. The arithmetic is straightforward: divide annual online revenue (or the cost of the service being unavailable) by realistic trading hours. An operation taking £12m a year online across roughly 4,000 effective trading hours carries about £3,000 an hour in gross order value at risk, before support cost, chargebacks and reputational effects. Set that against annual protection spend and the case usually writes itself. Financial services teams have a shorter path still, given the availability expectations that follow incidents like the DDoS attack that disrupted National Australia Bank’s online services.

Under attack now: the first hour, ransom demands and the UK legal position

Confirm it is a DDoS before you escalate. A capacity limit, an expired certificate, a bad deployment or a DNS misconfiguration all look like an outage. Check upstream interface counters, request rates versus error rates, and whether the traffic profile is plausible. Then work the sequence: notify your ISP and upstream hosting provider, since filtering closest to the source is the most effective option available, apply rate limiting where you can, and trigger the provider escalation path with a named contact rather than a web form. CISA’s guidance on understanding and responding to denial-of-service attacks sets out the same priorities, including engaging your service provider early and pre-planning the response.

If a ransom note arrives, do not pay. Preserve the demand with full email headers, keep flow data and logs, and report it: Action Fraud for the crime report (Police Scotland in Scotland) and the NCSC’s reporting route for significant incidents. Extortion crews test for payers, and the pattern of hit, demand and repeat has been prosecuted for two decades, as the Russian cyber-blackmail gang jailed for attacks on bookmakers demonstrated. Attack capacity itself remains a botnet supply problem, which is why coordinated botnet reduction initiatives keep reappearing on national agendas. The FBI and CISA have also issued joint public warnings about denial-of-service activity degrading access to public-facing critical infrastructure services, including their September 2020 advisory on DDoS against election infrastructure.

The legal and regulatory frame

Launching a DDoS attack is a criminal offence in the UK under the Computer Misuse Act 1990, section 3, as amended by section 36 of the Police and Justice Act 2006 to cover unauthorised acts intended to impair the operation of a computer. Custodial sentences are on record: Daniel Kaye was sentenced to two years and eight months at Blackfriars Crown Court in January 2019 over attacks that disrupted a Liberian telecoms operator.

Three regulatory duties shape requirements more than most procurement teams expect. Operators of essential services and relevant digital service providers carry security and incident-reporting obligations under the NIS Regulations 2018. FCA-regulated firms have to identify important business services and impact tolerances under the operational resilience regime (PS21/3), with firms required to be operating within those tolerances from 31 March 2025. And availability is a security requirement under UK GDPR, not just a commercial one, so a prolonged outage affecting personal data systems can carry regulatory questions alongside the revenue loss.

The decision, in the end, rests on fit rather than brochure capacity. Confirm which deployment model your addressing allows, cover network, application and authoritative DNS to the same standard, lock the origin, and make sure the SLA clock and the billing clause tell the same story. Managed DDoS protection bought on those terms in the UK is defensible in front of a board; a plan bought on peak-gigabit figures alone usually is not.

Frequently Asked Questions

What is managed DDoS protection, and how is it different from a self-service plan?

Managed protection means a provider’s SOC monitors your traffic, declares incidents, applies and tunes mitigation on your behalf, and reports afterwards. A self-service plan gives you the same filtering platform but leaves detection thresholds, rule writing and in-event decisions to your team. The practical test is whether the provider can change policy during an attack without waiting for your approval.

How much does managed DDoS protection in the UK typically cost?

Pricing follows four models: per-domain CDN tiers (Cloudflare publishes $20 and $200 per month for Pro and Business), fixed monthly platform subscriptions (AWS Shield Advanced is published at $3,000 per month per organisation on an annual commitment), committed clean-bandwidth pricing, and enterprise annual contracts with a separate managed service fee. Add onboarding engineering, DNS migration, tunnel setup and rule tuning to the licence cost, and treat any figure as a placeholder until you hold a written quote.

Does the DDoS protection included with my hosting or data centre cover me?

Partly. Bundled upstream filtering handles routine volumetric noise well, but ask what happens when the attack exceeds the platform threshold: many providers null-route the targeted IP to protect other tenants, which ends the attack and your availability at the same time. Get the threshold, the response action and the notification commitment in writing.

Do I need separate DNS DDoS protection if I already use a CDN?

Only if the CDN is genuinely authoritative for your zone and its DNS service carries its own mitigation and SLA. Plenty of organisations proxy their web traffic while leaving authoritative DNS on a small provider or an on-premise resolver, which leaves a single point of total failure. Either use two independent authoritative providers with matched zones, or a shielded anycast DNS service.

Can I get managed DDoS protection set up while an attack is in progress?

Yes. DNS or proxy-based onboarding can be completed quickly, and specialist rapid-response arrangements exist for organisations already under attack. Expect premium pricing, longer contract terms and imperfect tuning, and expect to fix origin exposure under load, which is why pre-contracting is materially cheaper.

Are DDoS attacks illegal in the UK, and can I take legal action after one?

They are criminal offences under section 3 of the Computer Misuse Act 1990 as amended by section 36 of the Police and Justice Act 2006, and UK courts have imposed custodial sentences. Report through Action Fraud (Police Scotland in Scotland) and the NCSC, preserve logs, flow data and any ransom correspondence with headers intact, and take separate legal advice on civil claims, which are usually difficult where attackers are overseas or unidentified.

Should we ever pay a ransom DDoS demand?

No. Payment marks you as a paying target, offers no guarantee the attack stops, and funds further activity, and there may be sanctions exposure depending on who is behind the demand. Report it, keep the evidence, and put the money into mitigation capacity and a tested runbook instead.