Fastly WAF vs Cloudflare WAF for high-traffic media sites

I'm a FinOps lead at a streaming media company serving about 8 billion requests monthly, managing a multi-CDN stack that includes both Fastly and Cloudflare, where we run WAF in production on each.

1. **Logging Cost Amplification**
At our scale, logging every WAF-matched request to our SIEM via Fastly's real-time logging is a dedicated six-figure annual line item. For Cloudflare, Logpush for WAF events to S3 is more affordable at our volume, roughly 20-30% of Fastly's equivalent cost. Cloudflare's model (cost per GB exported) was more predictable for us than Fastly's per-message throughput model, which spiked unpredictably during attack probing.

2. **Managed Rule Update Cadence and False Positives**
Cloudflare's OWASP core ruleset updates are aggressive, often several times a month, and default actions caused blocking issues with certain video player API calls and ad network beacons. We spent ~15 engineering hours monthly tuning exceptions. Fastly's managed rule updates were less frequent (major updates monthly) but were more surgical in our experience, resulting in fewer false positives for complex third-party media JS. Our tuning overhead dropped to ~5 hours monthly after migrating that property to Fastly.

3. **The Real Cost Per Million Requests**
The published $5-$10 per million requests is misleading. With full logging and DDoS protection layered on, our effective rate on Fastly was closer to $18 per million, and Cloudflare was about $12 per million. The largest differentiator was Cloudflare's lack of separate data transfer fees for blocked requests; Fastly charges for egress even on blocked traffic, which adds up during sustained probing.

4. **Vendor Support and Incident Response**
For a media site, you need support that understands "blocking a legit request is a revenue incident." Cloudflare's enterprise support is 24/7 but their initial response is often to direct you to rule exclusions. Fastly's support, while not 24/7 on standard plans, provided a dedicated TAM who understood our stack and would co-debug false positives with us in real-time during major events, which was critical.

Given your focus on logging costs and the false positive tax for ad-tech, I'd recommend Cloudflare WAF for its more predictable logging overhead and integrated platform pricing that doesn't charge for blocked request data transfer. However, if your team has less bandwidth for constant tuning and values a support team that deeply learns your traffic patterns, Fastly is the stronger choice. To make a clean call, tell us your monthly request volume and whether your security team requires full request/response logging for every WAF action.

You've hit on the core hidden cost. The billing model for observability is the real differentiator.

On point two, the false positive tax, I've seen Cloudflare's aggressive OWASP updates cause immediate, automated blocks on new ad partner callback patterns. Fastly's rule deploys are slower, but that gave us a crucial 24-48 hour buffer to review scoring in "log" mode before enforcement switched to "block". That latency directly reduced our tuning workload.

Which model is "better" depends entirely on your team's bandwidth for immediate incident response versus proactive tuning.

I'm coming at this from a smaller scale, so hearing about the six-figure logging overhead is a real eye-opener. Thanks for asking this, because I'd only been looking at the per-request WAF cost in our evaluations.

> the "false positive tax."

This is the part that worries me most. Our site's ad stack is already fragile. If an aggressive rule update starts blocking new vendor pixels or prebid callouts, that's a direct revenue hit we might not catch immediately. The idea that Fastly's slower update cadence could act as a built-in buffer is interesting. How much time does that realistically buy for a team without dedicated WAF analysts? Is a day or two enough to catch a major rule shift before it goes live?

Your data on tuning hours is exactly what we track to convert security overhead into a forecastable cost. Reducing from 15 to 5 hours monthly translates to a real engineering burn reduction.

However, there's a caveat to the cost-per-GB logging model being more predictable. While Cloudflare's Logpush to S3 is cheaper at steady state, the amplification during a zero-day or massive DDoS probe can still produce a massive, unpredictable S3 egress bill if you're pushing all logs to a region outside your provider's free tier. Have you factored that egress cost into your 20-30% comparison?

You're absolutely right about the S3 egress gotcha. We're on GCP, so our Logpush feeds into a Cloud Storage bucket in the same region as our analytics pipeline to avoid that exact cost. Anyone using AWS S3 in a different region than their processing is definitely going to get hit with an amplified bill during a volumetric attack.

That said, the per-GB model's predictability still holds for the Cloudflare product line item itself. The variable egress is a separate cloud provider cost, but it's a critical hidden variable. Fastly's per-message model internalizes that volatility into their own bill, which can be harder to forecast and negotiate around. The real comparison should be "total landed cost of logs in my SIEM."

The buffer point is interesting, but that latency also means you're exposed to novel attacks for longer. It's a direct trade-off between security responsiveness and operational stability.

That's a really useful breakdown, thanks. The difference in tuning hours is huge. I'm curious about something though: when you say Fastly's updates were "more surgical," do you think that's because of their slower cadence allowing for more testing, or is it more about the actual rule construction being different from Cloudflare's? Trying to figure out if that's a product philosophy or just a release cycle side effect.

Also, on the logging cost, does the 20-30% Cloudflare advantage include the compute cost of parsing those logs once they hit S3? Or is that purely the transport cost from their edge to your bucket? I'm trying to map the "total landed cost" you mentioned earlier to our own budget.

You're correct to highlight the egress variable as a separate, critical layer. Our 20-30% comparison isolated the Logpush product cost versus Fastly's logging endpoints. The total landed cost does include parsing compute, but for us, that's a fixed ETL batch cost. The volatile, attack-driven egress is the true wild card.

It forces a secondary architectural decision: you must colocate your log sink with your processing in the same cloud region, which can limit provider choice. Fastly's model abstracts that, but as you said, bakes the volatility into their bill, making annual commits harder to size. The predictability shifts from cloud egress to vendor pricing unpredictability.

This is super helpful, thanks. I'd only been thinking about the WAF line item, not the architectural lock-in from colocating the log sink.

When you say it limits provider choice, does that mean you're basically forced to pick S3, Cloud Storage, or Azure Blob based on where your primary analytics runs? What if your team uses BigQuery but wants to test Fastly? Does the logging model make that a non-starter?