Ignore the “largest DDoS attack ever” headlines – it’s the effect that matters

Another day, another “largest DDoS attack in history”.

‍

You’ve seen the headlines. A security vendor publishes a new post. The numbers are huge. The charts dramatic. And somewhere in the mix is the phrase “record-breaking”. The implied takeaway? We handled something massive — trust us, we’ve got this.

‍‍

Cloudflare is one of the more visible players when it comes to these updates. And to be fair, given its size and global reach, it likely does see more DDoS traffic than most. Its reports offer a glimpse into the scale of what’s happening out there — and it does a solid job of turning telemetry into digestible stories. But here’s the thing: in 2025, the size of a DDoS attack just isn’t the headline it used to be.

‍

Bigger is inevitable

Attack sizes are going up. That’s not a shocking trend — it’s a reflection of how infrastructure has evolved. Devices on 5G can now upload at 10Gbps. Carrier backbones are moving into 400Gbps territory. Botnets have more bandwidth and more flexibility than ever. So yes, attacks are getting bigger. But it’s not necessarily because the threats are getting smarter. It’s just that the pipes are wider.

‍

Where a 300Gbps attack used to feel catastrophic, today it’s something most large networks are expected to handle. It’s not breaking news anymore — it’s expected background noise.

‍

What doesn’t get talked about

Here’s a question you don’t often see answered: What was the impact on actual users? Did websites stay responsive? Were there login delays? Session drops? Did DNS time out or retries increase? Because when an attack pushes multi-terabit levels, even if your mitigation system holds the line, upstream networks — ISPs, IXPs, transit providers — might already be under pressure.

‍

That kind of congestion can lead to collateral effects. Not just for the target, but for neighbouring services sharing the same upstream routes. It’s not a failure of mitigation — it’s a limitation of how the internet is interconnected. But it rarely makes the summary.‍

‍

Sometimes, it’s not about the size

There are plenty of situations where an attack might look enormous on the surface — hundreds of gigabits per second, massive traffic spikes, all the right ingredients for a headline — but the actual impact ends up hinging on context, not raw numbers.

‍

A common example involves regional enterprises that primarily serve a local audience. These organisations can be hit with high-volume attacks that, at first glance, appear to justify large-scale, cloud-based mitigation. And in many cases, that mitigation works as intended: the traffic is absorbed, services stay online, and the charts tell a reassuring story.

‍

But under the hood, things can still go sideways. Once the attack crosses a certain threshold, some mitigation platforms will reroute traffic dynamically — sometimes pushing legitimate local users through out-of-country paths due to global anycast routing policies. For latency-sensitive applications, that added distance introduces enough delay to disrupt sessions, slow down responses, and degrade the overall experience — even though the attack was “successfully” mitigated.

‍

What’s often overlooked is that the bulk of the malicious traffic may not even be local. A large percentage might originate from outside the country or region, while the actual in-country load is minimal — maybe just a few gigabits, well within the limits of local infrastructure. With smarter traffic engineering — filtering foreign traffic upstream, and keeping domestic routes tight — the problem might have been resolved with far less disruption.

‍

It’s a good reminder that size doesn’t always correlate with severity. Where the traffic comes from, how it’s routed, and how mitigation interacts with application behaviour all play a critical role. Sometimes, the more effective response is the one that’s smaller, simpler, and better aligned with the real-world architecture behind the service.

‍

‍The story beneath the graphs

To be clear, there’s value in these “record” posts. They raise awareness. They demonstrate resilience. And yes — they reassure customers. If you’re operating a large-scale platform, telling people you’ve seen the worst and handled it is part of building trust.

‍

But there’s also a marketing rhythm to it. Vendors aren’t just publishing stats — they’re shaping a story. It’s not disingenuous; it’s just how the industry communicates. And some companies are better storytellers than others. The risk, though, is that we conflate volume with value — and miss the more important questions about how well the attack was contained, and whether users were protected end to end.

‍

What actually matters

So maybe it’s time we start shifting the conversation. Instead of focusing on how big an attack was, let’s ask: Was the user experience affected? Did mitigation trigger automatically — and fast enough? Were there ripple effects on neighbouring networks? Did critical services stay up? Were there any subtle performance hits that went unnoticed until later?

‍

These are the kinds of questions operations teams actually care about. Because when you’re running production infrastructure, it’s not just about how much traffic was blocked — it’s about how little anyone noticed.

‍

Let’s reframe the narrative

The DDoS landscape is always evolving. That won’t change. And yes, it’s still useful to track trends and highlight capabilities. But the volume of an attack isn’t the most important part of the story anymore. Not in a world where size alone doesn’t tell you anything about downstream impact. At the end of the day, the real measure of success isn’t how many packets were dropped. It’s whether real users stayed connected, responsive, and unaffected. That’s a harder thing to measure — and a harder story to tell. But it’s the one that matters.