We just started using Imperva's DDoS protection for our web app on AWS. Our team is small and I'm still learning, so maybe I'm missing something obvious 😅
Our problem: The mitigation threshold seems way too high. Our normal traffic is maybe 50 Mbps, but the system only kicks in after 2 Gbps. Last week we had a smaller attack (around 800 Mbps) and the site went down because Imperva didn't trigger. Our upstream provider overwhelmed.
Is this threshold configurable? I can't find a clear setting in the dashboard. Our config is mostly via their Terraform provider, but the docs are huge. Has anyone else dealt with this? I just need a lower trigger, like 200 Mbps.
Here's the basic Terraform I found for the network policy:
```hcl
resource "imperva_network_rule" "ddos_mitigation" {
name = "default_mitigation"
action = "alert_and_mitigate"
ddos_traffic_threshold = 2000 # This is in Mbps, right?
}
```
Is that `ddos_traffic_threshold` the setting? If I change it to 200, will it actually start mitigating sooner? I don't want to break things.
Yeah, that's the setting. Change it to 200.
But the real issue is your upstream provider getting overwhelmed at 800 Mbps. That's a tiny pipe by today's standards. You're paying for DDoS protection but your actual infra can't handle a spike to 1 Gbps? The cost-inefficient part is your bandwidth commit, not the Imperva config.
Get a bigger commit from your provider or move to a cloud with elastic bandwidth. Your DDoS threshold is pointless if your own network fails first.
show the math
Yeah, that's almost certainly the right setting. Changing `ddos_traffic_threshold` from 2000 to 200 should make it kick in much sooner, since that's well above your normal 50 Mbps but below where your upstream fails.
Before you apply it in Terraform, I'd double-check the units in their docs. I've seen some vendors use Mbps and others use something else like packets per second in similar fields, and getting that wrong would be bad. Maybe run a `terraform plan` first to see if it flags the change as a unit conversion?
Also, you might want to set up a low threshold alert first, just to be sure it triggers correctly without causing any unintended blocks on a real traffic surge.
Yeah, that looks like the setting to me. I'd be paranoid about the units too, though. Their docs are a maze.
Changing it to 200 Mbps makes sense for your normal traffic. But like user400 said, what happens when a real attack hits 201 Mbps and triggers? Won't your upstream still get overwhelmed if the mitigation isn't instant? Or does it redirect traffic first?
Yeah, that's the setting. I had the same confusion starting out. I'd change it to 200 like others said.
But a quick thing to check - in their dashboard, sometimes the threshold setting is in a different place under "network protections" or "rate rules". Could be why it's hard to find. Making the change in Terraform should work, but maybe verify it shows up correctly in the UI after you apply it.
Also, good point asking if it's in Mbps. I assumed it was, but their support told me once that for some plans the number is actually a "score" not raw Mbps. Might be worth a ticket to confirm before you rely on it.
Your upstream failing at 800 Mbps is the real cost problem. DDoS mitigation isn't instant - traffic has to be diverted and scrubbed. That takes seconds, maybe minutes. If your pipe tops out at 1 Gbps, a 201 Mbps attack will still saturate it before Imperva even blinks.
Scaling your bandwidth commit is cheaper than you think. I run 10 Gbps commits on AWS for less than your current DDoS service probably costs. You're paying for a guard dog but leaving your gate made of cardboard.
Fix the bandwidth first, *then* tweak the threshold. Otherwise you're just moving the failure point.
show the math
That's a valid point about the upstream capacity being a bottleneck, but I think it's a bit dismissive of the threshold issue. Even with a bigger pipe, letting 800 Mbps of attack traffic hit your origin before mitigation kicks in isn't ideal. The goal is to trigger the scrubbing before your infrastructure has to absorb the hit, regardless of its capacity.
While scaling bandwidth is part of the solution, getting the detection threshold right is still a crucial first step. You want the protection to engage as early as possible within your normal traffic envelope.
—daniel
Exactly. The detection latency is the real killer. Even with a perfect 200 Mbps threshold, there's still that window where malicious packets are hitting your origin while the system decides to divert.
It's like a data pipeline backpressure problem. You can set your alert threshold low, but if your processing topology can't shed load fast enough, you still get latency spikes. In this case, the mitigation *becoming active* has its own lag.
Maybe the right question is: what's the actual TTL between threshold breach and full redirection? If that's 30+ seconds, you might need an even lower threshold just to buy time.
Yes, that's the setting. Change it to 200.
But your whole approach is wrong. You're adding complexity (a third-party DDoS layer) before fixing the basic capacity problem. Your upstream fails at 800 Mbps. That's your real issue.
Skip the Terraform. Call your provider and get a bigger pipe first. Then decide if you even need this extra service.
Simplicity is the ultimate sophistication
I understand the "fix the fundamentals first" mindset, but I think you're conflating two separate problems. The capacity issue is a business cost decision - commit to more bandwidth and pay for it. The threshold issue is an operational one that's causing immediate, repeated outages.
Even with a 10 Gbps pipe, letting 1.9 Gbps of attack traffic hit your origin because your threshold is set at 2000 Mbps is still a failure mode. It wastes the DDoS service you're already paying for. You can, and should, address both the commit and the config simultaneously.
The complexity argument is fair, but tweaking a Terraform variable is a trivial fix compared to renegotiating a provider contract, which could take weeks. Doing the quick config change now stops the bleeding while they work on the capacity problem.
Every dollar counts.
Good point about the "score" vs Mbps, I've been bitten by that before. The vendor's API accepted a raw integer, but their backend was applying some proprietary weighting algorithm to traffic. We set what we thought was 500 Mbps and got mitigation at like 80 Mbps of "scored" traffic 😅
A quick ticket to support is definitely worth it. In the meantime, you could also check your traffic logs from a past normal peak. If their dashboard shows a "mitigation score" metric alongside raw bps, you could correlate to find a safe threshold number.
Clean code is not an option, it's a sanity measure.
Oh man, the "score" thing is so real. We had a similar gotcha with a different provider where the number in the portal was actually a "mitigation unit" based on packet rate and size, not raw bandwidth. Took a support call to decode it.
> you could also check your traffic logs from a past normal peak
This is the best move while you wait for support. Plot your normal max traffic against their "mitigation activity" log. The delta between when your graph spikes and when their mitigation log entry appears is your real threshold window. Might be pretty eye-opening.
Self-host or die trying.
Exactly. This opaque "score" system is how they sell you on cheap plans, then upsell you when your "score" triggers too early. You're basically buying a random number generator instead of protection.
Plotting your own logs is smart, but it assumes their logs aren't also fudged. I've seen providers where the "mitigation activity" timestamp lags the actual traffic by design, to hide their reaction time. Good luck proving it.
Prove it