Alright, let’s cut through the marketing speak. I see this pattern constantly: teams deploy a cloud WAF or a DDoS mitigation service at the edge, check the box for “protection,” and then wonder why their origin servers are still sweating bullets, CPU pegged, logs filled with garbage traffic.
The core issue is a fundamental misunderstanding of what “edge protection” actually does—and more importantly, what it *doesn’t* do. Vendors love to sell you a magic bullet, but they’re less enthusiastic about explaining the fine print in their traffic filtering. Here’s the reality you’re probably facing.
First, consider the traffic flow. Your edge provider is likely only mitigating volumetric DDoS attacks (Layer 3/4) and maybe applying some basic WAF rule sets to application traffic. But if their solution is a simple proxy pass (which most are), they are still forwarding all *non-blocked* traffic to your origin. This includes all the slow-and-low application attacks, credential stuffing campaigns, aggressive scraping, and API abuse that slip through their often-generic, un-tuned rule sets. Your origin is still handling the TLS handshake, the session establishment, and the application logic for every single one of these requests. The bandwidth attack is stopped, but the resource exhaustion attack is alive and well.
Second, and this is critical, many of these services have significant blind spots. They often rely on threat intelligence feeds that are crowdsourced and reactive. If an attacker is using a novel vector or rotating through residential proxy networks (like Bright Data or IPRoyal), the edge might not flag it as malicious. That traffic, looking perfectly legitimate from the edge’s perspective, gets a free pass straight to your servers. You’re essentially paying for a bouncer who only turns away people on a known blacklist, while a hundred others slowly clog the hallways.
Then there’s the configuration problem. Default WAF policies are notoriously lax to avoid false positives and support tickets for the vendor. If you haven’t aggressively tuned the rules for your specific application—whitelisting legitimate patterns, creating custom rate limits per endpoint, blocking outdated user-agents or suspicious geographic origins you don’t serve—you’ve left the door wide open. The vendor’s goal is uptime and ease of use; security is a shared responsibility they’re happy to let you assume.
Finally, let’s talk architecture. If your “edge” is just a CDN/WAF in front, and your origin IPs are somehow exposed (through old DNS records, forgotten subdomains, mobile app APIs hardcoded to IPs, or misconfigured DNS), attackers will simply bypass the edge entirely. They’ll find your origin’s real IP and hammer it directly. No edge service in the world will help you if you haven’t properly obscured and protected your origin’s network endpoints.
So before you blame the tool, audit the implementation. Map exactly what traffic is reaching your origin. Look at your logs. I guarantee you’ll find a flood of requests that the edge deemed “clean” but are absolutely malicious in intent, consuming your resources. The solution usually involves a combination of stricter edge tuning, implementing additional application-layer controls closer to (or at) the origin (like fail2ban, modsecurity, or host-based rate limiting), and a ruthless review of your attack surface.
Just my two cents
Skeptic by default
Exactly. The proxy pass model means your origin is still the ultimate termination point for every connection that isn't outright dropped. That's a massive resource tax people don't account for.
One nuance is that some of the higher-tier services offer "origin shielding" where they maintain persistent connections and act as a true buffer, but that's a specific feature and often costs extra. Most setups don't have it.
Your point about the TLS handshake is critical. Even benign traffic that passes filtering still makes your origin do the expensive crypto work. If your edge isn't terminating TLS, you're not getting the full compute offload.
—AF
Oh man, you've nailed the proxy pass trap. It feels like you've bought a filter for your hose, but you're still using your well pump for every single gallon that comes through, filtered or not.
I'd add that a lot of the log garbage you mentioned becomes a secondary, hidden tax. All that junk traffic that gets passed through still hits your application logs, web server logs, and monitoring systems. It inflates your log volume, messes up your analytics, and can even trigger false alarms in your alerting because of weird request patterns. You're paying for log storage and parsing cycles on what is essentially noise.
The un-tuned rule sets are another huge pain point. Out of the box, those WAF rules are so broad they either block legit traffic or let through way too much. Tuning them properly is a full-time job nobody has time for, so you end up with this leaky sieve of a filter. Your origin still has to deal with all the weird, malformed, and borderline stuff that slips through the cracks.
Spreadsheets > opinions
> "they are still forwarding all *non-blocked* traffic to your origin"
Right, but let's not pretend the vendors are being sneaky here. The real magic trick is that they sell you "edge protection" as a silver bullet when the fine print basically says "we'll filter the obvious noise, and for everything else, you're still on the hook for the compute and bandwidth." It's a feature, not a bug. They want you to keep scaling up your origin because that's where their real money is -- compute and data transfer at the edge are a rounding error compared to the premium they charge for origin resources.
The more cynical take: if you actually tuned your rules and started dropping traffic at the edge, you'd reduce your origin load. Then your cloud bill would drop. Then you'd realize you were overprovisioned. Then you'd ask why you're paying for the edge service at all. So the incentive is to keep the proxy pass leaky enough that you never quite feel safe enough to cut the cord.
What's your origin running? If it's a monolithic app with no real caching layer, you're basically paying for a bouncer who opens the door for everyone who passes the pat-down, then lets them trample the bar.
-- cost first
You're missing the real choke point, which is the contract itself.
> edge provider is likely only mitigating volumetric DDoS attacks (Layer 3/4) and maybe applying some basic WAF rule sets
That's not a maybe, that's a guarantee based on the service tier you bought. The standard SLA covers layer 3/4 flood. Everything else is an optional add-on, often with per-rule-group pricing. If you didn't explicitly pay for the advanced bot management or API security module, you're not getting it. The vendor's default posture is to proxy the traffic through, because dropping it could violate their duty to deliver under the base agreement.
People blame the tech, but the failure starts at procurement when no one reads the line items for what *isn't* included.
Trust but verify.
Spot on about procurement. But the contract failure is only the first domino.
The security team that inherits the "edge protection" box then has to make it work. They're handed a service with the wrong features turned on, a logging feed that's useless for tuning, and a mandate to "just make it secure." They're set up to fail from day one because the people signing the checks bought a compliance checkbox, not an operational tool.
So you end up with a gap between what finance thinks they bought and what ops can actually configure. That's where the origin keeps getting hammered.
— geo
It's not just about overprovisioning. The financial incentive is clear, but the technical lock-in is worse.
If you've let the edge provider handle your DNS and TLS, migrating away is now a project. That's by design. The leaky proxy keeps you dependent while they upsell you the "real" solutions, like their compute platform or managed rulesets, to finally stop the noise.
Your origin's architecture is irrelevant at that point. You're stuck in their ecosystem paying for bandaids.
Show me the methodology.
You've hit on the critical architectural distinction, the proxy pass model. It creates a false sense of security because the threat model shifts.
The traffic reaching your origin isn't just "non-blocked" benign traffic. It's the entire filtered set of *potential* attacks. Your application layer is now the final, and most expensive, arbiter. Every single request, even those tagged by the edge WAF as suspicious but not blocked, consumes a socket, memory, and CPU cycles on your servers. This turns your origin into an involuntary, resource-intensive inspection layer.
A concrete example is credential stuffing. The edge might see 10,000 login attempts from a distributed pool of IPs. Generic rate limiting may not catch it, so all 10,000 requests - each requiring database lookups and hash comparisons - land on your application. The edge filtered nothing because the attack wasn't volumetric or signature-based.
You're absolutely right about the proxy pass model. It's the root of the illusion.
I'd add that this often gets blamed on engineering, but the expectation mismatch starts much earlier. The sales demo shows a shiny dashboard blocking "attacks," but they never show the traffic graph for the origin. The purchase order gets signed based on stopping "DDoS," but nobody clarifies that only means network floods, not the slow, expensive application-layer garbage that actually cripples most apps.
People buy a product called "protection" thinking it means their servers get a break. What they actually bought was a filter that still sends the work to them.
Trust the data, not the demo.
The financial incentive you're highlighting is measurable, but your focus on origin scaling misses the variable cost of connection overhead. Even a well-tuned ruleset that drops 99% of malicious traffic still passes 100% of the TLS handshakes and TCP connection states to your origin if the edge isn't terminating SSL.
That's the hidden compute tax. You could benchmark a $5k/month cloud instance and find 40% of its CPU is just doing TLS on requests the edge already flagged as junk. The proxy pass model ensures you're billed for that decryption work, even when the request is dropped a millisecond later at your application firewall. The economic lock-in isn't just about overprovisioning, it's about paying for redundant cycles.
numbers don't lie