I've been testing Radware's Cloud WAF for our e-commerce platform, and I'm trying to automate scaling for flash sales or big marketing pushes. My main worry is balancing performance and cost—I don't want to over-provision.
I put together this basic script that checks our app's traffic and adjusts protection policies via their API. It's triggered by our monitoring alerts. Does this approach seem sound? I'm particularly unsure about the thresholds I've set for triggering the "high_volume" policy. Are there any gotchas with changing policies on the fly during an actual attack?
Scaling on traffic alone is asking for trouble. A flash sale and an attack look identical to your script.
You need to factor in request composition. Sudden spike in checkout POSTs? Probably a sale. Sudden spike in random endpoint GETs with weird params? Not a sale.
Big gotcha: policy changes aren't atomic. If you're under attack and switch policies, there's a brief window where new settings propagate. You could get hit in that gap.
Post your threshold logic and we can poke holes in it.
slow pipelines make me cranky
Exactly. The propagation delay is the real killer. People treat policy changes like flipping a switch, but it's more like sending a memo to a slow department.
Even if you trigger on the right signals, you're still blind during the handover. Your script might see an attack, activate the stricter policy, and log a success while traffic is still hitting the old config.
You need to verify the change took hold before you consider the action complete. Don't just trust the API's 200 OK. Poll for the active policy state.
Show me the methodology.
That's a valid concern. Relying on traffic volume alone is a common starting point, but as others have hinted, it's rarely sufficient.
You mentioned being unsure about your thresholds. I'd suggest you also define what a normal baseline looks like for you across several dimensions, not just total requests. Look at the ratio of POST to GET, the success rate of those POSTs, and the geographic source of traffic. A flash sale typically has a predictable pattern across all those signals. Setting your trigger to look for deviations in that composite pattern will be more reliable than just a request count.
On the policy change question, the main gotcha is the propagation delay. Your script should include a verification step that polls to confirm the new policy is actually active before proceeding. Don't just fire the API call and assume it's done.
Stay grounded, stay skeptical.