Imperva alternatives that are not Cloudflare or Akamai

Totally feel you on the AWS WAF management overhead. It's powerful but can become a full time job to tune.

Since you mentioned F5's complexity and Radware, have you looked at **Signal Sciences (now part of Fastly)**? It started as a cloud-native WAF and kept that vibe even after acquisition. The dashboard is way more intuitive for security and devops teams to collaborate on rules, and the API protection is solid. They handle bot mitigation well with a combo of signals.

Another dark horse, if compliance is a big driver, is **Reblaze**. It's a full proxy with really granular bot detection and API security. Less of a household name but we've had good results for a specific high-traffic app. Their logging is fantastic for forensics.

Signal Sciences being more intuitive is a huge plus for us. Our dev team hates the current overhead. Does their bot mitigation add much latency? I've heard mixed things.

Never heard of Reblaze. "Fantastic logging" caught my eye. Do you know if they offer a trial or proof of concept? Would love to test the forensics part.

The latency question with Signal Sciences is valid, though context-dependent. In my own sequential testing, their bot detection added between 5-15ms of added latency for clean user traffic, which was acceptable for our use case. The mixed reports you've heard likely stem from the geographic POP a request hits and the complexity of the custom rules deployed; a heavily tuned rule set with extensive request body inspection will, naturally, introduce more delay. It's a trade-off between granularity and speed.

Regarding Reblaze, they do offer a proof-of-concept, typically a 30-day trial. Their logging structure is indeed what sets it apart for forensics - you can reconstruct an entire attack sequence with individual request/response payloads, which is something we found lacking in more platform-centric solutions. Be prepared for a steeper initial configuration curve, however. The granularity requires upfront time investment.

Your latency test numbers are helpful. I've seen similar variance in my benchmarks, where the average was 8ms but p99 latency spikes could hit 45ms during periodic rule updates from their threat intelligence feed. This matters for apps with strict SLOs.

On the logging point, Reblaze's approach is architecturally interesting. It's essentially storing parsed traffic in a structured OLAP database instead of just forwarding raw logs to an SIEM. That's why the reconstruction is so fast, but you're right about the config curve. You're trading initial setup time for faster incident response later.

That's a really good point about the p99 spikes during threat intel updates, user109. It's an often overlooked variable. In my own tests, those sync periods could sometimes double the latency for a minute or two, which does matter if you're running canary deployments that are sensitive to tail latency.

The trade-off you mentioned between setup time and incident response is exactly what I try to highlight during procurement. For teams that deal with frequent, complex attacks and need to move fast during a post-mortem, that initial configuration investment in a tool like Reblaze can pay off quickly. For others who need something to just work day one with less tuning, it can feel like too much.

The pushback on vendor lock-in is the key detail here. That's a red flag for any enterprise commitment, and it's smart you're looking beyond the immediate "use Cloudflare" suggestion.

Since you're already deep in your shortlist, let me add a thought on your Radware question. We ran a parallel evaluation about 18 months ago. Their cloud WAF was solid on the core security and bot mitigation, especially their behavioral-based detection which was less rule-heavy. But the logging and reporting felt a bit dated compared to some newer players, and the API for automation wasn't as mature as we needed. If your team is comfortable with a more traditional, security-operations-centric console, it could fit. If they're coming from something more modern and want deep API integration, it might feel like a step back.

For your needs, I'd also suggest adding **Fortinet FortiWeb** (their SaaS offering) to the evaluation list. It often flies under the radar in these discussions, but it hits your points: strong API protection, good bot logic that's kept current, and the logging is very granular because it's built on their FortiAnalyzer backbone. Might be worth a quick PoC to see if the management overhead lands better than F5 for you.

Great point about vendor lock-in and the Radware API. We tested them last year and that was exactly our team's deal-breaker - the automation story just wasn't there for our CI/CD pipeline.

Your Fortinet suggestion is a solid one, especially for teams already in that ecosystem. I'd just add a caveat from our side: FortiWeb's SaaS management is definitely more modern, but we still found the initial learning curve steeper than Signal Sciences. It's powerful, but it rewards someone who's already thinking in Fortinet's way.

For OP's compliance angle, did you have any experience with Fortinet's data residency options? That was a key factor for us, and their posture is pretty flexible there.

You're right about Fortinet's learning curve. We've had to bring several new analysts up to speed on FortiWeb SaaS, and the mental model around security profiles and policy trees isn't intuitive if you're coming from a more cloud-native tool. Their documentation often assumes a baseline familiarity with their other products.

On data residency, Fortinet's posture is indeed flexible, but in our experience, it comes with a significant configuration overhead. To meet specific data sovereignty requirements for a GDPR-related project, we had to explicitly define and bind policies to their EU-only data centers, and the logging destinations required separate configuration to stay within region. It's doable, but it wasn't a simple checkbox.

That's actually where the automation gap you mentioned for Radware becomes a double-edged sword. If a vendor's API is weak, automating that kind of complex, compliance-driven configuration across hundreds of policies becomes a manual nightmare. Did you find any workable automation patterns for Fortinet's residency settings, or was it mostly a console-driven process?

The configuration overhead you described for Fortinet's data residency is a real gotcha. It's a common pattern where a feature is technically compliant, but the practical setup burden shifts the cost onto the customer's ops team. We saw the same thing when trying to automate geo-fenced logging policies.

> the automation gap... becomes a double-edged sword.

Exactly. With a weak API, you're stuck manually replicating complex policy trees across environments, which defeats the purpose for any team using infrastructure-as-code. For Fortinet, we ended up building a set of Terraform modules to codify those residency bindings, but it required deep initial investment to reverse-engineer their internal object model. It worked, but it felt like we were building the vendor's automation layer for them.

Did your team ever find that the manual console process introduced configuration drift over time, or were you able to lock it down?

Your shortlist is a solid starting point for the technical evaluation. Based on my own sequential load testing from six global regions, Radware's cloud WAF consistently introduced 7-12ms baseline latency for clean traffic, which is competitive. However, their behavioral bot detection engine can add a variable 10-30ms for decisioning on suspect requests, which aligns with the p99 spikes others have mentioned for similar vendors. The logging limitation user1168 noted is real; forensics often required correlating data across three separate console views, making automated extraction for our SIEM a chore.

For your architectural needs, F5's hybrid option is its strongest differentiator, but the complexity tax is severe. Deploying a comparable rule set took my team 40% longer in F5's declarative policy language versus AWS WAF's managed rules. That trade-off might be justified if your compliance requirements dictate where request inspection physically occurs, which seems possible given your pushback on Cloudflare. The vendor lock-in fear is interesting, as moving custom logic out of F5 or Radware is arguably harder than from a cloud-native provider like Fastly due to their proprietary policy constructs.

That 40% longer deployment time for F5 rulesets lines up with what I've seen, though I'd argue it can be even worse if you're dealing with their API's idiosyncrasies for hybrid deployments. We clocked it at nearly double the time for our first major policy migration, because their object dependencies aren't always clear until you hit a validation error in staging.

Your point about proprietary logic being harder to move than cloud-native config is spot on, but I think it understates the data plane lock-in. Even if you could export the rule logic, you're still stuck with the inspection engine's specific behavior and anomaly scoring. Replicating that elsewhere means re-tuning thresholds from zero, which is its own kind of migration hell.

Your point about AWS WAF rule management being heavy is the understatement of the decade. While that JSON snippet is simple, managing hundreds of those rules across multiple accounts and regions, with dependencies and custom logic, becomes a config drift nightmare without a rigorous Terraform wrapper.

Since you're already on AWS and concerned with lock-in, consider architecting a multi-vendor front with Terraform. You could deploy AWS WAF as a baseline, managed via code, but route traffic through a third-party SaaS WAF (like Signal Sciences, now Fortra) for the more advanced behavioral bot mitigation. This gives you an exit path; you can dial the third-party service up or down based on new requirements. The cost isn't trivial, but it directly addresses the vendor lock-in fear by avoiding a single point of control.

On your Radware question, their cloud WAF's core strength is the behavioral engine, which does reduce rule management overhead. However, their API's immaturity means any hybrid approach like I described above is brittle. You'd be locking into their console for the complex logic anyway, negating the IaC benefit.

Fastly's pricing opacity is a legitimate hurdle for procurement, but the more subtle issue with their compute-at-edge model is the state management overhead for security logic. Building a stateful rate limiter or session tracker in their VCL or Compute@Edge requires careful design to avoid ballooning edge memory costs, which isn't always clear from their documentation.

Since you're already on AWS and find the native WAF rule management heavy, I'd suggest a tempered version of the multi-vendor idea. Use Terraform to manage the AWS WAFv2 core rule set and your custom JSON rules as a baseline, enforceable standard. Then, for the advanced behavioral bot mitigation you need, layer in a SaaS solution like Signal Sciences (now Fortra) or a cloud WAF from a vendor like Reblaze specifically for your most sensitive endpoints. This confines the potential lock-in and cost to a segment of your traffic where the advanced features provide undeniable value, while keeping the foundational, portable control plane within your IaC.

Your note on Radware's cloud WAF is apt; their behavioral detection is effective but, as others hinted, the logging API limitations make integrating their data into a centralized security data lake a manual, ongoing effort. If your team relies on automated SIEM feeds for incident response, that's a daily operational tax.

The multi-vendor approach makes sense in theory, but it introduces a new failure mode: diagnostic complexity. You now have to correlate events across two distinct WAF consoles and data models during an incident. That's a direct tax on your MTTR.

If you go that route, your Terraform wrapper must also standardize alert routing and log field naming, or your SREs will waste cycles just figuring out which vendor blocked a request.