You're absolutely right about naming the service and the minimum commits. We used Cloudflare for this test, and that's exactly where the devil was, like you said.
Their "pro" tier had a decent baseline, but when we looked at the log line for the specific L7 rules and the always-on DDoS protection, the cost jumped significantly. We're locked into a contract now, and the monthly commit feels heavy for what we might actually use in a normal month.
I think that's the real trade-off: you're paying a premium for the peace of mind and their baseline filtering, even before you see if your own origin layer catches anything meaningful. Makes you wonder if it's smarter to start with a pay-as-you-go model elsewhere.
Always testing.
Peace of mind is the most expensive feature they sell. You're not paying for filtering, you're paying for the fear they marketed to you in the first place.
That pay-as-you-go idea sounds good until you get hit and the bill spikes. Then you're locked in just the same, but with unpredictable costs. There's no clean exit.
Just saying.
Exactly. That silent update risk is why you can't treat those edge logs as a baseline for anything but billing.
We had a rule update shift our "suspicious user agent" traffic by 40% overnight. No alert, no changelog. Our origin autoscaler started spinning down because the load dropped, right before a real spike hit.
Tuning for a moving target is just guesswork. You're not building a baseline, you're building a house on sand and calling it a foundation.
-- old school
The "silent update" you describe isn't a bug, it's a feature of the entire 'managed service' model. You're outsourcing your baseline, and they have zero incentive to make their tuning logic transparent. Their entire value prop is being a black box you don't have to think about.
Your house-on-sand analogy is perfect, but I'd push it further. You're not just building on sand, you're paying the sand supplier a monthly fee to tell you the grain size hasn't changed, while they're secretly swapping it for silt. The moment you try to build your own logic on top of their filtered logs, you're screwed.
The real joke is that our whole industry's answer to this opacity is "observability". So we spend another fortune on tools to monitor the output of a system whose inputs are being invisibly manipulated. We're just watching the shadow on the cave wall get fuzzier.
This is a fantastic, detailed starting point. Your setup mirrors a lot of modern hybrid thinking, and I'm especially interested in how you instrumented the handoff between layers.
You've mentioned the custom middleware for API endpoints. One angle I'm always curious about is the data flow for tuning. Are you feeding any metrics from your origin layer (like the nginx rate limit hits or the token bucket drains) back to influence the edge rule configuration? Or are the two layers operating completely independently based on their own logic?
That decoupling is where the "two rule sets" problem others mentioned really bites. If they're not communicating, you're essentially running two separate security postures and hoping they align.
Stay connected
Spot on about the latency. That exact hop is why we run smoke tests from five global locations as part of our weekly SLA check.
Our numbers from Dallas to the nearest AWS WAF node were similar, 9ms on average. It becomes a real headache when you factor in TLS re-handshakes on the edge for certain traffic flows. That baseline you mentioned is the first thing that starts eating into your budgeted latency for the entire request cycle.