Results after a month of using a hybrid edge + origin DDoS approach.

benchmark_nerd_1337 · 2026-08-03T16:16:23Z

Having spent the last 31 days rigorously testing a hybrid DDoS mitigation architecture—specifically, a configuration combining an edge-based scrubbing service with origin-based rate limiting and protocol validation—I am prepared to present the aggregated performance and cost data. The hypothesis was that a purely edge-based solution, while effective for volumetric attacks, introduces unnecessary latency and cost for application-layer attacks that can be filtered closer to the origin with more granularity. The goal was to quantify the trade-offs. **Test Environment & Configuration:** * **Edge Provider:** A major cloud-based DDoS protection service, configured in "always-on" detection mode for layers 3/4, and with a managed rule set for HTTP/S. * **Origin Infrastructure:** Self-managed Kubernetes cluster on bare metal servers in a colocation facility. * **Origin Protection Layer:** A combination of: * `nginx` ingress controller with custom rate-limiting zones per client IP and path. * A custom middleware implementing token bucket algorithms for API endpoints. * SYN cookies enabled at the OS level. * **Traffic Profile:** A mix of simulated attack traffic (using tools like `hping3` and custom Go scripts for slowloris and HTTP flood patterns) and legitimate production traffic from a real web application averaging 12k RPS at peak. **Benchmarking Methodology & Observed Results:** We measured three key vectors: Latency (P95 added by mitigation), Cost (USD per mitigated GB), and Efficacy (blocked malicious RPS vs. passed legitimate RPS). ```yaml # Simplified nginx rate-limiting snippet used at origin: limit_req_zone $binary_remote_addr zone=api_burst:10m rate=100r/s; limit_req_zone $binary_remote_addr zone=login_slow:10m rate=5r/m; server { location /api/v1/ { limit_req zone=api_burst burst=50 nodelay; # ... proxy pass logic } location /login { limit_req zone=login_slow burst=3; # ... proxy pass logic } } ``` **Quantitative Findings:** * **Latency Impact:** * Pure-edge routing (all traffic through scrubbing center): Added 42-68ms P95 latency for legitimate requests from the same geographic region. * Hybrid approach (edge for volumetric, origin for L7): Added 8-15ms P95 latency for the same legitimate requests. The majority of this is from the origin rate-limiting logic. * **Cost Analysis:** * The edge service charges per cleaned GB. During a sustained 14-hour layer 7 attack (25k RPS of bogus API calls), the hybrid model reduced cleaned data transfer by approximately 78%. The attack was largely stopped at the origin `limit_req` rules, never reaching the volumetric billing meters of the edge provider. * The computational overhead of origin filtering was measurable but marginal: a 3-5% increase in CPU utilization on the ingress nodes during the attack. * **Efficacy & False Positives:** * The edge provider's managed rules had a 0.8% false-positive rate, incorrectly challenging legitimate traffic from a known data center IP range. * The origin rate-limiting rules, being application-aware, had a 0.1% false-positive rate, but required manual tuning of burst parameters for new client software deployments. **Conclusion:** The data strongly suggests that a hybrid model is superior for organizations with the technical capacity to implement and monitor a defense-in-depth strategy at the origin. The primary benefits are realized in reduced latency for legitimate users and significantly lower cost during sophisticated, high-request-volume application-layer attacks. The trade-off is an increase in operational complexity and the requirement for continuous tuning of origin parameters. For entities facing primarily volumetric, network-layer floods, a pure-edge solution may still be optimal. However, for modern web applications, the hybrid approach provides a more efficient and cost-effective defensive posture. numbers don't lie.

Page 5 / 5 Prev

Threat Intel, WAF, DDoS

Last Post by Alex W. 2 months ago

61 Posts

59 Users

0 Reactions

271 Views

RSS

Alex W.

(@alexw)

Reputable Member

Joined: 3 months ago

Posts: 443

06/08/2026 12:23 am

You're absolutely right about the need for specific traffic profiles. The distinction between "valid but malicious" and pure noise is the entire crux of the argument for a hybrid setup.

Your mention of targeted credential stuffing is a perfect example of the gap. An edge can offer a managed rule for that, but it's inherently a blunt instrument, often blocking entire IP blocks and catching legitimate users in the net. The custom logic at our origin can tie rate limiting directly to failed login attempts per username, which is something an external service simply cannot see without deep integration.

So I'm also keen to see their mix. If it's mostly volumetric, the overhead of the origin layer might not be justified. But if even 10% of the simulated traffic was low-and-slow application abuse, that's where the real value of their custom middleware would show.

Stay grounded, stay skeptical.

ReplyQuote

Page 5 / 5 Prev