Microsoft Sentinel Licensing: Costs, Tiers, and Optimization

The Commitment Tier Trap That Costs Enterprises Six Figures

Microsoft Sentinel's consumption-based pricing model is structurally different from every other Microsoft enterprise product — and that structural difference is the source of a specific, expensive, and entirely avoidable mistake. Unlike M365 or Azure Reserved Instances, where over-commitment produces modest waste, Sentinel over-commitment produces systematic overspend because organisations commit to Capacity Reservation tiers based on projected ingestion volumes that almost always exceed actual steady-state operations.

The average enterprise Sentinel deployment in our analysis is over-committed by 35–55% of actual ingestion volume at the point of Capacity Reservation selection. An organisation ingesting 80GB/day at steady state that commits to a 200GB/day Capacity Reservation tier is paying $0.30–$0.35/GB effective rate when PAYG at their actual volume would cost $2.46/GB — but the Capacity Reservation minimum commitment forces payment for 200GB regardless of actual ingestion. The breakeven logic is correct at the committed volume; the error is committing before actual ingestion is validated.

This article explains how Microsoft Sentinel licensing costs work at each tier, how the free M365 data ingestion benefit interacts with your total cost, and the four-step approach to right-sizing your Sentinel commitment before you lock in a Capacity Reservation.

How Microsoft Sentinel Pricing Works

Microsoft Sentinel pricing has two components: Log Analytics workspace ingestion and Sentinel analysis. Both are required and both are billed based on data volume. Understanding that these are two separate billing lines — not one — is the starting point for cost management.

Pay-As-You-Go (PAYG) Pricing

At PAYG rates, Log Analytics ingestion costs approximately $2.76/GB and Sentinel analysis costs approximately $2.46/GB, for a combined effective rate of approximately $5.20/GB ingested. For an organisation ingesting 50GB/day, this produces a monthly cost of approximately $7,800/month or $93,600/year. PAYG is appropriate during the deployment and ramp period when ingestion volumes are still being characterised — not as a permanent operating mode above 10GB/day ingestion.

Commitment Tier Pricing

Commitment Tiers provide a fixed monthly commitment in exchange for a significantly reduced per-GB effective rate. The tiers and approximate combined (Log Analytics + Sentinel) effective rates are:

The break-even column is critical: it shows the actual daily ingestion volume at which the Commitment Tier becomes cheaper than PAYG. An organisation that commits to the 200GB/day tier but ingests only 80GB/day is paying the equivalent of a PAYG organisation ingesting 200GB/day — it is overpaying by approximately 2.5x for its actual data volume.

The M365 E5 Free Data Ingestion Benefit

One of the most commercially significant — and most frequently miscalculated — aspects of Sentinel licensing is the free data ingestion benefit for M365 E5 users. Organisations with M365 E5 licences receive free Sentinel data ingestion for specific Microsoft 365 log sources, which can materially reduce the total ingestion volume requiring paid capacity.

The M365 E5 free data sources in Sentinel include: Azure Active Directory / Entra ID sign-in and audit logs, Microsoft 365 Audit logs (Exchange, SharePoint, Teams, OneDrive), Defender for Office 365 alerts, Defender for Identity alerts, Defender for Cloud Apps alerts, Microsoft 365 Defender incidents, and Defender for Endpoint alerts. These sources are excluded from ingestion billing for M365 E5 users.

For a 10,000-user organisation with M365 E5, the free ingestion benefit reduces billable data volume by approximately 18–35GB/day depending on environment activity, authentication volumes, and security alert rates. At the 100GB/day Commitment Tier effective rate (~$2.35/GB), this represents approximately $1,500–$2,950/month in monthly cost reduction — or $18,000–$35,000/year. For organisations at the 200GB/day tier, the same benefit reduces effective cost by $1,260–$2,450/month.

The calculation error we see most frequently: organisations budget Sentinel cost based on gross data volume (including M365 sources), commit to a higher Capacity Reservation tier to cover that gross volume, and then discover post-deployment that M365 sources are free — but cannot reduce their Capacity Reservation commitment immediately because tier changes take effect at the next billing period and may not be available for downgrade until the commitment period expires.

What You're Actually Ingesting — And What You Can Filter

The second major source of Sentinel over-commitment is imprecise data ingestion scope. Many initial Sentinel deployments ingest all available data sources because security teams want comprehensive visibility. In practice, the commercial reality of consumption-based pricing requires deliberate decisions about which data sources deliver sufficient detection value to justify their ingestion cost.

High-Value, High-Volume Sources

Network security logs (firewalls, DNS, network device logs) are often the highest-volume ingestion sources and frequently produce the most meaningful security signals. They cannot be free-tiered and require careful volume management. For a 10,000-device environment, network security logs can represent 40–80GB/day alone. Before onboarding all network devices, conduct a 30-day PAYG pilot to characterise actual volumes from each source.

Low-Value, High-Volume Sources to Filter

Verbose application logs (IIS access logs for internal applications, verbose database query logs, verbose DNS resolution logs for known-safe infrastructure) can contribute 20–40% of total ingestion volume with minimal security detection value. Data Collection Rules (DCRs) in Azure Monitor allow filtering at ingestion — removing high-volume/low-value fields from logs before they count against your billable Sentinel volume. Organisations that implement DCR filtering during deployment typically reduce billable ingestion volume by 15–25% without meaningful reduction in detection coverage.

Security information and event management tables (CommonSecurityLog, SecurityEvent) for Windows endpoints where Defender for Endpoint is deployed represent significant duplication — Defender for Endpoint telemetry in Sentinel's SIEM already provides equivalent endpoint detection coverage, making raw SecurityEvent ingestion from the same endpoints redundant. Excluding SecurityEvent table ingestion for Defender-covered endpoints can reduce total billable volume by 10–20% depending on Windows server density.

The Right Commitment Tier Strategy

The single most important commercial principle for Sentinel deployment is: never commit to a Capacity Reservation tier before you have 90 days of actual production ingestion data. This appears obvious but is routinely violated because deployment timelines, budget cycles, and Azure commitment incentives create pressure to commit before data is validated.

The correct deployment sequence is: (1) deploy Sentinel in PAYG mode, onboarding data sources incrementally; (2) measure actual daily ingestion volume by source for 60–90 days; (3) apply M365 E5 free source exclusions and DCR filters to reduce billable volume; (4) only then select the Commitment Tier that covers the 90th percentile of your measured (not projected) ingestion volume. The 90th percentile — not the average — accounts for log spikes during security incidents without committing to a tier sized for peak volumes that occur 2–3 days per month.

Sentinel vs Splunk: The Competitive Negotiation Angle

If your organisation is evaluating Microsoft Sentinel against Splunk, CrowdStrike Falcon LogScale, or Elastic SIEM, the competitive evaluation creates negotiation leverage in your Azure and M365 EA discussions. Microsoft's commercial response to credible SIEM competition has historically included: Azure MACC commitment reduction to reflect Sentinel spend, flexible Sentinel trial period extension at PAYG rates, and in some cases a Sentinel Capacity Reservation commitment with right-to-reduce at the 12-month mark based on validated ingestion.

The competitive evaluation works most effectively when it includes actual vendor pricing proposals — not theoretical comparisons. Request Splunk's per-GB ingestion pricing and Falcon LogScale's tiered pricing at your expected data volumes. The resulting cost model demonstrates that you are a buyer who has done the analysis. For more on competitive pressure as an EA negotiation lever, see our guide to competitive pressure in Microsoft EA negotiations.

For the full security licensing context, see our Microsoft Security Licensing: Complete Enterprise Guide and our related article on whether M365 E5 security justifies the premium. For Azure cost management strategy more broadly, see our Azure Cost Management service page.

4-Step Sentinel Cost Optimization Plan

Step 1: Deploy in PAYG mode and measure before committing. Do not select a Capacity Reservation tier until you have 90 days of production ingestion data. Document actual GB/day by data source.

Step 2: Apply M365 E5 free source exclusions. If your organisation has M365 E5 licences, verify that all qualifying data sources (Entra ID, M365 Audit, Defender alerts) are excluded from billable ingestion. This is a configuration step — free sources must be connected through the correct data connectors to receive the free benefit.

Step 3: Implement Data Collection Rules for high-volume/low-value filtering. Work with your security operations team to identify verbose log sources that contribute volume without meaningful detection signal. Apply DCR transformations to filter these fields before ingestion.

Step 4: Select the Commitment Tier at the 90th percentile of measured volume. Calculate monthly cost at PAYG vs each Commitment Tier using your measured data. Select the tier where the monthly commitment is lower than the PAYG equivalent at your 90th percentile ingestion rate. Review quarterly and adjust as data volumes evolve. Contact our team via the assessment page if you want benchmark comparison against comparable deployments.