Traditional security tooling procurement runs on a familiar rhythm: agree a per-seat or per-endpoint price, sign an annual term, and budget accordingly. Microsoft Sentinel, the company’s cloud-native SIEM, does not follow that rhythm. It bills almost entirely on how much log data an organisation ingests, which means the price is a function of logging behaviour, not headcount, and that distinction catches a lot of security and finance teams off guard when the first real invoice lands.
The Basic Mechanics of Ingestion Pricing
Independent pricing analysis of Sentinel’s billing structure lays out the mechanics clearly. One detailed 2026 breakdown explains that every byte of high-volume log data reaching the analytics tier is billed per gigabyte on a pay-as-you-go or commitment-tier basis, and that even the commitment-tier list price only covers ingestion up to the committed daily volume, not overage, extended retention add-ons, or any data routed to the separate data lake tier.
Independent pricing trackers monitoring Sentinel’s retail rates put pay-as-you-go ingestion at roughly $4.30 per gigabyte in standard US regions, with commitment tiers starting at 100 gigabytes per day cutting the effective rate by around 31 percent, and the largest tiers at 50,000 gigabytes per day reducing it by more than half. The gap between pay-as-you-go and a well-chosen commitment tier is large enough that it should be a standing agenda item at every Sentinel renewal, not a one-time decision made at initial deployment and never revisited.
The Free Ingestion Trap
Microsoft does offer meaningful free ingestion for certain data sources, and this is where a lot of budget confusion starts. Cost analysis specific to Microsoft-heavy security operations notes that Azure Activity logs, Office 365 audit logs covering Exchange, SharePoint, and Teams, and the security alerts generated by Microsoft Defender XDR all ingest free, but the underlying raw logs behind those alerts, along with Microsoft Entra ID sign-in and audit logs, are billed at the standard per-gigabyte rate.
The distinction between free alerts and paid raw logs is easy to miss during initial deployment planning and expensive to discover afterward. A security team that assumes Defender integration means all related telemetry ingests free is likely to see a materially larger bill than expected once the raw advanced-hunting tables and Entra sign-in logs start flowing into the workspace at full price alongside the free alert summaries.
Why the Headline Rate Is Rarely the Real Rate
Buyer-side cost benchmarking makes a similar point about the gap between advertised and actual spend. Analysis aggregating verified Sentinel pricing data found that hidden costs, including premium support requirements, unexpected Azure platform fees, and Log Analytics workspace ingestion charges, typically add thirty to sixty percent on top of the base ingestion price once a deployment is fully operational. A commitment tier quote that looks attractive in isolation can end up costing considerably more once these adjacent charges are added to the comparison.
This is precisely why modelling a full year of realistic ingestion volume, including the raw logs that do not qualify for free ingestion, matters more for Sentinel budgeting than for almost any other Microsoft security product. The headline per-gigabyte rate is real, but it is rarely the number that determines whether the annual security budget holds.
Using Archive and Data Lake Tiers to Control Spend
Sentinel’s newer data lake tier gives budget-conscious security teams a genuine lever that did not exist in earlier versions of the product. Data routed to the archive or data lake tier after its active analytics retention window closes bills at a substantially lower rate than the standard analytics tier, while remaining searchable through on-demand search jobs when a genuine investigation requires it.
The trade-off is query latency and a per-scan cost for pulling archived data back into an investigable format, which makes this tier a good fit for compliance-driven long-term retention rather than data the security operations centre expects to query daily. Structuring retention deliberately around which logs need to stay hot in analytics tier versus which can move to a cheaper archive tier, rather than leaving every log source on a single default retention setting, is one of the more direct ways to bring the Sentinel bill under control without reducing actual security visibility.
Commitment Tiers Are a Daily Reservation, Not an Annual One
One structural detail trips up teams evaluating Sentinel commitment tiers for the first time: the reserved capacity is a daily volume commitment, paid every single day regardless of whether that day’s actual ingestion fills the tier. Choosing a 500 gigabyte per day tier because it matches an average day’s volume ignores the reality that ingestion volume fluctuates, sometimes significantly, based on patching cycles, incident response activity, and seasonal business patterns that generate more or less log data depending on the time of year.
The safer sizing approach is anchoring the commitment tier to a realistic low-to-median ingestion day rather than an average, and allowing genuine spike days to bill at that tier’s discounted overage rate rather than the full pay-as-you-go rate. Overshooting a committed tier is not penalised the way it is on some competing SIEM platforms, which makes slightly under-committing a lower-risk choice than over-committing to a tier that goes unused on quieter days.
The Splunk Migration Cost Comparison
A meaningful share of Sentinel deployments today are migrations from an existing SIEM, most commonly Splunk, and the cost comparison between the two platforms is rarely as simple as comparing headline per-gigabyte rates. Sentinel’s free ingestion for Microsoft-native sources gives Microsoft-heavy organisations a genuine structural advantage that a like-for-like Splunk cost comparison would miss entirely if it only compared raw per-gigabyte pricing.
Organisations running a genuinely mixed estate, with substantial non-Microsoft infrastructure generating the bulk of their security telemetry, see a smaller version of that advantage, since a larger share of their total log volume falls outside Sentinel’s free-ingestion categories. Modelling the migration honestly means breaking down projected log volume by source and checking which specific sources qualify for free ingestion before assuming Sentinel’s total cost of ownership will undercut an existing SIEM by the same margin quoted in a generic vendor comparison.
Defender Integration and the Discount Lever Nobody Uses
Sentinel’s pricing sits close enough to the broader Defender XDR ecosystem that Microsoft’s own commercial incentives around the two products differ in a way worth understanding before a renewal conversation. An Enterprise Agreement that already bundles Microsoft 365 E5 alongside a defined Sentinel commitment gives Microsoft more incentive to discount the Defender attach rate than to discount Sentinel’s ingestion pricing directly, since Defender licensing is the more strategic upsell from Microsoft’s perspective.
The practical negotiation implication is to anchor discussions on Defender XDR’s list price and the standalone rates for Defender for Cloud Apps and Defender for Identity, rather than pushing primarily for a lower Sentinel ingestion rate. Buyers who understand this asymmetry tend to extract more total value from a security-focused EA renewal than those who treat every line item as equally negotiable.
Building Detection Value Into the Ingestion Decision
Ingestion cost decisions should not be made purely on price. A log source that is cheap to ingest but never actually feeds a meaningful detection rule is not saving money, it is simply generating storage cost without generating security value. The more useful question to ask about any log source before committing budget to it is not just what it costs per gigabyte, but which specific detections or investigations that data would actually support if an incident occurred tomorrow.
Security teams that periodically audit their ingested log sources against active detection rules, retiring sources that no rule actually references, tend to bring their Sentinel bill down without any negotiation at all, simply by no longer paying to ingest data that was never doing meaningful security work in the first place.
Automation and Playbook Costs Beyond Ingestion
Ingestion is the largest and most discussed cost component, but it is not the only one that materially affects a Sentinel budget. Automation rules and playbooks, which trigger automated response actions when specific detections fire, consume separate Azure resources depending on how they are built, and a security operations centre that builds increasingly sophisticated automated response chains over time can see this secondary cost grow steadily even while ingestion volume stays flat.
Budgeting for Sentinel accurately means accounting for this automation layer alongside the ingestion meter, particularly as security teams mature from simple alerting toward genuine automated response, since that maturity curve tends to move automation cost from a rounding error into a line item worth tracking in its own right.
Negotiating the Sentinel Line Separately From the EA
Because Sentinel commitment tiers are structured as a daily reservation rather than an annual seat count, they do not map neatly onto the same negotiation logic that governs the rest of a Microsoft Enterprise Agreement renewal. Treating Sentinel as an afterthought inside a broader security bundle negotiation, rather than as its own consumption-based line with its own volume history and growth trajectory, tends to leave savings on the table that a dedicated conversation would have captured.
A useful negotiation anchor is the organisation’s own trailing twelve months of actual ingestion data, broken down by source, compared honestly against projected growth from any new log sources planned for the coming year. That level of specificity is far more persuasive in a renewal conversation than a general request for a better Sentinel rate, and it gives the Microsoft account team a concrete volume commitment to price against rather than a rough estimate.
It is also worth entering that conversation with a clear view of which commitment tier the organisation would move to if its ingestion grew by a defined percentage over the coming year, since security data volume tends to grow rather than shrink as an organisation matures its detection coverage, and negotiating tier flexibility upfront is considerably easier than renegotiating mid-term once growth has already outpaced the current commitment.
Conclusion
Microsoft Sentinel’s consumption-based pricing model rewards security teams that understand exactly which log sources are free, which are paid, and which tier each one genuinely needs to sit in. It punishes those that deploy broadly, leave every source on default retention, and only discover the real cost structure once the first full invoice arrives.
Getting ahead of this means modelling realistic ingestion volume including the sources that do not qualify for free ingestion, using archive and data lake tiers deliberately rather than defaulting everything to analytics tier retention, and negotiating Sentinel’s consumption commitment as its own line item backed by real usage history at every renewal.
