DDoS (Distributed Denial of Service)

A DDoS attack is a distributed denial-of-service attack. It makes a site or service unavailable by aiming more traffic, or more work, at it than it can handle. The traffic comes from many sources at once. It is a denial-of-service attack scaled out. RFC 4732, section 1 defines DoS as "an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work". RFC 4732 calls an attack distributed once the attacker reaches scale "by compromising enough end-hosts (typically using a virus or worm) or routers". A set of such compromised machines under one controller is a botnet. A DDoS is not a data breach. The goal is downtime, not theft or access. It is also not always distributed in the obvious sense. This is because reflection attacks bounce traffic off innocent third-party servers. RFC 4732 adds that "there are also many cases where a single well-connected end-system can perpetrate a successful DoS attack". A CDN defends from the front. Its anycast network scatters the flood across many edge servers and filters it there, so only clean traffic reaches your origin.

How it works

Every DDoS needs two things arranged: traffic sources, and a resource at the target to exhaust.

The sources are either a botnet the attacker controls, or other people's servers borrowed by reflection. Cloudflare describes the botnet route. Devices are "infected with malware, allowing them to be controlled remotely by an attacker". In this route, "these individual devices are referred to as bots (or zombies), and a group of bots is known as a botnet". Reflection needs no botnet at all. It needs only the ability to forge a source address. RFC 4732, section 3.1 gives DNS reflection as the classic case. The attacker sends a DNS query with "the spoofed address of the victim" as its source. Also, "the request is carefully chosen so that the size of the response is significantly greater than the size of the request, thereby providing the amplification". That asymmetry is why reflection now dominates. Cloudflare's DDoS Threat Report for the first half of 2026 reports that "the attack-vector center of gravity shifted from botnet floods to reflection and amplification". The same report puts DNS-based vectors at 34.3% of all network-layer activity.

The resource being exhausted is what separates the three families of attack.

• Volumetric, layer 3: this fills the link. RFC 4732, section 2.7: "The simplest DoS attack is to simply send enough non-congestion-controlled traffic such that a link becomes excessively congested, and legitimate traffic suffers unacceptably high packet loss." UDP reflection and DNS amplification are the common vectors. AWS classes these as attacks that "attempt to saturate the capacity of the targeted network or resource".
• Protocol, layer 4: this exhausts connection state rather than bandwidth. The canonical case is the SYN flood. RFC 4732, section 2.1.3 calls it "essentially a memory-exhaustion attack": "the attacker sends a flood of TCP SYN packets to the victim, requesting connection setup, but then does not complete the connection setup". AWS notes such a flood "can exhaust connection state on resources like servers, load balancers, or firewalls".
• Application layer, layer 7: this spends the server's own work budget with requests that look real. Cloudflare states: "The goal is to overwhelm the target with requests, since a single HTTP request can be expensive for the target server to respond to." These attacks barely need bandwidth. Slowloris holds many partial HTTP requests open until every server thread is tied up. Cloudflare is explicit that it "is not a category of attack but is instead a specific attack tool designed to allow a single machine to take down a server without using a lot of bandwidth".

The families overlap in practice. RFC 4732, section 2.1.2 lists what an application can be starved of. This includes memory, CPU cycles, disk space, processes or threads, and "the configured maximum number of simultaneous connections the application is permitted". AWS observes that "a larger TCP SYN flood may intend to saturate the capacity of a network while also exhausting the state of the targeted resource".

Why it matters for a CDN

Without a CDN, the flood arrives at one origin behind one public link. The thresholds are low. Cloudflare's H1 2026 report is blunt about scale: "A 100 Mbps attack is enough to overwhelm a server or website" and "A 100 Gbps attack can knock most unprotected data centers offline". Anycast changes the geometry, because one address is announced from every PoP. The flood then lands across the network instead of funnelling into the origin. Cloudflare lists "Anycast network diffusion: Using an Anycast network to scatter the attack traffic across a distributed network" as a mitigation strategy in its own right. RFC 4732, section 2.6 records the precedent: "A number of the root nameservers have since been replicated using anycast to further improve their resistance to DoS." Diffusion is not an even division, though. Traffic follows routing, so some PoPs take far more than their share.

Two further properties earn their keep. An edge that terminates the client connection can absorb shapes the origin cannot. Cloudflare "buffers incoming requests before starting to send anything to the origin server", so low-and-slow traffic such as Slowloris "never reach the intended target". Most attacks are also finished before a human could respond. In the first half of 2026, Cloudflare measured "96.62% of network-layer attacks remaining under 500 Mbps and 90.60% ending in under 10 minutes", while 935 network-layer attacks still exceeded 1 Tbps. Attacks are mostly small and brief, occasionally enormous. This is why mitigation has to be automatic and always on rather than a ticket you raise.

What CDNs do

• Cloudflare: autonomous detection and mitigation, marked "available on all plans", covers "layers 3/4 (network layer) and layer 7 (application layer) of the OSI model". The availability table lists standard, unmetered layer 3-7 protection on Free through Enterprise. Advanced TCP and DNS protection are reserved for Magic Transit customers (Cloudflare DDoS Protection docs).
• Fastly: DDoS Protection is a separately purchased product. It is "disabled by default, but can be enabled directly in the Fastly control panel". Enabling is not the same as mitigating. You then pick a protection mode of Logging, which only observes attack traffic, or Blocking, which actually mitigates (About DDoS Protection).
• AWS: Shield Standard "is provided automatically and at no extra charge when you use AWS". AWS documents its mitigation logic for CloudFront and Route 53 specifically. Shield Advanced is a paid subscription "for higher levels of protection against attacks" (How AWS Shield and Shield Advanced work).
• Google Cloud: Cloud Armor's Always-on DDoS protection covers "Layer 3 and Layer 4 volumetric and network protocol-based DDoS attacks, such as protocol floods (IP fragments, TCP SYN, ICMP) and amplification attacks (NTP, UDP, DNS) at no additional cost" for applications behind Google Cloud load balancers. But "to help protect against application-layer (L7) attacks, you must configure a security policy" (Cloud Armor overview).

Watch out for

• An exposed origin IP defeats the entire arrangement, because the traffic never meets the edge. Cloudflare's origin protection checklist is mostly about hiding it. Proxy your DNS records. Audit DNS-only records such as SPF and TXT to make sure they "do not contain origin IP information". Keep mail off the protected server, because bounces "reveal the mail server IP". Rotate origin IPs after onboarding, because "historical records are kept". Allowlisting the CDN's IP ranges helps. But it is, in Cloudflare's own words, "vulnerable to IP spoofing".
• A flash crowd looks like an attack. RFC 4732, section 1: "in principle it is not possible to distinguish between a sufficiently subtle DoS attack and a flash crowd (where unexpected heavy but non-malicious traffic has the same effect as a DoS attack)." Over-tight rate limiting or WAF rules therefore deny service to the users you were defending.
• Cache busting turned into a weapon. AWS describes cache-busting attacks as HTTP floods that use "variations in the HTTP request's query string that prevent use of edge-located cached content and forces the content to be served from the origin web server" (Examples of DDoS attacks). A CDN in front of you buys nothing if every request is engineered to miss cache. Normalise the cache key. Do not pass arbitrary query strings to the origin.
• Your DNS is a separate target with its own failure mode. RFC 4732 treats DoS on sites through DNS as its own class. AWS lists the DNS query flood: "an attacker uses multiple DNS queries to exhaust the resources of a DNS server". Every edge can be healthy while nobody can resolve your name.
• Blackhole routing, the fourth strategy on Cloudflare's list, stops the flood by discarding the whole prefix, legitimate requests included. It protects the neighbours, not the service.
• Source count says little about attack size. Amplification and reflection mean a handful of hosts able to spoof can generate a multi-gigabit flood.

Best practice

• Provision for your genuine peak before anything else. RFC 4732, section 4: "the first line of defense against DoS attacks must be to provision your service so that it can handle a foreseeable legitimate peak load. Underprovisioned sites are the easiest to take down."
• Put the CDN in front of every public entry point. Make the origin unreachable except through it: an outbound-only tunnel, authenticated origin pulls, or a network allowlist at minimum.
• Keep always-on L3/L4 protection enabled. Add an explicit L7 layer too: a WAF, rate limits and challenge rules tuned to your normal traffic. On Fastly and Google Cloud, that L7 step is a deliberate action, not a default.
• Raise the cache hit ratio. Cached responses are answered at the edge. As Cloudflare puts it, caching "reduces the number of requests sent to your origin server". Capacity planning and DDoS mitigation are the same work here.
• If you operate a network, filter at ingress. RFC 2827 is BCP 38. It shows that by "restricting transit traffic which originates from a downstream network to known, and intentionally advertised, prefix(es), the problem of source address spoofing can be virtually eliminated". RFC 4732, section 3.2 lists ingress filtering first among strategies to mitigate amplification.
• Watch for false positives after every rule change. Settle the escalation path while nothing is on fire: who is called, and whether the answer is scrubbing or a blackhole.