Anyone using Imperva for API gateway functionality?

Totally with you on the cost math. That premium is real.

One angle I've seen it pencil out for is teams already deep in their ecosystem for DDoS and bot protection on the web side. If you're already paying for it and the API volume is low, using their "gateway" features can be a stopgap that avoids managing another vendor. But like you said, it breaks down fast at scale or with complex routing needs.

Your point about scripting workarounds hits home - we tried to get custom response transforms happening and it was basically a hackathon to replicate what Kong does with a plugin.

That "stopgap" scenario you described is the only valid use case I've ever seen. Even then, you need strict guardrails.

Teams treat it as a permanent solution and then hit a wall. I've had to migrate two services off it after they outgrew the basic features. The migration cost alone erased the "convenience" savings.

If you go that route, document the exit criteria from day one. Something like "if we need more than three custom response mappings, we reassess." Otherwise the technical debt accrues silently.

Your point about migration costs erasing convenience savings is critical. I've quantified this in two scenarios where teams used Imperva as a gateway placeholder.

In the first, the exit was triggered by a need for custom authentication plugins. The migration to a dedicated gateway took six weeks of developer time, plus three months of parallel run for validation. The total cost exceeded the annual Imperva subscription they were trying to "save." The second team hit a performance ceiling with complex request body validation at scale; the latency introduced by the workarounds became untenable.

Your proposed guardrails, like the "three custom response mappings" rule, are sensible, but I'd add a performance baseline as a non-negotiable criterion. Document something like "if p95 latency for any endpoint increases by >100ms due to a gateway workaround, we trigger the migration." This captures the often-overlooked operational tax of those scripting hacks.

Your cost breakdown aligns with the data from three migrations I've analyzed. One nuance in that math is the operational overhead you've implied with the open-source option. While the raw compute for Kong OSS is $400, you need to factor in at least 0.2 FTE for platform management, patching, and HA configuration, which can close that gap significantly depending on your team's composition.

The more critical point is the "premium for features you might not need." I'd refine that: you're paying a premium for a *specific architectural pattern*. Imperva's model is perimeter defense. If your API strategy is evolving toward distributed, internal API gateways per service cluster, or you're adopting gRPC/WebSocket, that perimeter model becomes an active hindrance. The cost isn't just subscription fees, it's architectural lock-in.

Your "scripting workarounds" observation is the operational symptom of that. When you need to inject a custom header based on a complex JWT claim, or implement a lightweight request aggregation, you're forced to treat the WAF as a compute layer, which it was never designed for.

Spot on about the operational overhead for OSS. That 0.2 FTE figure is conservative in my experience - it's closer to 0.5 if you're building in proper CI/CD, secret management, and a developer portal.

Your point about paying for a perimeter defense pattern is the real takeaway. It's a design choice disguised as a feature list. I've seen teams struggle when they started decomposing their monolith and needed service-to-service API management internally; that perimeter gateway just can't adapt to east-west traffic.

That "document the exit criteria from day one" point is huge. Makes me think about onboarding - is that kind of rule something you'd put in a team's initial project docs, or is it more of an architectural decision logged elsewhere?

I can see teams missing it if it's not in the same place as the other setup checklists.

Your cost math is a good start, but you're missing the real hidden cost: the lock-in. With AWS Gateway or Kong, you at least own the configs and can automate changes. With Imperva's "gateway," you're often stuck in a UI or waiting on support tickets to adjust routing logic.

I've seen that "scripting workarounds" phase turn into a permanent, unmaintainable shadow layer because the alternative was a six-figure professional services engagement to get a feature that's standard elsewhere. So the premium isn't just for unneeded features, it's for the privilege of moving slower.

That's the worst part, isn't it? The slower velocity. You can budget for a known subscription fee, but you can't quantify the opportunity cost of a delayed feature launch because you're stuck in a support queue to modify a route.

I'd add that the "lock-in" extends to your own team's knowledge. You end up with a specialist who knows all the workarounds for the UI's quirks. If they leave, you're not just losing tribal knowledge about your own APIs, you're losing the only person who knows how to navigate the vendor's system. That's a single point of failure you don't have with a config-as-code approach.

The lock-in cost is operational resilience. I've seen audit fail because changes couldn't be traced to a ticket system. You can't prove who changed what or when if it's done through a support call. That alone kills it for regulated workloads.

Your point about the six-figure services engagement to get standard features is the killer. It transforms a capex decision into an unpredictable opex black hole. Budgets can't absorb that.

Okay, that math is actually super helpful to see broken down. The 300-1000% premium is wild.

But where does that DDoS threat model line get drawn? Like, if you're already behind Cloudflare or Akamai for your web assets, doesn't that mostly cover it? Or is there something specific about API-layer DDoS that makes Imperva's mitigation different? Genuinely trying to understand the "unless" part of your last point.