I've been looking into Radware for our web app protection and DDoS mitigation. The pricing structure seems complex with all the add-ons and traffic tiers.
I built a basic spreadsheet to estimate our quarterly costs based on projected bandwidth and the features we'd need. I used the public pricing sheets as a starting point. Has anyone else tried to model their spend before committing? I'm worried about hidden costs or usage spikes blowing the budget. Are my main cost drivers going to be bandwidth consumed, number of protected applications, or the specific security modules?
Your spreadsheet is a good start, but the public sheets are usually missing the real gotchas.
For Radware, the big three are typically:
* Committed bandwidth minimums you'll pay for even if you dip under.
* Costs per "security policy" applied, not just per app.
* Burst pricing during an actual DDoS attack. Your "usage spike" fear is spot on.
Did your model include their professional services fees for setup? That's a common quarterly budget killer right out of the gate.
always ask for a multi-year discount
Ah, the old "public pricing sheet as a starting point" maneuver. A classic path to budgetary heartbreak. While everyone's fixating on the modules and bandwidth tiers, they're missing the real puppet masters pulling the strings on your final invoice.
Your main cost drivers? Try the annual support uplift that auto-renews at a higher percentage than you'd think, and the fee for any configuration change you need their "certified engineer" to make after the first 30 days. The bandwidth and apps are just the cover charge to get into the club.
You're worried about usage spikes blowing the budget? That's cute. The real spike is when you need to turn on a feature you thought was included in "core protection" and it triggers a whole new SKU. Your spreadsheet has a lovely cell for "projected bandwidth," but does it have a cell for "quarterly true-up reconciliation surprise"? Didn't think so.
Price ≠ value.
Building a spreadsheet is a smart first step. I used a similar approach, but I'd suggest adding a column for "support hours" or "change requests."
My model found the biggest variable wasn't the base bandwidth or modules, but how often we needed to tweak policies or request reports. That "per-security-policy" cost user95 mentioned can balloon if you're managing lots of rules per app, not just the app count itself.
Do you have a column for post-attack analysis fees? That's the hidden spike that got us once.
That's a great point about the "support hours" column. We got burned by that, too. A simple policy review turned into a three-hour consultation billed at their "emergency" rate because it was outside our prepaid block.
The post-attack analysis fee is brutal. You're already stressed from the attack, then the invoice hits and it's another five figures for the report. Feels like getting charged for the ambulance ride after the car crash.