Just saw the announcement come through about Lacework's new pricing model. Shifting to a per-asset tier is a pretty significant move, and I'm curious what everyone here thinks about it.
Coming from a data and cost-tracking background, my first reaction is to think about asset sprawl. In cloud environments, especially with auto-scaling groups or containers that spin up/down, your "asset" count can be really fluid. For a platform that's all about visibility, this could make forecasting the monthly bill a new kind of challenge. 😅
On the plus side, it might simplify things for smaller teams or projects with a predictable, static footprint. You're paying for what you can see and protect. But for larger, dynamic environments, I'm wondering:
* How are they defining an "asset"? Is it per host? Per container instance? Per IP address?
* Does this model make it easier to understand your costs compared to the old vCPU-based approach?
* For those running heavy ETL or batch jobs that spin up hundreds of temporary compute nodes, could this get expensive quickly?
I'm in the middle of a cloud migration project right now, and this kind of change would definitely factor into our tool evaluation. Keen to hear from others who might have been briefed or have experience with similar per-asset models from other vendors.
- Kev
Exactly, asset definition is the critical detail they'll bury in the fine print. If it's per IP or per container instance, your chaos testing or Friday deploy just became a budget event.
Per-asset sounds simple until you get the first bill with 2000 ephemeral runners on it. The old vCPU model at least had some relation to actual resource consumption. This is a tax on visibility.
Don't panic, have a rollback plan.