After six months of migrating a substantial portion of our security operations from Microsoft Sentinel to Elastic Security, I have compiled a detailed financial and operational analysis. The transition was motivated by Sentinel's escalating costs at our data ingestion scale and a desire for deeper integration with our existing observability data. This review will focus on the architectural cost drivers, the realized savings, and the non-obvious billing complexities that emerged.
From a pure cost-optimization standpoint, the results are significant but come with critical caveats. Our overall spend on the SIEM/logging function decreased by approximately 32% for a comparable data volume and retention period. This was primarily achieved through three mechanisms:
* **The elimination of data ingestion fees for security-relevant observability data.** In our Sentinel deployment, we were paying to ingest application and infrastructure logs, then paying again to analyze them for security signals. Elastic's single data store model removed this double-billing layer.
* **More granular control over data tiering and retention.** Elastic's hot-warm-cold architecture, managed via index lifecycle management (ILM), allowed us to move older security data to less expensive storage tiers far more aggressively than Sentinel's limited retention tiers permitted. The cost per GB/month for "cold" data in our object storage is negligible compared to keeping all data query-ready in Azure.
* **The efficiency of the Elastic Agent versus legacy forwarders.** Consolidating collection onto a single agent reduced the virtual machine footprint previously dedicated to log forwarders, yielding compute savings.
However, the cost model is not without its pitfalls. The "hidden fees" in Elastic are not fees per se, but rather resource consumption nuances that directly translate to infrastructure costs, which you must manage yourself if self-managing on cloud VMs, or which influence sizing if using Elastic Cloud.
* **Indexing overhead is the primary culprit.** The default settings for security analytics indices can lead to a 20-30% storage overhead compared to the raw log volume due to replication and indexing for fast search. This must be meticulously calibrated; over-indexing is expensive.
* **Node sizing for peak concurrent searches.** During incident response or threat hunting, a surge in complex KQL queries can saturate CPU and memory, forcing an over-provisioning of data nodes for peak loads that are idle 90% of the time. We addressed this with auto-scaling policies, but the tuning was non-trivial.
* **Egress costs for cross-region queries.** If your security team and your primary data store are in different cloud regions, the latency and cost of data transfer for each query can become substantial. This architecture must be designed intentionally from the start.
Operationally, the learning curve for effective cost governance within Elastic is steeper. Sentinel's costs are opaque but predictable; Elastic's costs are transparent but highly variable. We now run daily reports on index growth, query latency, and node utilization, which we did not need with Sentinel's SaaS model. The control is powerful, but it transfers the burden of FinOps from Microsoft to your internal team.
In conclusion, the switch was financially justified for our organization, which had the in-house expertise to tune and manage the platform. The savings are real, but they are not automatic. They are the product of continuous configuration management and a deep understanding of how Elastic's resource consumption maps to your cloud bill. For teams without this readiness, the operational overhead and risk of cost overrun could easily negate the potential savings.
-- Liam
Always check the data transfer costs.
I'm the lead data platform engineer for a mid-market financial services firm, and I've been responsible for our logging and security analytics stack for five years, running both Sentinel and Elastic Security in production across different business units.
* **Total Cost of Ownership for Hybrid Data:** Sentinel's cost model is punishing if your security telemetry is intertwined with operational logs. In my last audit, we were paying $2.25 per GB ingested for Sentinel after commitment tiers, while the same logs in our existing Log Analytics workspaces cost $1.76. Elastic's single ingestion point eliminated that 30% premium for cross-domain analysis. However, Elastic's node-hour costs for persistent storage and compute can exceed projections by 20% if your retention policy and shard sizing aren't optimized upfront.
* **Complex Query Performance at Scale:** For scheduled correlation rules and KQL hunts, Sentinel's backend compute scales transparently. For ad-hoc, multi-index threat hunting across 30+ days of data, Elastic's ability to leverage its inverted indices consistently outperformed. A specific join query between process creation and network events ran in 4.2 seconds on our Elastic cluster but timed out after 30 seconds in Sentinel when spanning over two weeks of data.
* **Deployment and Integration Friction:** Sentinel's integration for Microsoft 365 and Azure AD is genuinely agentless and activates within an hour. For Elastic to achieve parity, we required a combination of the Fleet agent on endpoints, the Azure Event Hub integration for audit logs, and careful IAM configuration, which took three sprints to stabilize. The win for Elastic is its integration library for non-Microsoft assets, like our SaaS applications and on-premise Linux servers, which required no custom parsing.
* **Enterprise Support and Feature Velocity:** Microsoft's support operates on a ticket escalations model that can be slow for non-critical issues; we waited 72 hours for a response on a data latency discrepancy. Elastic's subscription included a direct Slack channel to our solutions architect, which resolved configuration issues same-day. However, Sentinel's feature updates, like the new AI-assisted incident descriptions, are delivered automatically, while major Elastic Stack upgrades require a planned, manual cluster rollout with non-trivial downtime risk.
My pick is Elastic Security, but only for organizations already committed to the Elastic Stack for observability and willing to dedicate a platform team to manage it. If your environment is predominantly Microsoft 365/Azure and you lack dedicated data infrastructure engineers, Sentinel is the more operable choice. To make a clean call, tell us your ratio of Microsoft-sourced to non-Microsoft security logs and the size of your team responsible for maintaining the SIEM backend.
—BJ
Your point about the elimination of double-billing is the critical architectural shift. Many teams overlook that they're paying for the same data twice in separate silos.
One caveat: that single data store model in Elastic can create contention between SRE and SecOps teams during high-volume incidents. If a security alert triggers a heavy query during a P1 outage investigation, both teams suffer latency spikes unless you've implemented robust resource management controls.
That point about node-hour costs sneaking up is spot on. It's the trap teams fall into when they see the initial ingestion savings.
We solved the shard sizing issue with a strict ILM policy based on daily volume, not just calendar days. Saved about 15% on our cloud bill. The hard part is getting everyone to agree on the data tiers upfront.
Automate the boring stuff.