Skip to content

SIEM Cost Engineering: Microsoft Sentinel Pricing

Security information and event management (SIEM) platforms are unusual in enterprise software: the license fee is driven almost entirely by a metric the security team does not control. Log volume is generated by infrastructure, application and identity systems that security engineers rarely own, so a routine change — enabling verbose logging on a firewall, onboarding a new SaaS audit source, raising a retention period — can double the bill without any security decision being made.

Microsoft Sentinel, the SIEM built on Azure Monitor Log Analytics, is the most widely deployed cloud-native option in Microsoft-centric estates, and its pricing structure is published in enough detail to model. This analysis covers how the meters work, what a realistic estate costs, and the specific engineering levers that reduce ingestion without reducing detection coverage.

How Sentinel billing is structured

Sentinel charges for data ingestion per gigabyte, then for retention beyond the included window. The Analytics Logs tier, which supports full detection rules and analytics, carries the highest per-GB rate. Pay-as-you-go pricing is published at $4.30 per GB in East US on the simplified tier, rising to $5.59 per GB in higher-cost regions (Microsoft Sentinel pricing). Commitment tiers begin at 100 GB per day, where the effective rate falls to roughly $2.96 per GB — a 100 GB/day commitment corresponds to about $296 per day of committed spend (Microsoft Learn: Sentinel billing).

Two additional tiers matter for cost engineering. Basic Logs are priced at approximately $0.50 per GB, and Auxiliary Logs at approximately $0.15 per GB, both with restricted query and detection capability and separate retention charges (Coralogix analysis). Microsoft also ran promotional pricing on a 50 GB commitment tier from 1 October 2025 through 31 December 2026, which is worth checking before you commit to the 100 GB tier (Microsoft Sentinel pricing).

TierApprox. price per GBDetection capabilityAppropriate for
Analytics (PAYG)$4.30–$5.59 by regionFull rules, workbooks, automationSecurity-critical sources
Analytics (commitment 100 GB/day)~$2.96 effectiveFullSteady high volume
Basic Logs~$0.50Limited, search-orientedHigh-volume verbose logs
Auxiliary Logs~$0.15Minimal, audit-styleCompliance-only retention

What a mid-size estate actually costs

Take a company ingesting 150 GB per day — a common profile for a 2,000-employee organization with Entra ID, Microsoft 365, two cloud environments, a firewall, an EDR platform and a handful of SaaS audit connectors.

At pay-as-you-go list rate of $4.30 per GB, 150 GB/day is $645 per day, or roughly $19,995 per month on a 31-day month. Under a 100 GB/day commitment tier, 100 GB is billed at the committed effective rate and the remaining 50 GB at PAYG: approximately $296 × 31 = $9,176 plus 50 GB × $4.30 × 31 = $6,665, for about $15,841 per month. The commitment saves roughly $4,150 per month at this profile — but only if the commitment is genuinely consumed, since commitment tiers bill whether or not data arrives.

The five drivers of an oversize bill

Verbose diagnostic settings. Enabling all diagnostic categories on Azure resources, particularly on high-traffic App Service or AKS clusters, is the single most common cause of unexpected volume. Most categories are diagnostic rather than security-relevant.

Duplicate platform coverage. EDR telemetry arrives through the EDR vendor’s own connector and through Defender for Endpoint’s built-in streaming, and firewall logs arrive from both the firewall’s syslog export and a native connector. Duplicated sources double ingestion while adding no detection value.

Identity log verbosity. Entra ID sign-in and audit logs are essential, but non-interactive sign-in logs from service principals and managed identities can dominate volume in large tenants.

Retention defaults. Analytics-tier retention is included for a defined period; interactive retention beyond that period, and long-term retention, are billed separately at their own rates. Teams that never adjust retention accumulate years of hot data.

Rule-driven amplification. Scheduled analytics rules that run frequently over large lookback windows consume query capacity, which is included up to a limit and billed beyond it. A rule running every five minutes over a 14-day lookback is expensive in ways that are invisible on the ingestion page.

A reduction playbook

The tactics below are ordered by typical impact. Expected effects are estimates from common deployment patterns, not benchmark results — measure each against your own ingestion report before and after.

TacticTypical impactRisk
Route verbose logs to Basic or Auxiliary tierHigh — often 30–50% of volumeLoss of correlation and full analytics
Disable non-security diagnostic categoriesHighMust confirm no detection depends on them
Deduplicate overlapping connectorsMedium–highRequires mapping detections to a single source
Filter noisy events at the DCR (Data Collection Rule) levelMedium–highOver-filtering creates detection blind spots
Reduce non-interactive identity log noiseMediumMust preserve privileged activity
Tune analytics rule frequency and lookbackMediumSlower detection for some scenarios
Shorten interactive retention; archive the restMediumRetrieval latency for investigations

The Data Collection Rule is the most under-used control. DCR transformations can filter and project events before they are ingested, which means cost is avoided rather than merely reorganized. Filtering a firewall table to drop denied-and-dropped traffic from known scanners routinely removes double-digit percentages of volume.

Alternatives and where Sentinel sits

Sentinel’s advantage is native integration with Microsoft 365, Entra ID, Defender and Azure, and a consumption price that starts at zero without infrastructure. Its exposure is that at very high, steady volumes — several terabytes per day — per-GB list pricing becomes less favourable than platforms sold on committed event-per-second licensing, and cost predictability requires commitment planning.

Microsoft’s own Security Copilot and Defender XDR bundle pricing can change the effective economics, and organizations consolidating on the Microsoft security stack should price the bundle rather than Sentinel alone. Independent cost analyses frequently note that the realistic comparison is not Sentinel versus a single alternative but the total Microsoft security spend versus a multi-vendor stack.

A decision framework

  1. Measure 30 days of ingestion per data source and per table before forecasting anything. The Azure Monitor usage report is the authoritative source.
  2. Classify every table as detection-critical, investigation-supporting or compliance-only, then assign a tier to each class.
  3. Estimate the commitment break-even point and compare against your floor utilization, not your average.
  4. Model retention separately — hot, interactive and archive retention are three distinct line items.
  5. Set a monthly ingestion budget alert with an owner, and review the top five growing tables monthly.
  6. Re-price the Microsoft bundle annually. Sentinel in isolation is rarely the right purchasing unit.

Common mistakes

Committing to a tier based on a peak month; enabling diagnostic settings wholesale during a migration and never revisiting them; treating Basic Logs as free (they carry retention charges and cannot support most analytics rules); and assuming that filtering at the agent or forwarder is equivalent to filtering at ingestion — in cloud-native collection, only ingestion-side filtering changes the bill.

Conclusion

Sentinel cost is an engineering problem with an engineering solution. The bill is set by table-level decisions — which categories are enabled, which tier each table occupies, how long each is retained, and which events are filtered before ingestion. Teams that treat ingestion as an architectural concern rather than a security-team complaint typically reduce spend by a third within two quarters while improving detection quality, because the exercise forces a source-of-truth review that duplicate connectors had obscured.

Sources

FAQ

Frequently Asked Questions

Quick answers to common questions about this topic.

Filtering is cheaper, because nothing is ingested. Basic Logs are appropriate when you need the data available for investigation but not for scheduled detection. Reserve filtering for events with no investigative value at all, since filtered events cannot be recovered.

View More