The 10 largest DDoS attacks in history
(and what we learned)

Back to Blog

DDoS attacks have grown by roughly an order of magnitude every five years. What seemed unthinkable in 2013 — a 300 Gbps flood — would barely register as a blip against the multi-terabit barrages of the 2020s. Each record-breaking attack forced the industry to rethink its assumptions about capacity, protocol abuse, and incident response.

Here are the ten largest DDoS attacks ever recorded, listed chronologically, along with the concrete lessons each one taught us.

Spamhaus — 300 Gbps (March 2013)

In March 2013, the anti-spam organization Spamhaus became the target of a DNS amplification attack that peaked at 300 Gbps — the largest publicly reported DDoS attack at the time. The attack was traced to a dispute between Spamhaus and the Dutch hosting company CyberBunker, after Spamhaus added CyberBunker to its blocklist.

The attackers exploited open DNS resolvers to amplify small queries into massive responses directed at Spamhaus's infrastructure. At its peak, the attack generated enough traffic to cause measurable congestion at major Internet Exchange Points in London, Amsterdam, and Frankfurt. CloudFlare, which was providing mitigation for Spamhaus, described the collateral damage as affecting networks several hops away from the target.

The 2013 Spamhaus attack was the first DDoS event to make front-page news globally, proving that a single attack could degrade internet performance for millions of uninvolved users.

Attack type: DNS amplification
Peak volume: 300 Gbps
Mitigation: Anycast distribution via CloudFlare across 23 data centers absorbed the flood
Key lesson: Open DNS resolvers are weapons. This attack accelerated the global push to close open resolvers (Project Open Resolver, BCP38), reducing the amplification surface for future attacks.

OVH — 1.1 Tbps (September 2016)

In September 2016, French hosting provider OVH was hit by a DDoS attack that peaked at 1.1 Tbps. The attack was one of the first major incidents attributed to the Mirai botnet, which had compromised an estimated 145,000 internet-connected CCTV cameras and DVRs. OVH founder Octave Klaba posted a screenshot on Twitter showing the attack metrics: simultaneous floods exceeding 1 Tbps, sourced from IoT devices with default credentials.

What made OVH significant was not just the volume but the source. Previous record-breaking attacks relied on amplification — abusing protocols like DNS or NTP to multiply traffic. Mirai needed no amplification. The raw bandwidth of 145,000 compromised cameras, each capable of pushing 1–30 Mbps of flood traffic, was sufficient to break the terabit barrier without any reflection tricks.

145,000 cameras. 1.1 terabits per second. No amplification required. The Mirai botnet proved that the IoT itself was the amplifier.

Attack type: Direct volumetric flood (GRE, TCP SYN, ACK, UDP) via Mirai botnet
Peak volume: 1.1 Tbps
Mitigation: OVH's VAC (DDoS mitigation infrastructure) absorbed the attack using its 18+ Tbps scrubbing capacity
Key lesson: IoT devices with default passwords are a massive attack surface. Manufacturers must ship devices with unique credentials. This was the beginning of regulatory conversations around IoT security.

Dyn DNS — 1.2 Tbps (October 2016)

One month after OVH, the Mirai botnet struck again — this time targeting Dyn, a major DNS provider. On October 21, 2016, three successive waves of attacks peaking at approximately 1.2 Tbps hit Dyn's managed DNS infrastructure. Because Dyn provided DNS resolution for some of the internet's most popular services, the downstream impact was enormous: Twitter, Netflix, Reddit, Spotify, GitHub, PayPal, and dozens of other major websites became unreachable for hours across the US East Coast and Europe.

The attack used an estimated 100,000 Mirai-infected IoT devices. Unlike the OVH attack, which hit a hosting provider's dedicated mitigation infrastructure, the Dyn attack targeted the DNS layer itself — a critical dependency for virtually every internet service. Users could not resolve domain names, so even websites with perfectly functional origin servers were effectively offline.

The Dyn attack did not take down Twitter or Netflix directly. It took down the phonebook. When DNS fails, everything fails — and on October 21, 2016, half the internet's phonebook went dark for six hours.

Attack type: Multi-vector volumetric flood (TCP, UDP, DNS) via Mirai botnet
Peak volume: ~1.2 Tbps across three attack waves
Mitigation: Dyn expanded its server capacity and rerouted traffic; full restoration took approximately six hours
Key lesson: Single-provider DNS is a critical point of failure. After Dyn, multi-provider DNS became an industry best practice, and companies began treating DNS as a first-class infrastructure concern rather than an afterthought.

GitHub — 1.35 Tbps (February 2018)

On February 28, 2018, GitHub was hit with the largest DDoS attack recorded at the time: 1.35 Tbps of inbound traffic, generated entirely through memcached amplification. The attack exploited the memcached protocol, which runs on UDP port 11211 and can produce amplification factors exceeding 50,000x — meaning a 1 KB request can generate a 50 MB response directed at the victim.

GitHub's traffic spiked from its normal baseline to 1.35 Tbps in under 10 minutes. Akamai Prolexic, GitHub's DDoS mitigation provider, rerouted the traffic through its scrubbing centers and had the attack fully mitigated within 10 minutes of engagement. GitHub experienced intermittent availability for approximately 5 minutes during the initial surge, but no data was lost.

1.35 terabits per second in under 10 minutes, mitigated in 10 minutes more. The GitHub attack was the textbook case for why automated DDoS mitigation, not manual intervention, is the only viable response at terabit scale.

Attack type: Memcached amplification (UDP reflection)
Peak volume: 1.35 Tbps / 126.9 million packets per second
Mitigation: Akamai Prolexic scrubbing; full mitigation within 10 minutes
Key lesson: Memcached servers must never be exposed to the public internet on UDP. Within weeks of this attack, ISPs and cloud providers began filtering UDP port 11211 at the network edge, and the number of exposed memcached instances dropped by over 50%.

Google — 2.54 Tbps (September 2017, Disclosed 2020)

In October 2020, Google's Threat Analysis Group (TAG) disclosed that Google had absorbed a 2.54 Tbps DDoS attack in September 2017 — making it, at the time of disclosure, the largest attack ever recorded. The attack had gone unreported for three years. Google attributed it to a state-sponsored actor, noting that the attack originated from networks associated with a nation-state's internet infrastructure.

The attack used multiple methods simultaneously, including UDP amplification via CLDAP, DNS, and SNMP reflection. Google's infrastructure absorbed the attack without service disruption, which is partly why it went unreported for so long — from Google's users' perspective, nothing happened.

Google quietly absorbed a 2.54 Tbps DDoS attack in 2017 and did not mention it for three years. When you have a network built to handle a significant fraction of all internet traffic, a 2.54 Tbps flood is an anomaly, not an emergency.

Attack type: Multi-vector UDP amplification (CLDAP, DNS, SNMP reflection)
Peak volume: 2.54 Tbps
Mitigation: Absorbed by Google's global infrastructure with no customer-facing impact
Key lesson: Nation-state actors use DDoS as a tool, and many large-scale attacks go unreported. The disclosure highlighted the gap between what the public sees and what actually happens at the top end of internet infrastructure.

AWS — 2.3 Tbps (February 2020)

In its Q1 2020 threat landscape report, AWS Shield disclosed mitigating a 2.3 Tbps DDoS attack in mid-February 2020 — the largest attack AWS had ever observed. The attack used CLDAP (Connection-less Lightweight Directory Access Protocol) reflection, a technique that exploits exposed LDAP servers on UDP port 389 to amplify traffic by factors of 56x to 70x.

The target was an unnamed AWS customer. AWS Shield Advanced automatically detected and mitigated the attack, and the customer experienced no downtime. The attack lasted approximately three days, with the 2.3 Tbps peak occurring during the most intense wave.

Attack type: CLDAP reflection/amplification
Peak volume: 2.3 Tbps
Mitigation: AWS Shield Advanced automatic mitigation; no customer impact
Key lesson: CLDAP is one of the most dangerous amplification vectors, with amplification factors exceeding 50x. Organizations must ensure LDAP services are never exposed to the public internet on UDP, and ISPs need to implement BCP38 source address validation to prevent spoofed traffic from leaving their networks.

Microsoft Azure — 3.47 Tbps (November 2021)

In January 2022, Microsoft disclosed that Azure had mitigated a 3.47 Tbps DDoS attack in November 2021, setting a new record for the largest volumetric DDoS attack ever recorded. The attack targeted an Azure customer in Asia and originated from approximately 10,000 sources across the United States, China, South Korea, Russia, Thailand, India, Vietnam, Iran, Indonesia, and Taiwan.

The attack used UDP amplification across multiple vectors and lasted approximately 15 minutes. It was followed by two additional waves in December: a 3.25 Tbps UDP flood on port 80 and a 2.55 Tbps UDP flood on port 443 — both from the same actor. Azure's DDoS protection platform mitigated all three attacks without customer impact.

3.47 terabits per second from 10,000 sources in 10 countries. The Azure attack demonstrated that modern volumetric DDoS is a globally distributed operation, not a single botnet in a single country.

Attack type: Multi-vector UDP amplification
Peak volume: 3.47 Tbps / 340 million packets per second
Mitigation: Azure DDoS Protection automatic mitigation; no customer impact
Key lesson: Attacks now routinely combine sources from 10+ countries with multiple UDP vectors simultaneously. Effective mitigation requires globally distributed scrubbing capacity, not a single chokepoint.

Cloudflare — 26 Million RPS (June 2022)

On June 14, 2022, Cloudflare mitigated an HTTPS flood that peaked at 26 million requests per second — the largest application-layer (L7) DDoS attack recorded at that time. The attack was attributed to a small but powerful botnet dubbed "Mantis," consisting of approximately 5,000 compromised virtual machines and servers (not IoT devices). Each bot was capable of generating roughly 5,200 HTTPS requests per second.

Unlike volumetric attacks measured in terabits, application-layer attacks are measured in requests per second and are far more expensive for the attacker to generate — each request requires a full TCP handshake and TLS negotiation. The Mantis botnet achieved its scale not through sheer device count but by compromising high-bandwidth servers in cloud data centers.

Only 5,000 bots. 26 million HTTPS requests per second. The Mantis botnet proved that a small number of powerful machines on fast networks can be more devastating than millions of IoT devices.

Attack type: HTTPS flood (application-layer L7)
Peak volume: 26 million RPS
Mitigation: Cloudflare's autonomous DDoS protection at the edge
Key lesson: Application-layer attacks are shifting from botnets of IoT devices to botnets of compromised cloud VMs and servers. The cost per request is higher, but the impact per request is also higher because each one consumes real server resources.

Cloudflare — 71 Million RPS (February 2023)

In February 2023, Cloudflare reported mitigating the largest HTTP DDoS attack on record: 71 million requests per second. The attack exploited HTTP/2 Rapid Reset (CVE-2023-44487), a zero-day vulnerability in the HTTP/2 protocol that allowed attackers to open and immediately cancel streams in rapid succession, overwhelming servers without completing any actual data transfer.

The attack came from a botnet of approximately 30,000 IP addresses across multiple cloud providers. HTTP/2 Rapid Reset was a protocol-level flaw, meaning every HTTP/2 implementation — NGINX, Apache, IIS, cloud load balancers — was potentially vulnerable until patched. Google, Cloudflare, and AWS coordinated disclosure of the vulnerability in October 2023, months after the initial attacks began.

HTTP/2 Rapid Reset turned a protocol optimization feature — stream multiplexing — into a DDoS weapon. 71 million requests per second from 30,000 IPs, and every unpatched HTTP/2 server on the internet was a potential victim.

Attack type: HTTP/2 Rapid Reset (CVE-2023-44487), application-layer
Peak volume: 71 million RPS
Mitigation: Cloudflare edge detection and rate limiting; coordinated disclosure and patching across the industry
Key lesson: Protocol-level vulnerabilities can turn standard features into attack vectors. HTTP/2 stream multiplexing was designed for efficiency, but the RST_STREAM abuse pattern was never anticipated in the spec. Every protocol upgrade is a new attack surface.

Cloudflare — 5.6 Tbps (October 2024)

In October 2024, Cloudflare mitigated the largest volumetric DDoS attack ever publicly recorded: a 5.6 Tbps UDP flood generated by a Mirai-variant botnet comprising approximately 13,000 IoT devices. The attack targeted an unnamed internet service provider in Eastern Asia and lasted approximately 80 seconds. Cloudflare's distributed network detected and mitigated the attack fully autonomously — no human intervention was required.

The 5.6 Tbps figure represents a 61% increase over Microsoft Azure's previous 3.47 Tbps record from 2021. The attack used a Mirai variant, which means the fundamental technique — compromising IoT devices with default credentials and using them to generate direct volumetric floods — has not changed in eight years. What changed is the number and bandwidth of the devices available.

5.6 Tbps. 13,000 IoT devices. 80 seconds from first packet to full mitigation with zero human involvement. Eight years after Mirai's source code was released, the same botnet family set the all-time record.

Attack type: UDP volumetric flood via Mirai-variant botnet
Peak volume: 5.6 Tbps
Mitigation: Cloudflare autonomous detection and mitigation in under 80 seconds
Key lesson: Mirai is not a historical curiosity — it is the most successful DDoS malware family ever created, and its variants continue to set records. IoT security remains the single largest unsolved problem in DDoS defense.

Summary: All 10 Attacks at a Glance

What These 10 Attacks Taught Us

Taken together, these attacks reveal several patterns that define modern DDoS defense:

1. Amplification must be eliminated at the source. Every amplification attack on this list — DNS, memcached, CLDAP, SNMP — relied on services that should never have been exposed to the public internet. BCP38 and source address validation are not optional.
2. IoT security is a collective action problem. Mirai's source code was released in 2016. Eight years later, its variants still set all-time records. Until manufacturers ship devices with unique credentials and automatic updates, the botnet supply chain will not shrink.
3. DNS is infrastructure, not a feature. The Dyn attack proved that DNS deserves the same redundancy treatment as power and network connectivity. Multi-provider DNS is now table stakes for any production service.
4. Automated mitigation is non-negotiable. At terabit scale, human response times are irrelevant. The GitHub attack went from zero to 1.35 Tbps in under 10 minutes. The Cloudflare 5.6 Tbps attack lasted 80 seconds. If your mitigation requires a human to make a decision, you have already lost.
5. Application-layer attacks are the next frontier. Volumetric records get the headlines, but the Mantis and HTTP/2 Rapid Reset attacks showed that L7 floods from a few thousand bots can be more disruptive than terabit-scale L3/L4 floods because they consume server resources, not just bandwidth.

Back to Blog

Related Articles