Fastly vs. Cloudflare DDoS protection - which handled your real attack better?

I've recently had the unfortunate opportunity to evaluate the real-world DDoS mitigation capabilities of both Fastly and Cloudflare under sustained, sophisticated attack. The incident involved a multi-vector assault targeting a critical API endpoint, characterized by:

* A high packet-per-second (PPS) UDP amplification component.
* A mid-volume, but highly randomized, HTTP request flood attempting to bypass simple rate counters.
* A slower, application-layer attack targeting a specific, expensive database query path.

Our architecture placed the CDN/WAF as the edge, with traffic then flowing to an origin pool behind additional, on-prem scrubbing appliances. The goal was to assess not just the raw absorption capacity, but the operational granularity of tuning during an active incident, the quality of telemetry for forensic analysis, and the effectiveness of their default "on" protections.

**Fastly's Performance**
Fastly's approach felt surgical. Their network's reliance on a massive TLS terminator count meant the volumetric attack was absorbed without noticeable latency impact on other traffic—a clean separation. The real strength was in VCL (Varnish Configuration Language) for real-time mitigation. We could deploy logic that was incredibly specific.

```vcl
declare local var.anomaly_score INTEGER;
set var.anomaly_score = 0;

# Heuristic for query param randomization attack
if (req.url.qs ~ "id=[0-9]{9,}") {
set var.anomaly_score += 10;
}
# Combine with abnormal request timing from a specific ASN
if (std.ip(req.http.Fastly-Client-IP, "0.0.0.0") ~ client_asn_attack_pool && var.anomaly_score > 0) {
set req.http.X-Block-Reason = "Param/ASN Correlation";
error 403 "Forbidden";
}
```

The ability to blend real-time request attributes, previous request states (via `obj.hits`), and external data sources in a programmable language was powerful for the application-layer component. The tradeoff was cognitive load: crafting effective VCL under duress requires deep platform knowledge. Their threat intelligence feeds felt less prominent; the focus was on enabling you to build your own logic.

**Cloudflare's Performance**
Cloudflare's mitigation was more automated and holistic. Their Anycast network's scale for the volumetric attack was, as expected, absolute. No tuning was required for that layer—it simply vanished. For the HTTP randomized flood, the WAF's managed rulesets (specifically the OWASP and Cloudflare Managed rules) with a high sensitivity score started catching a significant portion after we enabled "anomaly scoring" mode. The managed approach meant faster initial response with less in-house expertise. Their graphql analytics provided a clear, near-real-time view of the attack topography, which was superior for executive communication.

However, we found the application-layer attack more challenging to mitigate precisely without collateral damage. Rate limiting at the edge (`http_rate_limiting`) is powerful but coarser than Fastly's VCL. Creating a truly complex heuristic (like the param/ASN correlation above) would require a custom rule written in the Wirefilter language, which, while capable, felt less immediately integrable with other request phases than VCL.

**Key Tradeoffs Observed**
* **Control vs. Automation:** Fastly offers a programmable edge for precise, logic-based mitigation, demanding more expertise. Cloudflare provides robust, automated defenses with excellent dashboards, enabling faster initial response for teams with less dedicated security depth.
* **Telemetry:** Cloudflare's analytics were more accessible and visual for broad-stroke analysis. Fastly's real-time logging and historical data (via Log Streaming) were superior for deep forensic investigation and building custom detection models post-incident.
* **False Positive Management:** During the attack, tuning Fastly's VCL logic to avoid false positives was straightforward because we controlled the exact logic. In Cloudflare, adjusting sensitivity scores on managed rules or crafting precise custom rules carried a higher risk of inadvertently allowing attack traffic during the tuning process.

In conclusion, the "better" handler depends entirely on your organizational profile and attack vector. For a team with strong security engineering resources who value precise control and are facing complex, application-targeted attacks, Fastly's programmable edge is a significant advantage. For organizations seeking maximum network-level absorption and a robust set of managed security rules that reduce operational burden, Cloudflare's integrated, automated suite is likely more effective. In our case, the sophistication of the application-layer attack made Fastly's granularity the deciding factor for that particular incident, though we acknowledge Cloudflare's overall package is formidable for more common attack patterns.