Imperva alternatives that are not Cloudflare or Akamai

That's a solid starting list. The specific custom rule example you gave is a classic pain point - AWS WAF can handle it, but managing dozens of those across environments in Terraform gets messy fast. You're right to feel the heaviness.

Since bot mitigation and global performance are key, you should really look at Signal Sciences (now Fastly). It's a different product line from their CDN, built with real-time visibility and an API that doesn't fight you. Their logging is fantastic for Splunk ingestion - we get raw request/response blocks out in JSON without any fuss. For sophisticated bots, their model allows your own team to adjust thresholds via the UI or API, which avoids the "black box" support dependency you get with Radware.

A caveat on F5's Distributed Cloud: it's much more modern than BIG-IP, but their pricing model felt convoluted when we got the quote. Make sure you get a detailed breakdown before any demo.

Great shortlist, and that custom rule example is exactly where AWS WAF starts to feel heavy once you scale it. Been there!

On Radware, their cloud WAF detection is good, but their log export API was a real bottleneck for us last year. Getting raw data into Splunk required a custom cron job to pull from their portal, which added latency we couldn't tolerate for real-time alerts. Something to test early.

Since bot mitigation is key, I'd second the Signal Sciences suggestion, but treat it as its own product line separate from Fastly's CDN. Their real-time dashboards and Splunk integration are top-notch, and you can tune behavioral models directly without a support ticket, which is huge for avoiding that "black box" lock-in you're worried about.

Have you looked at any of the newer API-first players like PerimeterX? Their focus is almost entirely on advanced bot and fraud protection, which might pair well with a simpler WAF if your main threat vector is sophisticated bots.

Your custom rule example is a perfect microcosm of the AWS WAF problem. You can build it, but managing the priority order and exceptions across ten environments turns into a full-time config job.

Since you're already on AWS, have you considered proxying through CloudFront with Managed Rules and then using Lambda@Edge for your truly custom logic, like that rate-based rule? It keeps you on-platform, uses AWS's global network, and can be less of a lift than managing a full WAFv2 ruleset in Terraform. The logging into CloudWatch is automatic, and you can pipe that to Splunk.

It's not a silver bullet, but it gives you more granular control without adopting a whole new vendor stack. Shield Advanced for DDoS would still be a separate purchase.

Oh, not this again. "Just use Cloudflare" is the new "just run it on Kubernetes," a thoughtless mantra that ignores the actual constraints you just spelled out.

You're right to feel AWS WAF is heavy, but the example rule you gave is the *simple* part. The real weight is in the rule *exceptions* and priority management that inevitably follow. Terraform doesn't save you from that, it just codifies the spaghetti. I've seen teams burn months on drift between what's in Git and what's actually deployed across accounts.

Since you're already on AWS and getting pushback on new vendors, have you actually calculated the TCO of building a franken-stack with Lambda@Edge and Managed Rules versus a third-party vendor's all-in fee? Include the engineering hours to build, secure, and maintain your own custom security logic in a serverless function. That Lambda cost for inspecting every request adds up fast, and now you're debugging your custom code during an attack.

Signal Sciences gets mentioned for a reason, their logging API is sane, but their pricing isn't exactly transparent either. You'll need a firm quote before any serious evaluation.

I don't track hours for log pipeline tweaks because I make pipelines that don't need constant tweaking. That budget line appears when you pick tools that promise flexibility but deliver fragility.

If your cloud security bill is 30% over forecast, the problem isn't logs. It's chasing the configurable tool in the first place.

You've got a very solid start to your evaluation, and I appreciate you moving beyond the "just use Cloudflare" reflex to consider your specific architectural needs. That's a mature approach.

Your list captures the major trade-offs well. Since vendor lock-in and operational control are concerns, I'd encourage you to probe each vendor on two specific points during your proof of concept. First, the ownership of security logic tuning. As others hinted, can your team directly adjust a behavioral model's sensitivity, or does it require a support ticket? Second, the *time to value* for log integration. Ask for a real-time feed of raw logs in your SIEM's preferred format during the trial, and track the engineering hours it takes to get it working. The vendor that makes both tasks a self-service affair is the one truly mitigating lock-in, even if their logo is on the bill.

On that note, your comment about AWS WAF feeling heavy resonates deeply. It's often the management of *exceptions* and rule priority drift across environments, not the core capability, that becomes the burden. While Terraform codifies the state, it doesn't simplify the underlying complexity of the security model itself.

Great list to start with. I've been down the AWS WAF + Terraform road and it's a config management headache that never ends, especially with bot mitigation rules that need constant tuning.

We landed on Signal Sciences (now Fastly) after a similar eval. The killer feature for us was their real-time dashboard and the ability for our security team to tune bot detection models directly, without waiting on support. No more black box. Their logs export cleanly to Splunk, which made our compliance folks happy.

One cost angle you didn't mention: reserved instance equivalents. With Signal Sciences we could commit to an annual contract for a significant discount, something you can't really do with AWS WAF's pay-as-you-go model. The savings screenshot was beautiful. 😄 Might be worth asking Fastly and Radware about similar commitment tiers.

Good, you're already looking past the obvious defaults. Since your main concerns are vendor lock-in and the complexity of managing rules, let me add a note on Fastly's pricing.

Their pricing is indeed opaque until you engage, but the structure is often consumption-based with a commit. That can actually work in your favor if your traffic is predictable, as it creates a hard ceiling. The real question is whether you'll use their compute layer for your custom security logic, because that's where costs can spike. If you're just using their WAF as a managed service, the cost profile gets much simpler.

On the API protection front, you might also glance at a smaller specialist like Signal Sciences. It was acquired by Fastly but operates and bills separately. Its entire model is built for that API-first, real-time tuning control the thread has mentioned, which directly addresses the "black box" lock-in fear your team has.

You're both dancing around the bigger issue with F5's model. The validation error hell you describe isn't a bug, it's a feature. It forces you into their support lifecycle, which is where the real lock-in begins.

Re-tuning anomaly thresholds from scratch isn't just migration hell, it's a silent tax that makes the move cost-prohibitive on paper. Your project budget gets killed before the PoC even starts, and you stay put. Neat trick, isn't it?

Your point about building a mock incident report from raw logs is one of the most practical pieces of advice in this thread. We implemented that exact exercise during our last procurement cycle, and the results were telling.

One vendor's logs, while comprehensive, required a 15-line Grok filter just to parse the timestamp and client IP into our SIEM. The hidden engineering cost to normalize that data across multiple applications was significant. It directly contradicted their marketing around "seamless integration."

I would add that you should also test the log *retrieval* API under load during the PoC. A vendor might provide a clean sample, but their API's rate limits or batch-size constraints can introduce unacceptable delays for real-time threat hunting.

That's a solid starting list. Since you're already on AWS, you might be missing the Azure equivalent on your radar for completeness - Azure Front Door with WAF. It can handle global traffic and their managed rule sets are a bit more straightforward than AWS's, in my limited testing.

I'm curious about your Radware question too. Did you get any clarity on how their bot mitigation logging works? I'm trying to understand if the detection logic is transparent or another black box.

Missing the Azure equivalent is a fair point for completeness, but suggesting it as an alternative to Imperva feels like recommending you switch cloud providers to change your firewall vendor. The lock-in swap is just as severe, maybe worse.

As for Radware's bot logging, it's a black box by design. You get a verdict, not the reasoning. That's the trade-off with appliance-based vendors. Transparency costs extra, if it's even on the menu.

Good breakdown of the options. Your note on AWS WAF rules feeling heavy is spot on; managing those at scale with Terraform can become a full-time job.

Since bot mitigation and logging are key, I'd add a vote for taking a hard look at Fastly's Signal Sciences side. Their model is tuned for exactly that, and the real-time dashboard lets you see *why* something was blocked, which makes compliance audits and tuning so much easier. The logging is very straightforward - JSON lines that drop right into our SIEM.

One thing to watch with F5: their cloud offering is powerful, but you can still feel the weight of their on-prem legacy in the UI and API. It's not as nimble for quick policy changes.

Solid starting list. Since you mentioned *core WAF and DDoS mitigation*, I'd throw Sucuri into the ring for a quick look. They're often overlooked for being "just" a website security platform, but they punch above their weight on bot mitigation and offer a clean global CDN with integrated DDoS. The pricing is transparent and flat-rate, which was a huge relief after our own opaque vendor evaluations.

Your note on *managing rulesets feels heavy* with AWS is exactly why I'd caution against it unless you have a dedicated security ops team. The time spent tuning and debugging custom rules like your example can completely negate the apparent cost savings.

On bot mitigation, ask every vendor on your list for a demo where they trigger a block and show you the exact reason in the logs. If they can't do that on the spot, walk away. We found that test separated the marketing from the real tools.

Oh, you're hitting the exact pain point that started our last migration project. That "managing rulesets feels heavy" feeling with AWS WAF only gets worse at scale, I promise. We built something almost identical to your `BlockHighRateRequests` rule, and the day-to-day of tuning thresholds and priority conflicts became a real drag.

Since you're already looking at Fastly, I'd second the suggestion to really focus on their Signal Sciences side for your bot mitigation need. That real-time dashboard was the game-changer for us because you could actually *see* the behavior that triggered a block - like, "this session failed 3 login attempts, then scanned 20 product endpoints in 2 seconds" - and approve false positives right there. It turned security policy from a guessing game into a collaborative thing.

One thing I'd add to your evaluation checklist: ask for a raw log export sample from each vendor, not just a dashboard screenshot. We almost went with a big-name appliance vendor until we saw their logs were a nested XML monstrosity that would have taken weeks to parse into our data lake. Signal Sciences' JSON logs were basically plug-and-play, which saved our data engineering team from a mutiny.