Anyone using Barracuda CloudGen in production with AWS? Real world feedback

We ran a proof of concept with their CloudGen WAF in AWS for about six months before decommissioning it. I can directly address your points.

On performance, the latency additive for our internal gRPC services was between 8-12ms under normal load, which was outside our SLO. The GraphQL introspection queries triggered some pathological parsing behavior in their rule set, causing intermittent spikes to 90+ ms. Their "cloud-native" auto scaling did work, but cost predictability was a problem. Our quoted fixed fee ballooned by about 40% in a month with legitimate traffic surges because the scaling metrics (CPU) were too sensitive. You're billed for the peak hourly instance size, not average.

For your tooling questions, the Terraform provider is essentially a wrapper for manual steps. It can deploy the EC2 gateway, but all material WAF policy configuration still happens in their portal. The GitOps story is weak; you can't truly manage a declarative version of the security policy in your repo. Logs can be shipped to an S3 bucket via a built-in feature, and from there you can pipe to Grafana/Loki, but the log schema is verbose and not well documented. The portal alerts are noisy and lack fine grained control.

What broke first under load was the management plane connection for the gateways. During a sustained DDoS simulation, the gateways lost connectivity to Barracuda's cloud control, causing them to freeze policy updates and revert to a last known state. The failure mode was silent, which was the ultimate deal breaker.

The log schema point is spot on. Even after you get them to S3, the event structure is a mess of nested fields with inconsistent naming. We had to write a custom Fluentd parser just to make the logs queryable, which defeated the purpose of a built-in export.

The portal alerts being noisy is an understatement. Expect a flood of "informational" severity items for every rule evaluation. Tuning it to only show actual incidents requires diving into each individual rule logic, which isn't exportable.

Your focus on operational experience is correct. I ran a two-year migration where CloudGen was the incumbent WAF, and we ultimately replaced it. Your specific points on tooling are critical.

> Terraform/CloudFormation support ... is it complete or just a wrapper?

It's a wrapper. The provider manages the initial compute instance, but the core configuration - security policies, routing rules, SSL profiles - resides in their proprietary format within the portal. You cannot achieve a true immutable, Git-managed deployment state. Our ArgoCD workflow hit a wall because any portal-admin change created configuration drift the IaC couldn't reconcile. We had to implement a complex, fragile sync script that pulled state from the portal to attempt remediation.

The log integration is functional but labor-intensive. You can ship to an S3 bucket via a built-in connector, but as others noted, the schema is not clean. For Grafana/Loki, you'll be maintaining a custom parsing pipeline indefinitely. The cost scaling issue user1104 mentioned is accurate; monitor the 'Application Delivery Controller' metric group in Cost Explorer, not just the base WAF SKU.

The cost scaling got us too. Their autoscale triggers on a 5 minute CPU average. Any flash traffic, even valid, spins up the biggest instance size for the hour. You pay for that peak for the full sixty minutes, even if the spike lasted three. You have to treat their scaling like it's broken and set the ASG min/max to the same value to get predictable costs, which defeats the purpose.

> Real alerting and monitoring integration. Can you feed logs directly into Grafana/Loki

You can get the logs out via Kinesis Firehose to S3, but you're not wrong to be suspicious. The field naming is a real headache; you'll see `client_ip` in one event and `src_ip` in another for the same data. We built a custom processor to normalize it, but that's extra work and a failure point they don't advertise.

If you're on ArgoCD, the GitOps story is basically non-existent. The core WAF ruleset lives in their portal. We tried to sync it by exporting JSON configs and applying them via a custom tool, but the drift detection was a constant battle. Any hotfix in the portal would blow our Git state away.

You think their logs are a mess? Wait until you try to build a dimensional model from them. We had a field called `attack_severity` that returned integers, strings, and null in the same partition. Good luck getting that into a clean fact table.

And the noise in the portal alerts. Had to write a separate job just to deduplicate and reclassify their "informational" events before they hit PagerDuty. Another layer of fragile glue.

That 8-12ms for gRPC lines up exactly with what we saw on our payment APIs. It forced us to renegotiate SLAs with an internal team, which was a whole thing.

> you're billed for the peak hourly instance size, not average.

This right here. The scaling metrics are so aggressive, you're basically punished for successful traffic. We ended up locking the ASG to a fixed size after the second billing surprise. Makes you wonder who the auto-scaling is really for.

The portal-driven config management was our breaking point, too. Our SREs refused to maintain a "clickops" security layer. If you're already on ArgoCD, that drift problem is a non-starter.

I'm looking at this from the other side, trying to pick a WAF for our first big AWS project. This thread is super helpful but also kind of terrifying? You all are talking about all this drift and billing surprises. Is this just how enterprise WAFs are, or is Barracuda particularly bad at the cloud-native stuff?

If the Terraform is just a wrapper and the real config is stuck in a portal, that seems like a huge red flag for us too. We're a small team and can't babysit config drift. When you say you had to lock the ASG to a fixed size, did that just move the problem? Like, did you then have to manually size for peak traffic anyway and overpay that way instead?

Your points are spot on. I'll give you the raw numbers we measured.

> Performance impact on latency-sensitive APIs
Our gRPC microservice p99 latency increased by 9ms at steady state. Under any load fluctuation, the p99.9 spikes were over 50ms due to TLS renegotiation in their gateway. GraphQL performance was worse; any query with nested fragments triggered their SQLi rule engine, adding 100-200ms overhead per request. We had to build an allowlist for those paths, which weakened the security posture.

On cost, the auto-scaling is financially dangerous. The instances are billed hourly. A 5-minute CPU spike from a valid traffic burst will provision a larger instance for the full hour. Our monthly bill ran 60% over quote until we locked the Auto Scaling Group to a fixed instance family and size.

The Terraform provider only manages the infrastructure shell. All WAF policy configuration is locked in their portal's proprietary JSON format. Our ArgoCD sync attempts failed constantly because the portal state is the source of truth. You can export configs via their API, but the diff is unreadable and applying it back is a manual, stateful operation. It breaks GitOps completely.

What broke first for us was the monitoring. The logs are exportable to S3, but the schema is unusable for programmatic alerting. We had to deploy a dedicated Fluentd transform to normalize the field names before we could pipe to Grafana. You'll spend more time building tooling around CloudGen than managing the WAF itself.

Oh, the log schema isn't just messy, it's strategically ambiguous. That inconsistent naming means you can't write a stable dashboard without baking in their internal, undocumented version changes. You'll be rebuilding your "custom Fluentd parser" quarterly.

And yes, tuning the alert noise requires editing each rule in the portal. The real kicker? There's no API to export the rule logic you just tuned, so you can't even document what you changed. It's a configuration black hole.

Wow, reading the replies here has been a real eye-opener. I'm just starting to look at WAF options too, and the bit about Terraform being just a wrapper is super discouraging. If the core security config is stuck in a portal, it sounds like you can't really escape manual work, which defeats the whole point of IaC for us.

Your question about what breaks first under load is the one I'm most curious about now. For a small team like ours, we couldn't handle constant p99 latency spikes or surprise billing. Did anyone find a way to actually make the auto-scaling predictable, or is locking it down the only real fix?