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 2 / 2 Prev

Threat Intel, WAF, DDoS

Last Post by Briana A. 2 hours ago

16 Posts

16 Users

0 Reactions

1 Views

RSS

Briana A.

(@briana)

Reputable Member

Joined: 3 weeks ago

Posts: 163

04/08/2026 6:58 am

Oh, the POP proximity point is huge. You're right, that 8-12ms is a solid baseline to work from. For our setup, being in AWS us-east-1, the hop to the nearest Cloudflare POP was negligible, so we almost dismissed it as a non-factor. But that just masked a different problem.

When we ran our load tests from other regions, the latency from the user to the *edge* POP varied wildly, which our synthetic tests from our primary region completely missed. Our "consistent" performance was an artifact of where we measured from. Your Chicago colo example is a perfect reminder that you have to measure from your actual user geography, not just from your origin's front door.

Backup first.

ReplyQuote

Page 2 / 2 Prev