Shortlists for Akamai vs Cloudflare DDoS protection usually arrive on a buyer’s desk as a two-column feature table, with aggregate network capacity at the top in terabits per second, a tick next to “always-on”, and a line about global points of presence (PoPs). That table tells you almost nothing about whether your estate stays up. Both vendors run large anycast networks, both publish very large pooled capacity figures, both sell a web application firewall (WAF) and managed authoritative domain name system (DNS). The differences that decide outcomes sit elsewhere: in deployment model, in who is authorised to change a mitigation policy at 02:00, and in which of your three attack surfaces the contract actually covers.
What follows is a comparison across six decision points a buyer can verify during a trial or in contract language, rather than in a deck.
What each vendor actually sells under the DDoS label
Start by separating the product lines, because this comparison is really four or five products, not two.
On the Akamai side, Prolexic is the routed, border gateway protocol (BGP) based scrubbing service that takes announcements of your own prefixes and cleans everything inside them. App & API Protector is the reverse-proxy tier for HTTP/S and API traffic, and Edge DNS is the authoritative DNS platform. On the Cloudflare side, Magic Transit is the routed equivalent, Spectrum extends proxy protection to arbitrary TCP and UDP services, the WAF and proxy tier handles web traffic, and Cloudflare’s authoritative DNS sits alongside.
Table stakes are genuinely shared. Both operate anycast edges with always-on capability, both apply automated detection with human escalation, both publish capacity numbers in the hundreds of terabits per second range. Treat that headline as close to meaningless for comparison purposes. Capacity is pooled across a global footprint, and your outcome depends on regional PoP capacity, peering towards the networks your users actually sit on, and how quickly mitigation policy adapts to a changing vector mix. None of that appears in a marketing figure, which is why it is worth understanding how to judge Tbps claims before you let them anchor a decision.
Three surfaces frame the rest of this piece: network and transport, application layer, and authoritative DNS. A buyer who scores both vendors across all three usually finds the gap is in their own design, not the vendor’s.
Gap 1: deployment model decides more than brand
Reverse proxy protection, Cloudflare’s default posture and the shape of Akamai’s App & API Protector, covers HTTP and HTTPS. Nothing else. It also depends entirely on your origin staying hidden, which is Gap 4.
Routed scrubbing, meaning Prolexic or Magic Transit, protects whole prefixes including non-web ports: SSH, game protocols, custom agent channels, SIP, UDP services. The constraint is address space. Announcing a prefix to the global routing table generally means a /24 at minimum, because longer prefixes are widely filtered. Organisations renting addresses from a hosting provider cannot announce anything, which rules out the routed option with either vendor regardless of preference. Those buyers are left with proxy products or filtering at the hosting layer, and should price accordingly.
A worked case makes the split obvious. A software-as-a-service platform serving a web application over HTTPS plus a custom TCP port for a device agent protocol can put the web tier behind a proxy comfortably, but the agent protocol needs either a routed service or a TCP/UDP proxy product such as Spectrum. That single port changes the shortlist and the price. A brochure estate with nothing but web and email, by contrast, has no business paying for routed scrubbing. A trading or multiplayer gaming platform with latency budgets measured in milliseconds almost always ends up routed, with on-demand diversion weighed carefully.
Gap 2: time to mitigate, and the always-on versus on-demand trade-off
Always-on removes the detect-and-divert delay because traffic is already on the vendor’s edge. The cost is permanence: every packet, every request, every cache decision and every false positive on a login path now lives at the edge.
On-demand keeps steady-state latency and often cost lower, but it introduces a clock with several components. Detection. Decision. BGP announcement. Route propagation across the internet. Read each vendor’s mitigation service level agreement (SLA) carefully and establish which of those stages the stated time actually covers, whether the clock starts on detection or on your notification, and what the remedy is worth when it is missed. A credit equal to a fraction of a month’s fee rarely covers a lost trading afternoon.
Then there is the return path, which almost nobody models before signing. Clean traffic has to get back to you, over generic routing encapsulation (GRE) tunnels, a direct interconnect, or layer 2 handoff, and each has its own capacity ceiling and failure mode. Long-lived sessions tend to break when traffic swings from direct to diverted and back. If your application holds websockets or persistent agent connections, test that swing rather than assuming it is invisible.
One practical request for both vendors: a sample attack report from a comparable customer, redacted. Judge the forensics. Does it give a vector breakdown, packet and bit rates over time, source geography, and the sequence of policy changes with timestamps? Or is it a bar chart and a reassurance?
Gap 3: authoritative DNS, the layer most buyers leave unmanaged
This is the surface that falls outside the contract most often. An organisation moves the web estate behind Akamai or Cloudflare, signs a mitigation SLA, and leaves the zone sitting with a registrar on a legacy platform because nobody wanted to touch nameservers during the migration. The one component that makes everything else reachable is then unprotected and unmanaged.
To a customer, a DNS failure and a site failure look identical. The difference is that your mitigation contract may not cover the former at all. DNS providers have been knocked over before, as the assault on Point DNS demonstrated, and the blast radius covers every zone on the platform, not just yours.
Both vendors sell managed authoritative DNS capable of absorbing query floods. Secondary or dual-provider designs spread the risk further, at the operational cost of keeping zones in sync and resisting the temptation to make changes in only one place. Put these in the request for proposal (RFP): query capacity per region, DNSSEC signing and key rollover handling, zone change propagation times, support for secondary transfer from a third party, and plainly, who is accountable when resolution fails.
Gap 4: origin IP leakage beats raw volume as the cause of bypass
When proxy protection fails, the usual cause is not an attack that outgrew the edge. It is an origin address that was discoverable. Neither vendor can filter traffic that never touches their network.
The leak paths are well known and rarely all closed:
- Mail headers from application-generated email sent straight from the origin host;
- Historical DNS records captured by passive DNS services before migration;
- Certificate transparency logs, which publish every issued hostname, including the publicly searchable CT log ecosystem that exposes staging and internal names;
- Development, staging and legacy hostnames pointing directly at the same infrastructure;
- Direct-to-origin API endpoints kept outside the proxy for a mobile client or a partner integration;
- Third-party uptime monitoring or status pages configured against the raw address.
Both vendors provide lock-down tooling: edge IP range allowlisting at your firewall, authenticated origin pulls using a client certificate, and tunnelled connectivity so the origin holds no inbound listener at all. The practical difference is how much of that work sits with you versus the provider, which is a question to ask in the onboarding conversation rather than assume.
Run an origin discovery exercise before you sign. Search certificate transparency, pull passive DNS history, inspect your own outbound mail headers, and see how long it takes to find the real address. Repeat the exercise after cutover and confirm the origin answers only to the vendor’s edge ranges. If it still answers to the open internet, you have bought a brand, not a shield.
Gap 5: what “managed”buys from each, and who touches the config at 02:00
The word covers a wide range at both vendors and across their channels. At one end, you get a portal, a rule engine and a support queue. At the other, a security operations centre (SOC) analyst tunes policy mid-attack on their own authority.
The dividing line is simple. If nobody on the provider’s side can change a rate-limit threshold or a filter at 03:00 without waiting for your sign-off, you have bought monitoring, not management. Get that answer in writing, with the named severities and response times attached.
Onboarding deserves equal attention: baselining legitimate traffic over a realistic period, setting rate limits that survive a marketing email going out, and handling false positives on login, basket and checkout paths where a blocked customer is indistinguishable from a successful attack. Ask for the escalation matrix, the named contacts, and whether out-of-hours cover is included or sold as an add-on.
Then map the chain. A large share of UK and European buyers purchase Akamai or Cloudflare through a partner or reseller, which means the scrubbing network, the SOC answering the phone and the entity owing you SLA credits may be three different organisations. Establish whose is whose before the attack, not during it. The NCSC’s denial of service guidance collection makes the same basic point about knowing your dependencies, and it applies as much to the support chain as to the network path. There is more on where responsibility tends to sit in our overview of the main DDoS mitigation approaches and their limits.
Gap 6: commercial structure, and building the case from downtime cost
Pricing shapes differ more than list prices do. Expect to see committed clean bandwidth bands, per-prefix and per-site fees, request volume tiers on the proxy and WAF side, and clauses covering burst or attack-time traffic. Self-serve tiers look inexpensive because the configuration, tuning and incident work has been moved onto your engineering team. That is a real cost; price it at a loaded day rate and the comparison shifts.
Build the case from downtime cost per hour, not sticker price. Add revenue, staff time, recovery effort and the support tail that follows a public outage. For many mid-market organisations a few hours of unavailability exceeds a full year of protection spend, which is a far stronger argument at board level than a vendor capacity chart. Our breakdown of how UK managed DDoS pricing is structured goes further into the line items.
Contract clauses worth reading twice: minimum term and auto-renewal, notice period, how many mitigation events are included, what counts as an “attack”for billing purposes, and whether overage during an incident is capped. A provider that bills you more when you are being attacked has built the wrong incentive into the agreement.
How to choose between them without a lab
A short decision path handles most cases. Mixed TCP and UDP services plus your own portable /24 points towards a routed service, where Prolexic and Magic Transit compete directly on time-to-mitigate wording, return-path options and support model. Web and API only, with addresses rented from a host, points to a proxy tier, where App & API Protector and Cloudflare’s WAF compete on rule tuning, false-positive handling and bot management depth. No in-house SOC means you are buying operating model above all, so weight the escalation terms heaviest. A regulated footprint adds data residency, logging retention and audit evidence to the list.
Before signing, demand: a redacted attack report from a comparable customer, the escalation matrix with named roles, an onboarding and tuning plan with dates, clarity on SLA credit history and process, and a named technical owner on the provider side. Then put the same scenario to both, for instance a 400 Gbps carpet-bomb across your prefix at 02:30 on a Sunday with a simultaneous layer 7 flood against the login endpoint, and compare the answers rather than the decks.
For a large share of buyers the honest verdict is that either vendor is technically capable, and the deciding factors are deployment fit, operating model and who genuinely owns the configuration during an incident. Close the gaps above and the brand on the invoice matters far less than the design behind it. For more on how attackers pick their targets and how defenders respond, keep reading our coverage of UK readiness research and attack trends.
Frequently Asked Questions
Is Akamai or Cloudflare better for DDoS protection?
Neither is categorically better across all three surfaces. Both run large anycast networks with always-on capability, managed authoritative DNS and mature WAF products, so the sensible comparison is between specific products and operating models rather than brands. Judge them on deployment fit for your port and address-space situation, SLA wording, and whether the provider or its reseller can change policy during an attack without waiting for you.
What is the difference between Akamai Prolexic and Cloudflare Magic Transit?
Both are routed, BGP-based scrubbing services that protect entire IP prefixes rather than just HTTP traffic, which makes them the option for non-web ports and mixed TCP/UDP estates. Both generally require you to control a /24 or larger of portable address space to announce. The differences to interrogate are return-path options (GRE, direct interconnect or layer 2), always-on versus on-demand behaviour, mitigation SLA scope, and the support and escalation model attached.
Does Akamai vs Cloudflare DDoS protection cover authoritative DNS as well as websites?
Only if you buy it and migrate the zone. Both vendors sell managed authoritative DNS (Akamai Edge DNS and Cloudflare’s DNS platform), but plenty of buyers leave the zone with a registrar or legacy provider after moving the web estate. If DNS sits outside the contract, a query flood against your nameservers takes the site down and the mitigation SLA does not apply.
Can attackers bypass Akamai or Cloudflare by finding my origin IP address?
Yes, and that is the most common bypass route for proxy-based protection. Certificate transparency logs, historical passive DNS, application mail headers, staging hostnames and direct-to-origin API endpoints all expose the real address. Lock the origin to the vendor’s edge ranges or use tunnelled connectivity, then run a discovery exercise against yourself to confirm it worked.
How is managed DDoS protection priced in the UK with either vendor?
Enterprise deals are typically structured around committed clean bandwidth or traffic bands, per-prefix or per-site fees, request volumes on the proxy tier, and clauses for attack-time burst. Self-serve tiers carry a lower line item but shift tuning and incident work to your team. Pricing is negotiated and changes over time, so check current terms with the vendor or partner and build your business case from downtime cost per hour rather than the headline figure.