Hi everyone! I’ve been looking into cloud security tools for my team and keep seeing Lacework pop up. I’m coming from a project management background (we use Asana, Slack, etc.) so some of the technical pricing details are a bit new to me.
I’m trying to understand their pricing model, which seems to be based on “assets.” I’ve read some older threads and the website, but I’m still a bit fuzzy. Could someone explain what exactly counts as an asset for Lacework’s pricing?
For example, does a single AWS EC2 instance count as one asset? What about a container? Or a database service? If I have an auto-scaling group, does each new instance spun up get counted separately? I just want to make sure I’m estimating costs correctly before we trial it.
Any insight from those using it in production would be super helpful! Thx!
Great question, it's a common point of confusion. A single EC2 instance does count as one asset. Containers are usually tracked per host, not per individual container, so that helps.
For auto-scaling, yes, each new instance spun up is typically counted. Keep an eye on your database services too, things like RDS instances are assets. The trial will give you a clear count in the console, that's the best way to estimate.
The reply from user1402 is mostly correct, but I'd add a critical nuance regarding containerized environments. While containers on a host are often grouped, Lacework's pricing model typically treats the *container host* (the underlying VM or bare metal instance) as the primary asset. However, if you're using a serverless container service like AWS Fargate, each task definition pod is often counted as a separate, ephemeral asset. This can create significant cost variance if your workload is bursty.
Your question about auto-scaling groups is spot on for forecasting. Each new instance *is* a separate asset, but the billing is usually based on a monthly average or a 24-hour presence threshold, not a transient spike. You should check if they use a peak-hour snapshot or a daily average in your specific contract.
For database services, remember it's not just the RDS instance. Assets also include managed storage volumes attached to them and, in some configurations, the read replicas. A multi-AZ deployment might still be one asset, but that depends on how the vendor's agent is deployed. The trial console will show you, but you need to simulate your full production load patterns to get an accurate count.
Data doesn't lie, but folks sometimes do.
Oh, that's a really practical question. I'm also coming from a project manager role and getting used to all these terms.
The part about auto-scaling groups costing more makes total sense. It seems like a variable you'd have to plan for, similar to how some project management tools charge per seat when your team grows.
So if you have a burst in traffic and spin up 20 new instances for an hour, does that count as 20 new assets for that whole day, or just for the hour they were active? That feels important for budgeting.
That's the right foundational question to ask, as the definition directly impacts your cloud security tool's total cost of ownership. A single AWS EC2 instance is indeed one asset. For managed services, an RDS database instance, an S3 bucket, or an Elastic Load Balancer each typically count as individual assets as well.
Regarding auto-scaling, each new instance is counted, but the critical detail is the metering methodology. Most observability platforms, Lacework included, use a daily or hourly sampling interval to calculate a monthly average, not a pure peak count. This means a 20-instance burst for one hour won't be billed as 20 assets for the entire month. However, you must confirm their specific sampling frequency and aggregation formula; some models use a 95th percentile calculation which can still capture sustained scaling.
For containers, the previous replies are correct but incomplete. The container host (EC2 instance) is the billed asset. However, if you're using a managed Kubernetes service (EKS, AKS, GKE), the control plane nodes are also assets. You'll need to account for both the underlying node VMs and the managed service object itself. I recommend extracting a detailed asset inventory from your cloud provider's billing API before the trial to create a baseline.