Having just spent the last three days mapping Lacework's APIs to our internal ticketing system (a saga in itself, involving their somewhat-opaque anomaly events endpoint), I'm left staring at the dashboard with one burning, non-technical question. The platform is undeniably powerful—polyglot, decently extensible, good coverage—but the invoice feels like it's scaled for the kind of enterprise that still runs mainframes.
So, let's break down why the cost feels so punitive for a team of, say, under 50 engineers. It's not just the raw number; it's the architecture of their pricing model.
* **The "Everything Bagel" Tax:** Lacework sells you the entire CNAPP suite whether you need all of it or not. Cloud workload protection, container security, CSPM, vulnerability management, compliance. For a small team, we might desperately need the CSPM and vulnerability bits, but the container runtime defense is pure overhead because we're serverless-first. But there's no à la carte menu. You're buying the whole integrated platform, and you're paying for the privilege of their data lake doing joins across all those telemetry streams.
* **Data Ingestion as a Revenue Center:** This is the big one. Their model heavily weights data volume. The moment you start adding accounts, regions, or even just have a busy microservices environment, the meter runs. It's not like you can easily filter on the client-side before sending—their value prop is *them* doing the correlation. So you're incentivized to... send less data? Which defeats the purpose. I've seen bills where a 30% spike in Lambda invocations (a new feature launch) translated to a frightening line item.
* **The Hidden Cost of "Flexibility":** Their API is RESTful, but to get true value, you're building middleware. Want to sync vulnerabilities to Jira? That's on you. Need to rationalize alerts with your existing PagerDuty workflows? More custom glue code. So the real TCO isn't just the license fee; it's the weeks of developer time building and maintaining the integrations to make it *usable* without living in their portal. Compare that to a point solution with a built-in, opinionated Slack/Jira integration that *just works*.
Here's a sanitized snippet of the kind of logic we had to write just to normalize their anomaly alert payloads for our internal systems. This isn't out-of-the-box functionality.
```python
def normalize_lacework_alert(raw_event):
"""
Because Lacework's anomaly payload structure changes based on
resource type (EC2 vs Container vs IAM), and we need a uniform 'severity'
and 'resource_identifier' for our routing engine.
"""
# The 'data' object is a Russian doll of nested JSON
resource_type = raw_event.get('detail', {}).get('eventType', 'UNKNOWN')
if resource_type.startswith('AWS_EC2'):
# Drill down for instance ID
entity = raw_event['detail']['data'].get('entityMap', {})
resource_id = entity.get('InstanceId', [{}])[0].get('value', 'N/A')
elif resource_type.startswith('DOCKER'):
# Entirely different path for containers
resource_id = raw_event['detail']['data'].get('imageId', 'N/A')
else:
# Fallback, which unfortunately happens often
resource_id = raw_event.get('resourceId', 'UNKNOWN')
# Severity mapping is another fun adventure
lacework_severity = raw_event['detail']['severity']
our_severity = {1: 'low', 2: 'medium', 3: 'high', 4: 'critical'}.get(lacework_severity, 'medium')
return ResourceAlert(resource_id=resource_id, severity=our_severity)
```
This isn't to say the product is bad. For a large org with a dedicated cloud security team, the unified view and scale probably justify the cost. But for a small team, you're paying enterprise premiums for capabilities you won't use, while simultaneously funding the development of the integration middleware they didn't build. It feels like you're subsidizing their roadmap.
The painful irony? The very "completeness" that makes it attractive is what prices it out of reach. You end up asking, "Can we get 80% of the value for 30% of the cost from two or three simpler tools?" Even with the integration headache of stitching those together, the math often works out in favor of the DIY approach—which is a sad conclusion for an integration specialist to reach.
APIs are not magic.
Exactly. Their pricing isn't built around usage, it's built around lock-in. You buy the whole platform because their 'value' is in the data correlations across those modules. If you don't ingest everything, the magic fails. So you're forced to pay for the ingestion pipeline upfront, not the actual insights you need. It's a tax on data hoarding.
Your stack is too complicated.
You've nailed the core tension there. The data correlation is their whole pitch, but you're stuck paying for the firehose to get a drink of water.
We tried a trial deployment with just CSPM turned on to keep costs down. The correlation engine started flagging "anomalies" based on missing data from the other modules we weren't ingesting. The noise was counterproductive.
It creates this perverse incentive where you feel compelled to pay for and *use* everything just to make the single feature you wanted work properly. That's the lock-in.
Trust the trial period.
You're spot on about the data ingestion being the revenue center. It's not just paying for the firehose - you're paying to *filter* it on your own dime. Their anomaly events API, which you mentioned, is a perfect example. To get a usable webhook payload into our system, we had to build a middleware layer that does nothing but strip out the noise from the modules we don't use. So we're paying for the data, then paying again in engineering hours to ignore most of it.
The serverless point is key too. We're on a similar stack, and the container runtime alerts are just static. There's no way to turn that data stream off without crippling the correlation for the parts you *do* need. The pricing isn't for features, it's for data volume, and they've tightly coupled the volume to the platform's core functionality.
APIs are not magic.
You've hit on the architectural reason. It's a platform built for enterprise-scale data gravity. The correlation engine needs that massive, unified data lake to function, so they can't unbundle it.
The cost isn't for your *risk surface*. It's for their *data storage and processing*. Small teams don't have the data volume to justify that infrastructure cost, but they're forced to subsidize it because the model is monolithic.
You end up paying for the platform's overhead, not your actual coverage needs. Look at point solutions that pipe findings into a SIEM you control if you need correlation.
Trust but verify, then don't trust.
That "Everything Bagel" analogy is perfect. You're buying the integrated data platform, not a security product. The joins across all those streams *are* the product.
It gets even more expensive when you realize their data model requires normalized storage of all that raw telemetry for their correlation window. You're not paying for the alert you get on Tuesday; you're paying for them to store and re-query the last 30 days of cloud logs, container manifests, and network flows that led to it. A small team's bill is essentially covering the fixed cost of that backend infrastructure, which is massive.
For teams your size, the ROI vanishes because you're subsidizing engineering built for petabytes, not your gigabyte-scale environment.
sub-100ms or bust
You've perfectly described the core frustration. The "Everything Bagel" model means the financial entry point is set by the platform's most expensive component to run - that unified data lake. For a smaller team, you're right, it feels like buying a full industrial kitchen just to use the oven.
A caveat to your point about no à la carte menu: I've seen them offer limited modules in very early startup programs, but it always collapses back into the full platform after a year or a funding round. The economic model simply can't support a fragmented offering because, as others said, the correlation *is* the product.
The real hidden cost, which you're starting to see with your API middleware, is the operational burden of managing the noise from the modules you didn't want. You end up with a "shadow tax" of engineering hours just to filter your own expensive data stream.
Architect first, buy later
That first point hits home for me. The lack of an à la carte menu was the dealbreaker on our last evaluation. We're a PostgreSQL and MongoDB shop, mostly on GCP, and the thought of paying for container scanning when we have maybe three containerized apps felt absurd. It's like buying a full set of tires when you only need to replace one.
But I think there's another layer to the data ingestion model. It's not just paying for the firehose, it's that their pricing is completely opaque about what constitutes a "billable resource." When we asked our rep for a breakdown of cost per gigabyte of log ingestion vs. cost per container image scan, it was all vague talk about "platform value." That opacity feels deliberate, because if you saw the line items, you'd realize how much you're subsidizing the parts you don't use.
Backup first.
You're isolating the exact economic distortion at play. Their model isn't simply "you pay for everything," it's that the pricing anchors on the most expensive data stream to *process*, not the most valuable one to *you*. That's why it feels punitive.
For a serverless-first team, the container runtime data is a cost center with near-zero marginal value. But because the correlation engine's logic is predicated on its presence, you're forced to fund its ingestion and normalization. You're not just buying an unused module; you're subsidizing the platform's architectural dogma that all telemetry is equally necessary for the base analysis.
The irony is that this makes their "integrated" value proposition a liability for smaller, modern stacks. You end up paying a tax for architectural patterns you've deliberately avoided.
James K.
The noise from the correlation engine with partial data is a critical, and often under-discussed, operational cost. You've identified the feedback loop: to reduce noise, you need more data, which increases the bill and generates new noise from other unused modules.
This isn't just a pricing issue; it's a signal-to-noise ratio failure inherent in their architecture. The engine assumes a complete data picture. When you provide an incomplete one, its statistical models generate false positives based on missing variables. It's like a diagnostic tool that throws an error because you didn't plug in an optional sensor.
For a small team, managing that alert fatigue becomes a full-time job, which defeats the purpose of buying a managed service. You either accept the noise or commit to the full financial and operational burden of the platform.