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:

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