Hi everyone. I just wrapped up a 30-day proof of concept with Lacework for our cloud infrastructure, and I have to say I'm pretty disappointed. The security insights were actually quite good, but the cost structure around data ingestion has me completely spooked about moving this to production.
Our setup isn't even that large—a mix of AWS services (EC2, S3, RDS) and a Kubernetes cluster. We configured the agent and the cloud integration as per their docs. The alerting and the Polygraph features were impressive, I won't lie. But when we got the preliminary cost estimate for ongoing usage, my team lead's face just went white.
The deal-breaker is how they charge for data analyzed. It seems like every API call, every configuration check, every network flow log is a discrete unit that adds up. We have a pretty event-driven, serverless component, and the volume during our testing period suggests our bill would be several times what we initially budgeted for a security tool. It feels unpredictable, and as the person who might have to help build pipelines for this data later, that's a huge red flag.
I'm curious if others have hit this wall. Specifically:
- Did you find ways to filter or sample data *before* it gets to Lacework to control costs, or is that against the grain of how it's supposed to work?
- For those who proceeded, did the billing stabilize or become more predictable, or was it always a scramble?
I'm nervous about signing off on something that could have variable costs that scale directly with our own data/event volume, especially if we have an incident and everything gets noisy. It feels like we'd be incentivized to turn things *off* when we need them most. Maybe we misconfigured something? Any insights from teams who've been through this would be really helpful.
Ah, that "face just went white" moment is such a gut punch, isn't it? We had a similar experience after a POC with a different platform, where the sticker shock from data events was the main blocker.
Your point about an event-driven, serverless environment is key. That architecture inherently generates a massive volume of discrete events, and when a tool charges per unit, it's like a perfect storm for cost overruns. The predictability just vanishes.
In our case, we found we had to get extremely surgical with our ingestion filters before even considering production. It meant accepting gaps in coverage for non-critical resources. Have you looked at whether you can significantly dial back the data sources fed into Lacework, maybe by excluding entire AWS accounts or namespaces for your dev/test environments? It's a trade-off, but sometimes it's the only path forward.
Stay connected