We recently switched from Aqua Security to Lacework for our container and cloud security. It was a big move for our team, and I'm still getting up to speed.
I'm curious about others' experiences. For us, we gained much better cloud posture management and a single view across AWS accounts. But we lost some granular control over container runtime policies that we had in Aqua. The Lacework API feels more modern, but I'm still figuring out how to replicate some of our old automated workflows.
Still learning.
I'm a cloud security lead at a mid-sized fintech, managing about 120 AWS accounts and a mix of EKS clusters and EC2-hosted containers. We've used both Aqua and Lacework in production over the last three years.
Core comparison based on our migration:
1. **Entrypoint & Ideal Fit**: Aqua is container-native, built for teams securing a software supply chain (registry, CI, runtime). Lacework is cloud-native, built for teams managing complex, multi-account cloud estates. If containers are your whole world, Aqua fits better. If containers are one piece of a sprawling cloud environment, Lacework makes more sense.
2. **Container Runtime Policy Granularity**: This was our biggest loss. Aqua lets you write runtime rules based on specific system calls, mount paths, or user IDs. Lacework's container alerts are largely behavioral (e.g., "unusual process spawned") or based on known threats. For custom, low-level runtime control, Aqua wins. We had to accept a different model.
3. **Agent Overhead & Deployment**: Aqua's agent is heavier, often requiring a DaemonSet plus dedicated scanner deployments. Lacework's single agent (we use the Flexa version) pulls double-duty for host and container, which simplified our node provisioning. Our cluster nodes saw a 10-15% reduction in memory pressure from security agents after the switch.
4. **Posture Management & CSPM**: This is Lacework's clear win. Its compliance mapping and cloud resource assessment are integrated from day one. We went from zero to fixing critical S3 bucket and IAM misconfigurations across all accounts in a week. With Aqua, we'd have needed a separate tool or a lot of custom scripting.
My pick: I'd recommend Lacework if you're securing a multi-cloud or complex AWS environment where cloud posture is a major pain point. I'd stick with Aqua if your primary need is deep, customizable container runtime security and you already have another solution for CSPM. To make a clean call, tell us your team's split between cloud engineering and AppSec expertise, and what your biggest compliance driver is (e.g., SOC2, PCI, or internal policy).
security by default
The API difference is real. We used the Aqua API to tie runtime alerts to auto-scaling events and spot instance termination hooks. Had to rebuild that logic from scratch after our migration.
>lost some granular control over container runtime policies
This is a common tradeoff. You're swapping container-specific controls for the broader cloud context. You'll likely find you don't need most of those ultra-granular rules if Lacework's behavioral baselining is tuned properly.
What's your monthly spend across those AWS accounts now? Lacework's per-account pricing can get steep. Watch your bill if you're scaling accounts.
cost per transaction is the only metric
"Don't need most of those ultra-granular rules" is the standard Lacework line, but I've seen that behavioral baselining miss some very specific, nasty stuff that a good syscall rule would have caught. It's fine until it isn't.
The API rebuild pain is real. Their API is modern, but it's built for their model, not yours. We ended up building more abstraction than we wanted just to map our old event logic onto their new alert taxonomy.
Data over dogma.
Yeah, that behavioral baselining is a double-edged sword. It cut our alert noise by a ton, which is great for the average day. But you're right, it can totally miss those weird, one-off process injections that don't fit a "normal" pattern.
We had to accept that trade-off and just run more targeted scanning jobs as a separate layer for that specific paranoia.
measure twice, ship once