Tag Archives: ddos protection service comparison

DDOS Protection Cost UK: What You Really Pay

Ask five UK providers to price protection for the same ecommerce site and the quotes will range from a small monthly subscription to an annual contract many times larger, all of them described as DDoS protection. That spread is not a negotiating tactic. The DDoS protection cost UK buyers face varies by two orders of magnitude because the word “protection”is being used to sell at least three different products, bought by three different sorts of customer, with wildly different amounts of human engineering attached. Work out which product you are actually being quoted and the numbers stop looking random.

What follows is a cost anatomy from the buyer’s side: what each pricing model charges for, which line items stay invisible until the first attack, and how to turn downtime into a figure your finance director will sign.

Why DDoS protection quotes in the UK swing so wildly

Three markets hiding behind one search term

The first market is bundled protection: filtering included with a hosting plan, a content delivery network (CDN) tier or a cloud load balancer. Marginal cost near zero, tuning near zero.

The second is mid-market managed service: a monthly fee, a named provider, some human involvement, usually a reverse proxy or a small scrubbing arrangement in front of a handful of properties. This is where most UK mid-market buyers end up, and where the contract language matters most.

The third is enterprise Border Gateway Protocol (BGP) scrubbing with committed capacity: you announce your own /24, traffic is diverted to scrubbing centres, clean traffic comes back over GRE tunnels or a cross-connect. You are buying network capacity, a routing relationship and an engineering team. It has a high floor because all three cost money whether or not you are attacked.

What an entry-level plan genuinely covers

Entry-level proxy plans advertised in the UK market at low monthly prices are real products, not bait. They buy a share of a large anycast proxy estate, automated volumetric filtering, a rate-limiting engine and a dashboard. For a brochure site or a small SaaS front end, that is often proportionate.

What they do not buy is anyone’s attention. Best-effort means exactly that: your traffic is defended by the same automated policy as everyone else on the shared tier, and if a layer 7 attack slips through the generic rules, the rule changes are yours to write. If nobody on the provider’s side is authorised to change policy at 03:00 without your written sign-off, you have bought monitoring, not management.

Why G-Cloud day rates are quoting people, not bandwidth

Public sector buyers looking at the Crown Commercial Service’s Digital Marketplace will see mitigation services listed at a price per unit per day. Those unit prices confuse people who assume they are paying for gigabits. They are not. G-Cloud style day rates typically price consultancy, onboarding, incident response time and diversion support, in other words a human being for a day. Comparing a day rate against a monthly subscription is comparing a plumber’s call-out charge with a water bill.

The question that explains most of the gap

Several UK “providers”do not own a scrubbing centre. They resell capacity on a larger network, wrap it in a portal and a support contract, and add margin. Sometimes there are two resale layers. Each one is another party that must be woken up before a mitigation policy changes, and another margin on your invoice.

So before you compare headline prices, ask who owns the scrubbing centres, whose autonomous system number (ASN) the traffic is cleaned on, and what your escalation path looks like in the middle of the night. Two quotes that differ by 10x for the “same”protection are usually not describing the same distance between you and the engineer who tunes the filter.

The pricing models behind the number on your quote

Per protected property or per protected IP. A flat monthly fee covering a defined number of domains, hostnames or IP addresses. The trap is counting creep. Staging, a customer portal, an API endpoint, a mail relay and a second data centre each add a chargeable unit, and the tidy monthly figure can multiply by the time the estate is honestly documented. Count every public-facing address before signing, not after.

Clean traffic bands with overage. The contract commits you to, say, 100 Mbps of clean traffic delivered, with an overage rate per Mbps or per GB beyond it. This is the single most common source of a surprise invoice after an attack, because attacks change traffic shape. Legitimate users refresh, bots retry, and some providers meter the traffic they forward after scrubbing rather than the flood they dropped. Read the metering definition, ask whether it is 95th percentile or peak, and ask what happens to billing during a declared incident.

Committed capacity and per-Gbps pricing. BGP scrubbing deals price a committed clean bandwidth tier plus the plumbing: GRE tunnel provisioning, or a cross-connect in a shared facility with its own monthly port fee. Budget for the network engineering time too. Announcing a /24 to a scrubbing provider, testing failover and documenting the withdrawal procedure is not a half-day job.

On-demand and emergency onboarding. On-demand looks cheaper on the monthly line because you pay for standby, not for constant traffic handling. The costs move elsewhere: diversion time while routes propagate, and in many contracts an emergency onboarding fee if you are attacked before you are provisioned. Compare the annual always-on premium against that fee plus the extra minutes of downtime, not against zero. Our breakdown of always-on versus on-demand DDoS protection works through where each model genuinely fits.

What each deployment model really costs once you add everything up

Reverse proxy or CDN-fronted protection

Lowest entry cost, priced on requests and bandwidth, quick to deploy with a DNS change. Its weakness is not capacity. It is origin leakage. If your server’s real IP address is still visible in historic DNS records, mail headers, TLS certificate transparency logs or an old subdomain, attackers route around the proxy entirely and hit the origin directly.

No pricing tier fixes an exposed origin. Budget for the remediation instead: new origin addressing, firewall allow-lists restricted to the provider’s published ranges, cleaning up stale A records and moving outbound mail off the web server. That work is usually a few days of engineering, and it is the difference between a paid proxy service that protects you and one that decorates your invoice.

BGP scrubbing and always-on routing

Higher floor, because you are buying capacity and a route rather than a shared proxy slot. It suits ASN holders, hosting companies, data centre operators and anyone protecting non-HTTP services such as game servers, VPN concentrators or VoIP. Costs to model: committed Gbps, tunnel or cross-connect fees, a /24 you actually control, and the internal staff time to run the diversion.

Hosting-level filtering

Bundled with a DDoS protected hosting package, near-zero marginal cost, and genuinely useful against crude volumetric floods. What you rarely get is tuning, a named escalation contact or a forensic report afterwards. If the provider’s answer during an incident is to null-route your IP to protect their other tenants, your site is down either way.

Whichever model you choose, the sticker price is not the total. Add web application firewall (WAF) licensing if it is not included, TLS termination and certificate management, log egress charges if you ship traffic logs into a SIEM, and internal staff hours. On a mid-market deployment those adders routinely equal the mitigation fee itself.

The line items buyers forget until the first invoice

Authoritative DNS. Left off the quote more often than any other component, then added later and billed separately by query volume. A site sitting behind a fully mitigated proxy is still unreachable if its name servers fold, and name servers are a soft target precisely because they are UDP-based and often hosted with a registrar nobody has thought about since 2019. Price network and transport layer, application layer and DNS as one budget line. Our buyer’s guide to authoritative DNS protection covers what to demand from that part of the stack, and the NCSC’s guidance on denial of service attacks is worth putting in front of anyone who thinks the web tier is the whole problem.

Attack reports and forensic exports. Sometimes a paid add-on, sometimes only available on enterprise tiers. Yet a vector breakdown with timestamps, source distribution and packet rates is the evidence you need for an insurer, a regulator, your own customers under an uptime clause, or any legal action following a DDoS attack. If the report costs extra, that is a line item, not a nicety.

What “managed”buys. The most expensive undefined word in a DDoS contract. Pin it down in writing: will the provider change rules mid-attack on their own authority, or does every tuning decision wait on a ticket and your approval? The approval model is cheaper monthly and far more expensive per incident, because the clock runs while your on-call engineer finds the portal password. Ask how many rule changes are included per year and what a change request costs beyond that.

SLA credits. Time-to-mitigate commitments are meaningful only if the measurement method is stated. There is a large practical difference between “60 seconds from detection”and “60 seconds from customer report”, and credits are almost always capped at a percentage of the monthly fee. A 100% credit on a £900 month does not cover a £20,000 trading outage. Treat credits as a signal of confidence, not as compensation.

Price your downtime before you price the protection

The business case is arithmetic, not fear. Build it from three components: revenue or transaction value per hour, incident staff cost, and contractual exposure to your own customers.

Take an illustrative mid-size UK retailer selling online. Spread across realistic trading hours, its annual online turnover gives an average revenue per hour, but peak Saturday afternoons in the run-up to Christmas might run several times that. A four-hour partial outage on a peak weekend, assuming half of attempted orders are lost rather than deferred, removes a meaningful slice of a trading weekend’s gross revenue. Add the people pulled onto an incident bridge for a day, plus an out-of-hours agency callout, and the total climbs again before anyone mentions refunds or reputational damage.

Against that, the annual cost of a managed DDoS protection UK contract is a fixed, known number. The break-even question becomes concrete: does your organisation expect more than roughly one significant outage a year? For an ecommerce operator during peak trading, a law firm running a client document portal under a professional obligation, a healthcare supplier with booking systems, or a B2B platform with liquidated damages in its uptime clauses, the answer is usually yes.

Resist the temptation to inflate. The Department for Science, Innovation and Technology publishes an average cost of the most disruptive breach in its annual Cyber Security Breaches Survey, and boards increasingly recognise that figure. It covers all breach types, skews low because it includes micro-businesses, and will be picked apart if you present it as a DDoS number. Quote the current edition by name and date if you use it, then rely on your own revenue-per-hour model for the actual case.

How to compare UK quotes on evidence rather than sales decks

Send every shortlisted provider the same ten questions and compare the answers side by side:

Who owns the scrubbing centres, and are you a reseller of another network’s capacity?
What is the total mitigation capacity, and what capacity is committed to me contractually?
Is mitigation always-on or on-demand, and what is the measured time to divert?
Can your engineers change mitigation policy mid-attack without my written approval?
How is time-to-mitigate measured, from detection or from my report?
What clean traffic is included, how is it metered, and what is the overage rate?
How many protected IPs or hostnames are included, and what does each additional one cost?
Is authoritative DNS protection included, and is it billed by query volume?
Is a post-incident attack report with vector breakdown included at no extra charge?
What is the named escalation path at 03:00 on a bank holiday, and what phone number do I call?

Then ask for something sales teams rarely offer: a redacted attack report from a real incident in the last twelve months. A capability slide proves nothing. A report showing attack start time, vectors, peak packet rate and the minute mitigation engaged tells you whether the operations team exists. If you want a structured starting point for evaluating vendors, our DDoS protection service comparison sets out how the main approaches differ in practice.

Terms worth negotiating: minimum term (push back on 24 months if you have not tested the service), a burst allowance that waives overage during a declared attack, waiver of emergency onboarding fees, and an exit clause that includes DNS TTL handover so you can leave without a self-inflicted outage.

Red flags, in order of seriousness: “unlimited”capacity claims, which no network can honour once you read the fair use clause; “fully managed”with no definition of who is authorised to act; mitigation SLAs with no stated measurement method; and any provider who will not name the network their traffic is cleaned on. One more, quieter one: a quote that covers only HTTP when half your revenue runs through an API or a DNS zone nobody has audited.

The honest summary of DDoS protection cost UK-wide is that you are pricing three things at once: capacity, authority to act, and evidence afterwards. Cheap plans give you the first. Only the contract tells you whether you are getting the other two, and only the second attack tells you whether you were right. Read the clauses before you compare the prices.

Frequently Asked Questions

How much does DDoS protection cost in the UK per year?

Entry-level proxy plans advertised in the UK market start at modest monthly subscriptions. Mid-market managed services typically land in the low thousands to low tens of thousands annually, depending on protected IP counts and committed clean traffic. Enterprise BGP scrubbing with committed capacity runs higher again, and public sector day rates on G-Cloud listings are quoted per unit per day for incident and consultancy work. Check current pricing directly, as published rates change.

Why is there such a big gap between cheap and enterprise DDoS protection pricing?

Partly technology, mostly people and margin. Cheap plans share automated filtering across thousands of customers with no dedicated engineering time; enterprise contracts commit capacity, a routing relationship and named responders. The resale chain matters too, because each layer between you and the network that owns the scrubbing centres adds margin and removes direct access to the engineers tuning the mitigation.

Does free or bundled protection from a host or CDN count as enough?

For a low-risk brochure site, frequently yes. For anything revenue-bearing, the limits show up fast: little or no tuning, no forensic report, and a provider whose incentive during a large attack may be to null-route your address to protect other tenants. Bundled filtering also rarely covers your authoritative DNS, which is a separate failure point.

What extra charges can appear on an invoice after an attack?

Overage on clean traffic bands is the most common, followed by emergency onboarding fees if you were on an on-demand plan and not yet provisioned. Then look for per-incident support charges beyond included hours, rule change fees above an annual allowance, paid forensic report exports and DNS queries billed by volume.

How do I justify the cost of DDoS protection to finance?

Model revenue or transaction value per hour at peak, add incident staff cost and any liquidated damages you owe customers under uptime clauses, then compare one realistic outage against the annual contract value. Present it as expected loss avoided, not as a doomsday scenario, and cite any national figures you use by source and year so the number survives scrutiny in the room.

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 Protection Service Comparison: How To Judge 6 Vendor Claims Against Real Attacks

Most buyers start a DDoS protection service comparison by asking vendors for a feature matrix, then discover that every matrix looks the same. Everyone claims multi-terabit capacity, sub-minute mitigation and layer 7 defence. The differences that decide whether your checkout stays up on a Friday afternoon are rarely in the datasheet at all: they sit in the protection model you buy, the assets that model can physically cover, and the contract clauses that govern what happens in hour 40 of a sustained attack.

This piece compares protection models rather than brand names, tests each model against attack patterns that have actually played out in the wild, and gives you a scoring framework you can run over a shortlist inside a week.

What you are actually comparing: five protection models, not five brands

Vendor names change ownership. Models do not. There are five ways DDoS traffic gets stopped before it reaches your infrastructure, and each has hard limits on what it can protect.

Always-on CDN or reverse proxy

Cloudflare, Fastly and Akamai sit in front of your web estate permanently. DNS points at their edge, they terminate TLS, they filter, and they forward clean requests to your origin. Strong for HTTP/S, strong for layer 7 rules and bot management, and mitigation is effectively instant because traffic never routes to you in the first place. The constraint is protocol: anything that is not web traffic needs a different answer, and your origin IP must be genuinely hidden for the model to hold.

On-demand or always-on BGP scrubbing

You advertise your own prefixes, and when an attack starts, routes are diverted to a scrubbing centre via BGP, with clean traffic returned over GRE tunnels or a dedicated connection. This protects entire /24s and everything inside them: mail, VPN concentrators, SIP and RTP for voice, game servers, database replication, odd-port APIs. The trade-offs are diversion time (minutes, not milliseconds, unless you run it always-on) and the requirement that you own routable address space and can influence BGP announcements.

On-premise appliance

A hardware or virtual appliance at your network edge, inspecting traffic with full visibility of your applications. Excellent for low-and-slow layer 7 detection and for state-based attacks, useless against a volumetric flood that saturates your upstream transit before packets ever reach the box. Appliances belong in hybrid designs, paired with cloud capacity that can be signalled when the pipe fills.

Hosting or data-centre level protection

Included filtering from your hosting provider, colocation facility or ISP. It is usually shared, usually tuned to protect the provider’s network rather than your specific application, and often carries a null-route policy: if your IP attracts enough traffic to threaten neighbours, it gets black-holed. That is protection for the data centre, not for you. Providers have been rolling out this tier for well over a decade, including data centre operators adding anti-DDoS as a standard facility service, and it has real value as a baseline. Treat it as a floor, not a ceiling.

DNS-layer defence

Authoritative DNS hosted on an anycast platform built to absorb query floods, or a hybrid arrangement that shields on-premise name servers behind a cloud tier (Akamai’s Shield NS53 is the reference implementation of that pattern). Ignored in most comparisons, and the fastest route to a total outage when it fails.

Mature setups are hybrids: proxy for web, scrubbing for the rest of the address space, hardened or dual-provider DNS, and an appliance where deep application visibility is needed. Managed DDoS protection in the UK is often delivered through this stack by an MSSP rather than direct, which is a model that has existed since vendors first built managed security service partner programmes around mitigation appliances. The partnership layer matters, because the party you phone at 3am may not be the party operating the scrubbing centre. Before signing that quote, it is worth learning how to judge Tbps claims on scrubbing capacity against what the contract actually guarantees.

One check before you read any older comparison

The mitigation market has consolidated across generations. Prolexic’s scrubbing network now operates inside Akamai. IntruGuard’s technology was absorbed into Fortinet’s DDoS appliance line. Webscreen and netZentry were once fixtures on procurement shortlists and no longer exist as independent vendors. If you are working from a comparison written a few years ago, verify what the current entity actually operates today before you weight it.

The metrics vendors advertise, and the ones that decide your outcome

Advertised network capacity in Tbps tells you what the platform can absorb globally, across every customer, during the worst simultaneous event of the year. What matters to you is capacity and points of presence near your users. A 100Tbps global network with thin capacity in London and Manchester is worse for a UK retailer than a smaller network with dense European presence.

Time to mitigate is the metric most often quoted and most loosely defined. Ask what the clock measures. Detection? Route diversion complete? Or clean traffic restored to the customer? Ask whether mitigation is fully automated or requires a human in a NOC to approve a signature change, and what the escalation looks like at 02:00 on a bank holiday. An automated seconds-level response on a known attack vector is a different product from a 15-minute human-in-the-loop diversion, even when both appear in the same SLA table.

False positive rate is the metric nobody publishes. Aggressive challenge pages, JavaScript checks and CAPTCHA friction will protect your infrastructure and damage your conversion rate at the same time. During evaluation, ask for the tuning process: how quickly can a rule be relaxed, who can do it, and can you see the block decisions in your own logs?

Then separate the two attack classes properly. Layer 3/4 volumetric floods, reflection and amplification are a bandwidth and packets-per-second problem. Layer 7 request floods, credential stuffing and scraping are a request-economics problem, and they frequently sit inside your normal traffic envelope. A vendor scored purely on scrubbing capacity can win your comparison and still fail the incident.

Comparing providers against real attack patterns, not datasheets

DNS as the single point of failure

The clearest test in any comparison is what happens when the attack is not aimed at you. The October 2016 attacks on Dyn’s managed DNS infrastructure, driven by Mirai botnet traffic, took large numbers of unrelated customer sites offline simultaneously. Those sites were not attacked. Their web protection worked perfectly. They were unreachable because name resolution failed. Botnet-scale capacity of that kind has been a policy concern for years, with coordinated industry plans to reduce botnet activity running alongside enforcement work.

Which models survive it? An always-on proxy does not help if the DNS answering for your proxy hostname is down. Scrubbing does not help either. The only defences are DNS resilience by design: two independent authoritative DNS providers serving the same zone, or a hybrid arrangement shielding your own name servers behind cloud capacity. Put DNS resilience in the scoring grid as a weighted row, not a footnote.

Ransom DDoS with a deadline

The pattern is consistent: a 15 to 30 minute demonstration attack against a payment or checkout endpoint, followed by a note naming a cryptocurrency figure and a deadline measured in hours. Extortion has followed DDoS capability for as long as the technique has existed, and prosecutions do happen, as the jailing of Russian cyber-blackmailers who extorted UK bookmakers showed.

Now walk each model through that window. An existing always-on proxy needs a rule change and possibly a plan upgrade. Existing scrubbing needs a diversion request. If you have neither, you are onboarding a new provider under duress: DNS changes propagating against whatever TTL you set months ago, or a BGP announcement and tunnel build with an emergency onboarding fee attached. That is the moment long minimum terms get signed. Pre-agreeing an emergency onboarding path, with pricing, contacts and a tested runbook, costs far less than negotiating mid-attack. CISA, the FBI and MS-ISAC set out the reporting and non-payment position in their joint guidance, Understanding and Responding to Distributed Denial-of-Service Attacks (2024).

Hacktivist floods against public sector estates

In March 2024 the French Prime Minister’s office confirmed that multiple government websites had been hit by sustained DDoS attacks of what it described as unprecedented intensity, attributed publicly to hacktivist activity. Attention, not money, is the motive, which changes the profile: multiple targets across an estate, sustained over days, shifting vectors when one is blocked. Public sector buyers should test breadth of coverage across many small properties rather than depth on one flagship site, and should ask how billing behaves when 40 domains are simultaneously under load. Attackers pick symbolic targets, which is why even institutions with no commercial value get hit, as when a coordinated flood against the Vatican’s website failed to take it down.

Application-layer bot abuse on checkout and login

Credential stuffing against a login endpoint and inventory-hoarding bots on a checkout flow rarely register as bandwidth spikes. Requests are well-formed, come from residential proxy pools, and rotate user agents. Volumetric scrubbing will pass this traffic straight through. What stops it is bot management: device fingerprinting, behavioural scoring, rate limiting per credential rather than per IP, and the ability to serve a soft challenge to suspicious sessions without blocking genuine customers. Financial services have carried this load for years, from bank platforms knocked offline by flooding to the botnet operators behind the traffic being named and pursued.

Contract terms, pricing models and the clauses buyers regret

Pricing generally follows one of three shapes: pay-as-you-go clean bandwidth, flat-rate unmetered mitigation, or a committed tier with burst charges above it. Model the third one against a 72-hour attack before you sign. Ask explicitly whether overage is billed on clean traffic delivered to you or on total traffic absorbed, because the difference across three days of a large flood can be substantial.

Then read the definitions clause. What counts as an attack? Some agreements only trigger SLA obligations above a stated packets-per-second or bandwidth threshold, which conveniently excludes exactly the layer 7 events that hurt e-commerce. Check whether SLA remedies are service credits (a discount on a bill) or an actual time-to-mitigate commitment with a measurable start point.

Finally, run an asset coverage audit before you compare anything. List every internet-facing service: web, APIs on non-standard ports, SMTP and mail gateways, VPN and remote access, DNS, FTP or SFTP transfer endpoints, legacy IP ranges from acquisitions, staging and CI environments. Mark which model can protect each one. This is where most comparisons quietly fail, because the shortlist was built around web traffic and the estate is not.

A scoring framework you can run on a shortlist in a week

Weight the rows to your own risk, then score each shortlisted provider from 1 to 5. Suggested starting weights:

Asset inventory coverage (25%): percentage of your listed internet-facing services the provider can actually protect under the proposed design.
Layer 7 and bot handling (20%): rule granularity, bot scoring, rate limiting by credential or session, tuning turnaround.
Time to mitigate (15%): defined start point, automation level, out-of-hours escalation.
DNS resilience (10%): anycast authoritative DNS, secondary provider support, on-premise shielding options.
Reporting and forensics (10%): post-incident reports you can hand to a regulator or board, log export to your SIEM.
Escalation route (10%): named contacts, who can trigger mitigation at 3am, whether the MSSP or the platform owner answers.
Cost predictability under a 72-hour sustained attack (10%): modelled, in writing.

Demand proof rather than claims. Ask for an authorised load or attack simulation against a staging environment, with written permission from both parties. Ask for two reference calls in your own sector, not a logo wall. Ask for a redacted attack report from a real incident, which tells you more about reporting quality than any sample dashboard.

Sector weighting matters. Banks and payment operators should weight escalation and forensics higher, given operational resilience expectations. Healthcare and other essential service operators carry availability duties under the NIS Regulations, and availability sits inside the security obligations of UK GDPR. E-commerce should weight bot handling and cost predictability, with PCI DSS considerations for the checkout path. Legal firms usually weight confidentiality of traffic inspection and TLS key handling. For a broader view of the defensive options behind these scores, our overview of DDoS attacks and the possible solutions available covers the underlying techniques.

Migration and operational traps that neutralise good protection

The most common failure in this field is scope, not capacity. An organisation puts its web estate behind a proxy, leaves mail, VPN and an API on port 8443 outside it, and then finds the origin IP is still discoverable. Check DNS history archives, MX records that point straight at your network, certificate transparency logs (which publish every hostname you have ever requested a certificate for), and forgotten staging subdomains. Attackers query those sources first.

After cutover, lock the origin firewall to the provider’s published IP ranges. Skipping this step leaves a direct path around every control you just bought. Keep the outgoing provider live in parallel for a defined window, lower DNS TTLs well before the migration date so you can move quickly, and rehearse a failover during business hours rather than discovering the gaps during an incident.

Align the runbook with published guidance. The NCSC’s denial of service guidance collection covers preparation and response for UK organisations, and the CISA joint guide sets out reporting expectations. On the legal position, denial-of-service attacks are criminal offences in the UK under the Computer Misuse Act 1990, following the amendments made by the Police and Justice Act 2006 that put unauthorised acts impairing the operation of a computer beyond doubt. Report incidents; do not pay ransoms; and note that UK police forces have been building specialist e-crime capability for years, including dedicated regional e-crime units.

Run the comparison this way and it stops being a datasheet exercise. A useful DDoS protection service comparison ends with a scored grid tied to your own asset inventory, a modelled cost for a three-day attack, a tested emergency onboarding path, and DNS resilience treated as its own line item rather than an assumption.

Frequently Asked Questions

What should a DDoS protection service comparison actually measure?

Coverage of your real asset inventory first, then layer 7 and bot capability, defined time to mitigate, DNS resilience, reporting quality, escalation route and cost predictability during a long attack. Advertised network capacity in Tbps is a weak differentiator on its own, because it describes the platform’s global ceiling rather than what it will do for your specific traffic mix.

Is an always-on CDN proxy better than on-demand BGP scrubbing?

Neither is better in the abstract. A proxy gives near-instant mitigation and strong application-layer controls, but only for HTTP/S traffic, and only while your origin IP stays hidden. BGP scrubbing protects whole prefixes including mail, VPN, voice and non-standard ports, at the cost of diversion time unless you run it always-on. Most mature estates use both.

How much does managed DDoS protection cost in the UK?

Entry-level proxy plans are published openly by some vendors, while scrubbing and managed enterprise contracts are quoted case by case, so avoid budgeting from headline figures. The variables that move the price are protected bandwidth, number of protected prefixes or domains, always-on versus on-demand, bot management inclusion, and support tier. Ask every bidder to price the same 72-hour attack scenario so the quotes are comparable.

Does my hosting provider’s included DDoS protection count as enough?

It is a reasonable baseline against commodity floods, but it is usually shared, tuned to protect the provider’s network, and may include a null-route policy that black-holes your IP to protect other tenants. Check the terms for that clause specifically, and check whether it covers application-layer attacks at all.

How do I protect DNS as well as my website?

Use an anycast authoritative DNS platform built for query floods, and consider running two independent DNS providers for the same zone so a single provider outage does not remove you from the internet. If you must keep name servers on-premise, use a shielding tier in front of them, the pattern Akamai implements with Shield NS53.

What time-to-mitigate SLA is realistic to ask for?

For always-on proxy or always-on scrubbing, mitigation of known vectors should be effectively automatic and measured in seconds. For on-demand BGP diversion, a few minutes from detection to clean traffic restored is a reasonable ask, provided the contract defines which of those two events starts the clock and what the out-of-hours escalation looks like.

Can I test a provider’s mitigation before I sign?

Yes, with written authorisation from both parties and a booked window, usually against a staging environment or a dedicated test prefix. Unauthorised testing against infrastructure you do not control is an offence under the Computer Misuse Act 1990, so keep the scope, permissions and timings documented before anything is generated.

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.