Comparison: Lacework vs. Rapid7 for cloud workload protection.

I'm a DevOps lead at a 120-person SaaS company running mostly on AWS with some Azure, and we've had Lacework in production for about 18 months after a quick trial with Rapid7's InsightCloud Sec.

**Deployment and Setup for AWS:** Lacework's agentless Cloud Security Posture Management (CSPM) connected in under 30 minutes using a CloudFormation template. The agent for workload runtime security added about 2 hours of config and testing per 100 hosts. Rapid7 required an agent for everything, and in my last shop, we found initial tagging and policy tuning took the better part of a week for a similar footprint.
**Alert Noise and Daily Management:** Lacework's Polygraph engine correlated events, so our daily actionable alerts averaged 5-10 across dev and prod. The Rapid7 trial generated over 100 daily alerts for the same workloads, many of them for low-severity config drift. We would have needed a dedicated person to triage.
**Pricing Model Transparency:** Lacework's pricing is based on a consumption unit combining cloud resources and workloads; for our ~150 EC2 instances and container services, it runs between $45k-$55k annually. Rapid7 quoted us a traditional per-asset, per-feature model that started near $30k but projected to double as we grew, with add-on costs for their vulnerability management module.
**Limitations and Where They Win:** Lacework's compliance reporting is good out of the box, but its vulnerability database updates can lag by a few hours compared to Rapid7's. Rapid7 clearly wins if you're already embedded in their ecosystem for SIEM and VM, wanting a single pane. Lacework wins on immediate time-to-value and low-touch operations for a small team.

I'd recommend Lacework for your small team needing a set-and-forget AWS workload protector that minimizes daily alerts. If you're heavily using other Rapid7 tools or need the tightest integration with an existing vulnerability scanner, then Rapid7 could make sense. To be sure, can you share your projected host count and if you have a dedicated security analyst?

Your point about Rapid7's quote being per-asset, per-feature is a classic trap. It sounds straightforward, but it's how you get vendor-locked into a cost structure that scales poorly. Every time you add a new cloud service or feature module, you're renegotiating.

I'd caution against taking that Lacework consumption unit at face value, though. Their model is more opaque in practice. You need to watch your data ingestion spikes during deployments or auto-scaling events closely, or that $45k estimate can quietly balloon.

That's a really important point about cost predictability. Our finance team keeps asking for predictable OpEx, but I'm worried about those auto-scaling surprises too. How much of a spike in your consumption units would you typically see during, say, a major feature deployment? Is there a rule of thumb for buffer?

Welcome to the community! You're asking the right questions for a small team.

For your AWS setup, the agentless CSPM piece for posture management is usually the fastest win with either platform. The real time sink comes from tuning the runtime security alerts to match your actual stack so you're not flooded with false positives. That's where a lot of the initial "management" time goes, regardless of vendor.

On pricing, both models have scaling quirks. Rapid7's per-asset model can get complex as you add services, but it's more predictable month-to-month. Lacework's consumption model ties cost directly to your cloud activity, which is great for low-traffic periods but can surprise you during busy deployments or if you have a security event that generates a lot of logs. For a startup, I'd ask both vendors for a written scenario: what would your bill be if your AWS resource count doubled next quarter?

Small team? Forget both of them. Overkill.

You want easy AWS setup and low alert noise? Neither of these will give you that out of the box. The initial config is a nightmare of policy tuning. You'll spend a week just turning off alerts for your own normal dev traffic.

Their pricing models are designed for growth, alright. Growth in your bill. Rapid7 locks you in, Lacework's consumption model will spike when you can least afford it. Look at something simpler, or just use AWS's own tools until you actually need this complexity.

Agree with asking for the scenario bill. That's a solid move.

Just make sure their scenario includes an outage scenario or a surge in malicious traffic, not just resource count. That's when Lacework's log ingestion can really spike. A "normal" doubling of resources might be fine, but a security incident that generates 10x the normal activity logs is the real budget killer.

That's a critical extension of the scenario-based quote idea. A surge in malicious traffic isn't just a cost issue, it's a stress test for the pricing model itself. You're paying more precisely when you're under duress and likely consuming more support resources, which feels punitive.

A pragmatic follow-up when requesting that scenario from a vendor would be to ask about mechanisms for capping or alerting on consumption. Some platforms offer hard stops or granular controls to throttle data ingestion during an incident, turning a cost variable into a manageable parameter. Without that, the model can feel like it's profiting from your misfortune.