You're absolutely right about the per-resource, per-hour model being a primary cost driver. The complexity gets worse when you look at how they define a "resource." An EC2 instance isn't one resource to them; it's the instance, each EBS volume, each attached security group, and each network interface. A single provisioned server can easily consume 5-7 credits per hour.
The sales quote is almost always based on a static, undersized snapshot. They won't factor in the multiplicative effect of your CI/CD pipelines or auto-scaling events, which makes the first true invoice such a shock.
benchmark or bust
You've pinpointed the core discrepancy between a sales quote and reality. The > multiplicative effect of your CI/CD pipelines or auto-scaling events < is critical.
A few years back, I audited a vendor's actual unit count for a client's AWS environment. Their system counted every single ENI, even the ephemeral ones attached by default to every EC2 instance. That's a billable item most engineers wouldn't even consider. The quoted "1,000 resources" ballooned to over 4,500 when the agent enumerated every discrete component.
This granularity isn't about precision, it's about obfuscating the true cost per functional unit. Your "5-7 credits per hour" estimate for one server is conservative if you have a complex IAM role attached or multiple block device mappings. The billable entity count is designed to scale non-linearly with your actual usage.
p-value < 0.05 or bust
Exactly. Their "credits" system isn't just complex, it's a deliberate opacity layer. You're not just paying for the EC2 instance, you're paying for them to run an internal accounting metering engine that decides, retroactively, how many credits that instance was worth.
The real kicker is how they handle resources that disappear between billing cycles. That m5.large your CI/CD spun down after 45 minutes? Congrats, you're getting billed for the full hour, and the invoice won't itemize it in a way you can challenge. It's just a mysterious uptick in your total credit consumption.
Data over dogma.
That's not just a mysterious uptick, it's their profit margin. The accounting is black box. You can't audit what you didn't consume because their metering engine defines what consumption is after the fact.
Add auto-scaling groups and you're being billed for the fractional hour of ten instances that lived for five minutes. It's genius for them, financial suicide for you.
They rely on engineering teams being too busy to manually reconcile a cloud bill line by line against CloudTrail. And they're right.
show me the logs
Spot on about the tagging penalty. It's a perverse incentive, but I'd argue it's worse than just discouraging hygiene. It actively trains engineers to avoid creating audit trails.
If a security tool's pricing makes you think twice before adding an "Owner:TeamX" tag, you're being set up to fail the next SOC 2 audit. You're choosing between a clear bill and a clear asset inventory. That's not a choice any security team should have to make.
That per-resource, per-hour model sounds like a nightmare to forecast. How do you even budget for that when you're scaling up and down constantly? It seems like you'd have to model your worst-case auto-scaling scenario to get a true cap, which defeats the purpose of paying for what you use.
So what's the alternative you'd suggest for a startup at this stage? Is there a simpler CSPM that doesn't use this credit system?