Every few months a mitigation provider publishes a traffic graph with a new peak on it, the trade press repeats the figure, and somewhere in the UK a head of infrastructure forwards the link to their team with one line attached: are we covered for this? A terabit DDoS attack makes an excellent headline and a poor planning document. For a mid-market ecommerce or SaaS platform running a few hundred Mbps of normal traffic, with occasional spikes to a couple of Gbps, the record figures change almost nothing about what should be built. The things that actually take those sites offline are smaller, quieter and mostly unrelated to volume records.

What follows is the reasoning behind that claim, and then the specific evidence to demand from any provider whose sales deck leads with a terabit number.

What a terabit DDoS attack actually is, and where the traffic lands

A distributed denial-of-service (DDoS) attack at terabit scale means aggregate inbound traffic measured in terabits per second (Tbps), typically a flood of User Datagram Protocol (UDP) packets sent from tens of thousands of compromised hosts towards a target address or prefix. Three numbers describe such an event and they are not interchangeable: peak bandwidth in Tbps, packet rate in packets per second (pps), and total bytes delivered over the life of the attack.

Peak Tbps sells press releases. Packet rate is what kills stateful devices, because a firewall or load balancer has a pps ceiling long before it has a bits-per-second ceiling. Total bytes delivered is the honest measure of how much traffic a network really absorbed, and it is usually the number missing from the headline. Cloudflare’s disclosure of a 7.3 Tbps flood in mid-2025 put it at roughly 37.4 terabytes delivered in about 45 seconds. Short, brutal, over before most on-call rotas have finished reading the first alert.

Reading the record numbers properly

Publicly reported peaks have climbed quickly. Cloudflare reported 7.3 Tbps in mid-2025, then 11.5 Tbps later in the year, and by late 2025 its own quarterly DDoS threat reports had pushed the disclosed peak past 20 Tbps, with the trend line heading towards 30 Tbps. Several of the largest lasted under a minute. Duration matters more than most buyers assume, and it is the detail that reframes the whole on-demand mitigation question later in this piece.

The other detail worth holding onto: these measurements are taken at a global anycast edge spread across hundreds of points of presence. Anycast means the same IP address is announced from many locations at once, so a botnet firing at one address is automatically split across dozens of scrubbing points by internet routing. No single facility receives the full volume, and no single customer origin ever sees it. Treating a 30 Tbps figure as “the flood that would arrive at my rack”is a category error, not a conservative assumption.

Where the volume is absorbed

Terabit-scale traffic is eaten by upstream transit and peering capacity, by anycast distribution across scrubbing locations, and by filtering hardware sitting in those locations. None of that sits in your cabinet. Your firewall, your load balancer and your origin uplink are downstream of every decision that determines whether a large flood is survivable, which is why capacity is the one part of the problem you genuinely cannot fix yourself.

The sources behind the biggest floods are consistent: large botnets of Internet of Things (IoT) devices, compromised consumer routers and customer premises equipment, plus reflection and amplification through exposed UDP services. The economics are well documented in the booter and stresser market, where rented capacity is sold by the minute; the practical defender response to botnets available for hire has little to do with matching their peak output.

Why volume records rarely explain why a UK site went down

Run the arithmetic on your own estate and the record numbers lose their grip. A 10 Gbps origin uplink is saturated by roughly 0.03 percent of a 30 Tbps event. A 1 Gbps uplink goes under at about 0.003 percent. Anything above a few Gbps pointed at a single origin is already a complete outage, so the difference between a 7 Tbps record and a 30 Tbps record is academic from where you sit. Your real ceiling is three to five orders of magnitude below the league table.

So what does take these sites down?

Origin IP leakage, the most common bypass

More proxy bypass is caused by leaked origin addresses than by raw volume. The usual culprits are boring and repeatable: outbound mail headers that stamp the sending host’s real address on every transactional email; historical DNS records sitting in passive DNS databases years after a migration; certificate transparency logs listing staging, dev and admin subdomains that resolve straight to the origin; monitoring probes and payment callbacks configured against the origin IP because the proxy interfered with a health check once in 2021.

A terabit capability is irrelevant when 2 Gbps arrives at an address that was never supposed to be public. The fix is unglamorous: firewall the origin so it accepts traffic only from your provider’s published ranges or a private cross-connect, rotate the origin IP after onboarding, and send mail through a separate relay.

Application-layer floods that never register in Tbps

Layer 7 attacks are measured in requests per second, and the good ones are surgical. Consider 120,000 requests per second against an uncached product search endpoint on a mid-sized ecommerce stack. Database connections exhaust, queue depth climbs, the site returns 502s, and the whole thing registers well under 1 Gbps. Invisible in any terabit ranking. Cart, login, coupon validation and faceted search are the endpoints attackers reach for, because each request costs the target far more than it costs the botnet. The first sixty minutes of an ecommerce DDoS incident almost always involve this kind of traffic rather than a wall of UDP.

Authoritative DNS, the layer nobody owns

Authoritative Domain Name System (DNS) service is the surface most often left with whatever the registrar or hosting control panel supplied at setup. It is also the single point where a modest query flood removes every service at once, including the well-protected ones, because a client that cannot resolve your name never reaches your carefully scrubbed web tier. Three questions settle it: who operates your authoritative DNS, across how many independent anycast networks, and is that service inside the same mitigation contract as your web traffic? If the answer to the third is no, sound DNS DDoS attack protection is the cheapest resilience upgrade available to most UK buyers, and the specific gaps to close at the DNS layer are worth reviewing before renewal.

Deployment models that can absorb terabit-scale volume, and what each costs you

Four models dominate the UK market, and each buys capacity in a different currency.

• Reverse proxy on anycast. Very large aggregate capacity, fast HTTP and HTTPS mitigation, straightforward onboarding by DNS change. Protects only what resolves through it, and collapses as a control the moment the origin is directly reachable.
• Border Gateway Protocol (BGP) scrubbing and diversion. Protects whole prefixes and non-HTTP services such as SMTP, game protocols and APIs on odd ports. Needs a /24 or larger that you control, plus a return path by Generic Routing Encapsulation (GRE) tunnel or cross-connect, and route propagation adds minutes you must plan around.
• Hosting-level and data centre filtering. Convenient, frequently bundled, sometimes genuinely capable. Capacity is shared across every tenant and the ceiling is whatever the facility’s upstream transit contract allows, which is rarely disclosed in the order form.
• On-premise appliances. Useful for application-layer inspection and internal east-west protection. Useless against volumetric floods, because the flood arrives on a pipe the appliance cannot widen.

Always-on versus on-demand against a 40-second flood

Here is where the record-breaking figures earn their place in the analysis. A flood lasting 35 to 45 seconds exposes the on-demand model’s central weakness. Detection has to fire, a human has to authorise diversion, a BGP announcement has to go out, and routes have to propagate across the internet. That sequence can consume more time than the attack lasts, producing the graph nobody wants in the post-incident pack: mitigation starting just as the traffic stops.

The recommendation is blunt. Always-on for public web surfaces, and on-demand reserved for cases where diversion genuinely costs you in latency or money, such as a latency-sensitive trading path or a rarely attacked internal prefix. The trade-offs between always-on and on-demand protection are real, but sub-minute bursts have tilted the balance decisively for anything customer-facing.

How to read a provider’s terabit capacity claim without a lab

Capacity claims come in three flavours and only one of them affects your uptime.

1. Aggregate network capacity. The sum of everything, everywhere. Marketing number.
2. Per-point-of-presence capacity. More honest, still not yours.
3. Capacity in the region serving your users. For a UK customer base, that means London and, ideally, a second European site for failover. This is the only figure that decides whether your Tuesday morning stays quiet.

Then trace the resale chain. A meaningful share of UK managed DDoS protection is resold, sometimes twice, and the capacity in the deck may belong to a network the seller has no operational control over. Ask directly: whose autonomous system number announces my prefix during mitigation, whose scrubbing centres filter it, and which company employs the engineers who join the bridge at 03:00? A reseller can be a perfectly good buy if the answers are clear and the escalation path is named. It is the vagueness that should worry you.

Evidence to request instead of a slide

• A redacted attack report from the last quarter showing vector breakdown, peak figures, detection timestamp and mitigation timestamp;
• The service level agreement (SLA) definition of time to mitigate, with confirmation that the clock starts at detection rather than at ticket acknowledgement, a distinction covered in more depth in this examination of what SLA mitigation seconds actually mean;
• A named escalation matrix with roles and out-of-hours numbers, not a shared inbox;
• Change-freeze behaviour during peak trading, including who can push a rule change on Black Friday and who signs it off.

What “managed”has to mean in writing

Managed is the most elastic word in this market. Insist on written detail for onboarding and initial rule tuning, always-on traffic baselining, who is authorised to issue a mitigation order without customer sign-off, how a false positive gets rolled back mid-flash-sale, and what a post-incident report contains and when it arrives. If nobody on the provider’s side can change policy at 03:00 without waking your CTO, you have bought monitoring, not management. The buyer’s guide to managed DDoS protection in the UK goes further on how these contracts are typically priced and scoped.

Sizing your own exposure and building the business case

Work out your real ceiling in this order: origin port speed, upstream transit commit (the committed rate, not the burst), load balancer packet-per-second throughput, then authoritative DNS query capacity. Most teams discover the binding constraint is not the number they assumed. A 10 Gbps port fronted by an appliance that tips over at a few hundred thousand packets per second has a pps ceiling, not a bandwidth ceiling.

UK pricing tends to be built from committed clean bandwidth, per-prefix or per-domain charges, overage on attack traffic, and a cap on mitigation events per year. Read the overage clause carefully, because a single large event billed on attack traffic can dwarf the annual subscription.

Build the case from downtime cost, not from last quarter’s record. Do the division on your own trading figures: a shop turning over roughly £40,000 a day is losing, on that arithmetic alone, in the region of £1,700 of gross revenue per hour offline, before chargebacks, support volume and paid advertising spend burned on landing pages nobody can reach. That figure justifies the spend. A 30 Tbps headline does not.

One scenario to rehearse before it arrives: the ransom demand, usually a short demonstration burst followed by a deadline and a wallet address. Escalate to your provider and report it to Action Fraud, the UK’s national fraud and cybercrime reporting centre. Never pay. Payment marks the target as willing and invites the next demand, a pattern seen repeatedly in extortion cases involving DDoS blackmail prosecutions.

A short exposure review to run this month

1. Leak hunt: check certificate transparency logs, passive DNS history and outbound mail headers for your origin address, then lock the origin to provider ranges only;
2. DNS resilience check: confirm who runs authoritative DNS, how many anycast networks carry it, and whether it sits inside your mitigation contract;
3. Failover test: divert and return during a maintenance window, and time it properly against the SLA;
4. Escalation contact: one named person at the provider, one deputy, tested out of hours, documented where the on-call engineer can find it at 03:00.

The UK’s National Cyber Security Centre publishes practical guidance on denial of service preparation that pairs well with that checklist, particularly on understanding your own service dependencies before an incident rather than during one.

Frequently Asked Questions

How big is the largest terabit DDoS attack recorded so far?

Publicly reported peaks moved from 7.3 Tbps, disclosed by Cloudflare in mid-2025, through 11.5 Tbps, to figures above 20 Tbps in Cloudflare’s own reporting by late 2025. All of these are vendor-reported measurements taken at a global anycast edge, and the record moves often, so treat any figure as accurate at the time of writing rather than permanent.

Would a terabit DDoS attack take down a site that already has protection?

If the site is behind a large anycast network and the origin is not directly reachable, a terabit flood is absorbed across hundreds of locations and no single facility sees the full volume. The realistic failure modes are different: a leaked origin IP, an application-layer flood aimed at expensive endpoints, or an unprotected authoritative DNS zone. Fix those three before worrying about the peak figure.

How much bandwidth does it take to knock a typical business website offline?

Far less than the headlines suggest. A 1 Gbps origin uplink saturates at roughly 0.003 percent of a 30 Tbps event, and a 10 Gbps uplink at roughly 0.03 percent, so anything above a few Gbps arriving at a single unprotected origin is already a full outage. Stateful devices often fail earlier still, on packet rate rather than bandwidth.

Can on-demand DDoS protection stop a 40-second terabit flood?

Usually not in time. Detection, human authorisation, BGP announcement and route propagation can together take longer than a 35 to 45 second burst, so mitigation engages as the traffic ends. Always-on filtering is the sensible default for public web surfaces, with on-demand kept for prefixes where diversion carries a genuine latency or cost penalty.

What evidence should I ask for when a provider claims terabit-scale scrubbing capacity?

Ask for capacity in the region serving your users rather than the global aggregate, a redacted attack report from the last quarter with detection and mitigation timestamps, and an SLA that starts the time-to-mitigate clock at detection. Then trace the resale chain to the party that owns the scrubbing points and employs the on-call engineers. If a claimed terabit DDoS attack capability cannot be attached to a named network, named facilities and a named escalation path, treat the number as somebody else’s.