Switched from LogRhythm to Elastic Security - 3 month honest review

Hey, great to see another LR refugee sharing their story. I'm a revenue operations lead at a SaaS company around 200 people, and my team runs Elastic Security in production for securing our sales and marketing stack - we use it to monitor Salesforce, our ad platforms, and our own product telemetry for security-relevant events like configuration changes or suspicious data exports.

Here's my breakdown on the key criteria for someone comparing these two:
- **Mid-market vs. Enterprise Feature Gates:** Elastic's open-core model makes advanced features like ML-based anomaly detection available to everyone, whereas LogRhythm historically gates those behind their highest Enterprise tiers. In practice, this meant we could build custom behavioral alerts for user activity in our CRM without a costly license upgrade, something LR wouldn't allow.
- **True Cost Per GB Ingest:** Our all-in Elastic Cloud bill runs about $0.28 per GB ingested, which includes the managed service and our chosen 90-day hot retention. With LogRhythm, the licensing was so opaque we could never get a clean number, but support and professional services engagements to add new log sources always pushed the effective cost higher.
- **Deployment and Agent Management:** You nailed it with the Elastic Agent. Rolling out to 150+ EC2 instances took us about two days with Terraform. The real win was consistency; every agent runs the same version from policy. With LogRhythm's old Windows-based agents, we'd have version drift and silent failures that took weeks to diagnose.
- **The Reporting and Visualization Trade-off:** Kibana is incredibly powerful for analysts who live in it, but building polished, scheduled reports for leadership is still a manual, hacky process. LogRhythm's out-of-the-box executive reports were templated and easy to schedule. We've had to build a separate Metabase instance just for leadership dashboards because Kibana can't do that cleanly.

My pick is Elastic Security, specifically for teams that have in-house platform or DevOps expertise and a cloud-native stack. The flexibility is worth the steeper initial learning curve. If your primary need is to hand a polished SIEM to a traditional security team with minimal customization, stick with LogRhythm. To make a clean call, tell us your team's comfort level managing YAML/JSON configurations and what percentage of your log sources are already in the cloud.

Yeah, the "true cost per GB" is a myth they all sell you. The real cost is the brainpower to figure out what a GB actually means in their pricing model and building the dashboards to track it. Wait until you need to scale, that's when the fun starts.

Also, using it for CRM security is clever until someone changes a field mapping in Salesforce and breaks your entire detection pipeline. Good luck.

You're right about the brainpower cost. The dashboards are a project in themselves. But that's where the reserved capacity commitment can create a stable baseline for forecasting, if you can accurately model your ingestion growth.

The mapping breakage point is valid too, though that's a data pipeline governance issue, not unique to Elastic. If your source systems change schemas without a change control process that includes your detection team, you'll have alerts failing silently on any platform.

Yeah, the detection-as-code workflow via the Kibana API is the only way we managed to get any kind of governance in place. That part is solid.

But you're glossing over the main headache with that approach: the rule updates themselves. The API is stable, but the actual YAML rule definitions are a moving target. We've had at least two minor version bumps in the Elastic stack where the schema for a rule field changed and our CI pipeline started throwing validation errors on previously accepted YAML. It's not breaking, but it's noisy and you have to go back and adjust your rule definitions to match the new expected format. It feels like developing against an undocumented API.

Also, if you're doing GitOps, make sure your deployment pipeline accounts for rule order dependencies. We had a case where a rule that depended on a custom index pattern being created would fail on initial deployment because the rule loaded before the index pattern resource. You have to build in stages or retries.

Thanks for the detailed review, really helpful as someone exploring SIEM options. That point about building dashboards to track ingest volume by source is exactly what I was wondering about - it seems essential for managing that usage-based cost.

Could you share a bit more about what you put in those daily dashboards? Like, are you just charting raw gigabyte totals per log source, or are you doing something smarter like calculating trends or alerting on unexpected spikes? Trying to figure out what's useful vs. just creating more dashboard noise.

You're right to focus on the dashboard itself becoming noise. The trick isn't just charting raw totals by source, because that's just historical accounting. The useful bit is calculating a baseline and alerting on deviation.

We set up a simple moving average of ingest per source over the last 7 days, then alert if a source spikes by more than, say, 15% outside that band. That catches the unexpected S3 bucket suddenly logging debug level, or a new Lambda function spamming errors. Without that, you're just watching a number go up and wondering if it's supposed to.

Of course, this assumes your 'normal' is stable. If your developers are constantly deploying new services, the alert fatigue makes the whole exercise pointless. Then you're just building dashboards to manage your dashboards.

Exactly, that's the whole difference between monitoring and actually managing your ingestion. Building that baseline is crucial.

We ran into a similar problem with our developer environments. A 15% spike from a single service is a great red flag, but what if you have twenty new ephemeral services spun up each week? Your moving average becomes useless noise.

We had to get more clever and build separate baseline models. One for stable, production sources using that 7-day average, and another for 'volatile' sources like dev/test that uses a longer rolling window and a wider deviation threshold, like 30-40%. It's not perfect, but it cuts down the false positives from normal dev churn.

Have you looked into using Elastic's own machine learning jobs for this instead of a static threshold? The built-in anomaly detection can sometimes spot those weird, non-linear spikes better than a simple band, especially when new services are coming online constantly.

Your snippet on detection-as-code hits the nail on the head for governance. That said, we hit a specific snag with the Kibana API when managing rule exceptions at scale.

If you're syncing rules from Git via CI/CD, watch out for how you handle exception lists. The API endpoints for updating a rule and its linked exceptions are separate, which can create race conditions in your pipeline if you're not careful. We had to sequence our deployments to update the exception list first, retrieve its new `list_id`, then deploy the rule pointing to that ID. It adds a layer of orchestration complexity the docs don't really cover.

We ended up wrapping the whole process in a Python script that uses the Kibana API's `_bulk_action` endpoint for exceptions first, caches the IDs, then runs the rule deployment. Without that, you risk a rule deploying with stale or missing exception data.

Three months in and you're still calling the usage-based model clear? That's optimism.

You built dashboards to track ingest volume, which is exactly the vendor's trap: you've now dedicated engineering time to building and maintaining the very tool that polices your billable usage. The cost is never just the per-GB fee, it's the full-time equivalent you need to babysit those dashboards and chase down every spike.

And "cost clarity" versus LogRhythm's guessing game? It's just swapping one opaque licensing model for another that requires a dedicated monitoring system to even understand. Wait until you get your first surprise bill from a misconfigured agent going haywire in a dev environment you forgot about. The clarity arrives when the invoice does.

You're not wrong about the engineering time becoming a line item. That's the hidden tax of any consumption model.

But compared to the black box of LogRhythm's socket-based licensing, where adding a single new server could trigger a full license review and a massive true-up bill, I'll take the transparency of my own dashboards. At least I can see the spikes coming and choose to optimize or pay.

The real trap is thinking you can just set it and forget it. The dashboards aren't a one-off project, they're a permanent fixture. It's less about "policing the bill" and more about capacity planning for your own data pipeline. If you're not doing that, you've got bigger problems than the invoice.

You nailed the hidden FTE cost. But calling it a vendor trap is letting your own team off the hook.

That "misconfigured agent going haywire in a dev environment" isn't an Elastic surprise bill. It's an operational failure you were blind to with LogRhythm's flat fee. The usage model just makes your inefficiency visible and billable. The alternative is paying a fat, fixed premium to keep your waste hidden.

Operational failure or not, you're still paying for the meter.

LogRhythm's flat fee at least capped the cost of my team's mistakes. Elastic's model turns every oversight into a direct financial penalty. Visibility doesn't fix the leaky pipe, it just shows you how expensive the water is.

You're spot on about cost clarity, but only after you've paid the "understanding tax" to learn the usage model. We had a similar false start.

Optimizing costs with those dashboards works great for production workloads, but our biggest surprise wasn't from a dev agent. It was from enabling a new security feature in the Elastic Agent policy that suddenly parsed and enriched every log field, doubling our ingest volume from some sources overnight. The dashboard showed the spike, but we didn't realize the cause was a checkbox we'd clicked for "better visibility."

So the clarity is there, but it's reactive. You're building the dashboard to answer questions you don't know to ask yet.

You're praising detection-as-code, but that snippet you're editing in the Kibana UI? It's a fake Git workflow. The real power comes from treating the whole security ruleset as a single declarative artifact.

We define our entire rule base in a custom Terraform provider that points at the Kibana API. Every rule, exception list, and even the index patterns the rules reference are defined as code. The provider handles the dependency graph, like making sure an exception list exists before a rule tries to link to it, which kills those race conditions you're hitting with scripts.

The Kibana API's `_bulk_action` is a bandage. If you're already GitOps, you should manage the entire state declaratively. Otherwise, you're just versioning change scripts, not your actual security posture.