I've been analyzing latency and throughput numbers for edge services for the last three months, and a common point of confusion I see in architectural discussions is the conflation of Content Delivery Networks (CDNs) and dedicated Distributed Denial of Service (DDoS) protection services. While there is significant overlap in their infrastructure—both utilize globally distributed points of presence (PoPs)—their primary optimization targets, and consequently their architectural nuances, are fundamentally different. It's akin to comparing a sports car engineered for top speed with one engineered for maximum downforce and cornering; they're both cars, but their performance profiles diverge sharply under specific conditions.
A CDN's core performance metrics are **cache hit ratio, time-to-first-byte (TTFB), and overall data transfer throughput.** Its primary function is efficient, low-latency content delivery.
* It caches static assets (HTML, CSS, JS, images, video) close to users.
* It may offer basic security features like a Web Application Firewall (WAF) or rate limiting as a value-add, but these are often simplified or tiered.
* Its traffic filtering is typically designed to stop common, high-volume web attacks (e.g., SQLi, XSS) to protect *the cache* and the origin, not to sustain a volumetric network flood.
A dedicated DDoS protection service's core metrics are **packets per second (PPS), gigabits per second (Gbps) mitigation capacity, and mitigation time.** Its sole purpose is to absorb and filter malicious traffic before it reaches your infrastructure.
* Its entire stack, from network interfaces to routing logic (often using BGP flowspec), is optimized for real-time classification and dropping of attack traffic.
* It employs specialized hardware (scrubbing centers) with deep packet inspection (DPI) and behavioral analysis to differentiate between a legitimate user and a bot in a flood, often at layers 3, 4, and 7 simultaneously.
* While it proxies traffic, its caching capabilities are usually minimal or non-existent; its "performance" is measured in uptime during an attack, not latency reduction.
Consider a simple benchmark scenario: a 300 Gbps UDP reflection attack mixed with a 2 million RPS HTTP flood.
* **With a Standard CDN:** The volumetric UDP attack (layer 3/4) would likely bypass the CDN entirely if your origin IP is exposed, saturating your upstream bandwidth. The HTTP flood would hit the CDN's edge, but without advanced behavioral analytics and dedicated scrubbing capacity, the CDN's origin pull mechanisms could be overwhelmed, causing cache misses and eventual origin failure. Your CDN's bill for "uncached" origin transfers would also skyrocket.
* **With a Dedicated DDoS Service:** The service would announce your IP prefix via BGP (or you'd DNS CNAME to it). All traffic, including the UDP flood, is routed into their scrubbing network. Here, the layer 3/4 attack is filtered before it even reaches the logic handling HTTP. The HTTP flood is then analyzed across dozens of attributes (TCP window size, TLS fingerprint, request entropy) not just simple rate, allowing more precise filtering. Your origin sees only the cleaned traffic, often with minimal latency penalty *during the attack* compared to a CDN struggling under load.
The financial and operational difference is stark. A CDN prices on bandwidth delivered (egress). A DDoS service often prices on "protected bandwidth" (e.g., up to 10 Gbps) and features. For a company with a publicly accessible API or gaming servers, a CDN's basic protections are insufficient; the false-positive rate must be incredibly low, and the mitigation scale must be beyond what any single cloud provider's CDN offers. The reverse is also true: using a massive DDoS scrubber to deliver cat videos is cost-ineffective and suboptimal for latency.
In essence:
* **A good CDN** is a **performance and cost-optimization** layer, with security as a secondary benefit.
* **A DDoS protection service** is a **resiliency and survival** layer, optimized to absorb and discard the worst the internet can throw at you, with performance as a secondary benefit.
You choose based on your primary threat model and what you're benchmarking for. If your SLA is defined by 99.9% latency under 100ms, you benchmark CDNs. If your SLA is defined by 99.99% uptime even under sustained 500 Gbps attacks, you benchmark DDoS providers. The architectures, while converging in some "cloud security" platforms, are built for different races.
numbers don't lie
numbers don't lie
Good breakdown of the core metrics. The sports car analogy fits.
Where it gets messy is that a modern CDN's "basic" WAF is now often a rebranded, limited version of a full DDoS provider's stack. You can buy into a false sense of security because the checkbox is ticked.
A real DDoS service is built from the ground up for volumetric attack absorption and behavioral analysis at layer 3/4. Its entire edge network is tuned for scrubbing, not caching. A CDN's network is tuned for throughput - when a huge attack hits, your cached performance goes out the window because you're fighting for the same bandwidth.
slow pipelines make me cranky