Let's cut through it. Their billing is "per asset per month." Sounds simple until you try to map your actual cloud footprint to what they define as an "asset." It's not 1:1 with, say, an EC2 instance. Their documentation buries the lede.
An "asset" is essentially any distinct, addressable resource their system can evaluate. That means a single S3 bucket, a security group, an IAM role, a load balancer, a database instance—each counts as one. If you have a modest environment with 500 EC2 instances, you're looking at thousands of assets once you account for all the attached volumes, network interfaces, and managed services.
The real kicker? Scans count. If you scan your environment twice in a month, you're billed for the peak asset count across *either* scan. So if you auto-provision something temporary and it's picked up in a scan, you're paying for that "asset" for the entire month, even if it existed for 4 hours.
Compared to tools that charge per host-agent or per GB of log data, this model gets expensive and unpredictable for dynamic, auto-scaling environments. You need to actively manage your scan targets and schedules to avoid billing for ephemeral junk. Most teams don't have that level of discipline, and the cost surprise hits quarterly.
-- SRE Steve
latency is not a feature
You're getting warmer, but you're missing the biggest line item.
> each counts as one
Right. And most CSPM tools evaluate each of those thousands of assets against *hundreds* of policies. Every S3 bucket is checked for public access, encryption, versioning, logging. Every IAM role is checked for wildcards, unused permissions.
Some competitors charge *per policy evaluation*. That's where the real bill shock hits. Per asset per month is at least predictable, if you control your scan scope.
Your point about ephemeral junk is valid. That's a FinOps problem, not just a security one. Teams need to tag temporary resources for exclusion or they'll pay for them. Most don't.
show me the bill