Strategic Mitigation at Scale: Managing Billions of Requests with Cloudflare

While managing infra for several products, we saw 500M+ Layer 7 requests in a single 24-hour window, with total mitigated traffic in the billions over the project. Goal: 99.5% uptime. This post is a condensed view of the stack and config that got us there.

Architecture: Proxy-first, origin last

Cloudflare sits in front of your origin as a reverse proxy. You point DNS (A/AAAA or CNAME) at Cloudflare; they run Anycast (same IP from many PoPs), so traffic hits the nearest edge. TLS is terminated at the edge; only then do you get HTTP(S) to your origin. That gives you one place to enforce WAF, rate limits, and bot logic before a single byte hits your app.

Important for L3/L4: your origin IP is not published to the internet. Only Cloudflare’s IPs talk to it. Volumetric attacks (UDP flood, SYN flood, amplification) hit Cloudflare’s network, not yours. We didn’t have to scale our own network layer—we only had to handle the traffic that passed L7 checks.

L7: WAF, rate limiting, bots

All the “interesting” tuning was at Layer 7. We used three levers:

• WAF (custom + managed) — Custom rules in Cloudflare’s expression language (match on path, headers, URI, country, etc.). Plus managed rulesets (e.g. OWASP Core) in block or challenge mode. We started strict and relaxed rules that caused false positives after checking Firewall Events.
• Rate limiting — Count requests per key (e.g. IP or header) per time window; action = block or challenge. We applied different limits per path (e.g. stricter on login and signup, looser on static assets). Important: we used “count only certain status codes” where possible so 4xx/5xx from our app didn’t burn the limit for real users.
• Super Bot Fight Mode — Extra bot detection and JS/cookie challenges. Turned it on for paths that had no legitimate bot traffic; saw a clear drop in suspicious requests in Analytics and a reduction in origin load.

Example of the kind of logic we used for a custom WAF rule (conceptually; your expressions will depend on your app):

(http.request.uri.path contains "/api/auth" and 
  rate_limit(1, "1m", "ip") > 10) 
  or 
(cf.threat_score > 25 and 
  not ip.geoip.country in {"US" "GB" "DE"})

Translation: throttle aggressive auth attempts per IP; for high threat scores from certain countries we used challenge or block. We tuned thresholds and country lists from Firewall Analytics and origin logs.

Observability and tuning

We relied on Firewall Events (rule ID, action, count) and Analytics (requests, status codes, bandwidth by path and country). When we saw a spike in blocks or challenges, we checked whether it was a real attack or a misconfigured rule. We also watched origin 5xx and latency; if the origin started failing, we temporarily relaxed or disabled the noisiest rules until we could fix the rule or scale. Having a single dashboard for “what’s hitting the edge” and “what’s blocked” made it possible to iterate quickly during the incident.

Outcome

We held 99.5% uptime through the peak. There were short windows (on the order of minutes) where the origin threw 5xx under the heaviest load; we used that feedback to tighten edge rules and add rate limits so the next spike stayed at the edge. The majority of abusive traffic never reached our servers.

If you’re running high-traffic services and expect L7 abuse, putting a proxy layer in front (Cloudflare or similar) and investing in WAF, rate limiting, and bot detection will protect your origin. We used Cloudflare for this run and the combination of control plane, analytics, and support was a good fit for our scale and timeline.