Let's cut through the marketing slides. LogRhythm's "per EPS" (Events Per Second) licensing model is sold as scalable and aligned with usage. In reality, for any environment with anything other than robotic, flat-line traffic, it's a financial trap waiting to spring.
The core problem is simple: you're licensing based on a variable you cannot consistently predict or control. A single incident—a misconfigured device, a burst of debug logging, a minor malware outbreak—can spike your EPS for a billing period. Congratulations, you've just tripped a clause that triggers a license review and a hefty true-up invoice. It's like paying for your office electricity based on the peak wattage used for 5 minutes one day, rather than your total consumption.
Vendor negotiations become a farce. They'll point to your "commit" and the "overage," framing it as *your* capacity planning failure. The hidden costs aren't in the software—they're in the constant, anxious monitoring of your own event flow, the throttling of valuable logs to stay under an artificial ceiling, and the punitive nature of the true-up process.
* You're incentivized *against* ingesting certain logs (security data!) because they're "too chatty."
* Your "scalable" solution now requires internal policing and log filtering that undermines its value.
* Forecasting becomes a game of "what's the worst-case peak we can afford?" not "what data do we need?"
For predictable, regulated environments, maybe you can make it work. For everyone else in the real world of dynamic networks, mergers, new app deployments, and actual security incidents, it's a model designed for vendor revenue protection, not customer utility.
Just my 2 cents
Trust but verify.
You nailed it. The perverse incentive is the worst part.
You start throttling logs to stay under the cap, which means your security tool is now blind. Defeat the whole purpose.
Seen teams build entire side-systems just to filter or sample logs before ingestion. More complexity to manage a bad license model.
Simplicity is the ultimate sophistication
You're spot on about the hidden costs. I'd add the anxiety bleeds into every system upgrade or new project. The first question becomes, "What will this do to our EPS?" not "Will this improve our security posture?"
And you're right, the vendor framing it as *your* planning failure is the real slap in the face. Real traffic is spiky by nature.
I've seen teams spend more on the log-filtering side-project than on the original license, just to avoid these cliffs. Feels like we're licensing the headache, not the tool.
So true. The "per kWh" vs "peak wattage" analogy is perfect. I ran numbers on one month with a few minor incidents.
Our contracted EPS was 15k. Our 95th percentile was 12k. Our *peak* for two minutes during a network scan was 43k.
Guess which number the invoice was based on.
You're not buying analysis capability, you're buying insurance against your own unpredictable peaks. The effective cost per log during quiet periods is absurd.
show the math
Absolutely hit the nail on the head. Your analogy to peak wattage is spot-on and really exposes the business model flaw.
It's worse than just unpredictable though, it's *asymmetric*. You get penalized for peaks, but you don't get a refund for troughs. The system is rigged to bill you for your 99th percentile moment while ignoring the 80% of time you're underutilized.
I've started seeing vendors push AI-generated cost estimates for future EPS. It's another layer of obfuscation, like "the model predicted you'd have a breach so we preemptively billed you for it." 😑
Clean code is not an option, it's a sanity measure.
Your electricity analogy is strong, but it's actually worse than that. A utility can smooth its generation across a grid, averaging out peaks and troughs. In our context, the "grid" is just your single organization, and the vendor's model has no mechanism for that averaging. You're 100% right about the negotiation becoming a farce; they're selling you a deterministic license for a fundamentally stochastic process.
The deeper architectural perversion is that it forces you to make risk decisions based on finance, not security. You mentioned throttling security logs, which is the ultimate failure. I've designed systems where teams had to implement probabilistic sampling on critical auth logs just to keep the license compliant, which statistically guarantees you'll miss low-volume, targeted attack patterns. You're not just managing a budget line item, you're deliberately degrading your security observability to fit a pricing model.
The true cost is the operational debt of building and maintaining that pre-processing filter layer, as others noted. You end up with two complex, stateful systems where there should be one: the filter you don't trust and the SIEM you can't feed freely.
Plan the exit before entry.