Microsoft Sentinel Pricing: What You Actually Pay and How to Cut It

The first Sentinel bill that surprises a team is almost always the same story: they scoped the SIEM budget against Sentinel's published per-GB rate, missed that Log Analytics charges its own per-GB fee on top, and ended up paying nearly double what they planned. We have seen this across Azure-native shops, MSSPs migrating from Splunk, and ISVs standing up a tenant-per-customer model. The billing model is not complicated, but it requires reading two pricing pages at once.

Two Layers, One Bill

Sentinel does not store data itself. It sits on top of a Log Analytics workspace, and both products charge for ingestion independently.

At pay-as-you-go rates (East US, mid-2026), you are looking at roughly:

Log Analytics workspace: ~$2.30/GB ingested
Microsoft Sentinel surcharge: ~$2.46/GB ingested
Combined effective rate: ~$4.76/GB

That number is the starting point for every conversation we have with a new client. A team ingesting 50 GB/day at pay-as-you-go is spending around $7,100/month before any commitment discount. At 200 GB/day the waste from staying pay-as-you-go becomes hard to justify to finance.

Retention is separate. The first 90 days of retention in a Sentinel-enabled workspace is included. After that, Log Analytics charges roughly $0.10–$0.12/GB/month depending on region.

Commitment Tiers Actually Work

Microsoft offers commitment tiers at both the workspace level (Log Analytics) and the Sentinel level. They are not linked automatically. You set them independently, and both matter.

Sentinel commitment tiers start at 100 GB/day. At that tier the effective Sentinel per-GB rate drops to around $1.23/GB, versus $2.46 pay-as-you-go. That is a 50% cut on the Sentinel portion alone. Stack a matching Log Analytics commitment tier and the combined effective rate falls to roughly $2.30–$2.50/GB.

The tiers are: 100, 200, 300, 400, 500 GB/day, then 1, 2, 5, 10, 25, 50 TB/day. You pay the committed amount daily whether you hit it or not, so right-sizing matters. We typically recommend clients model their 30-day average ingestion, apply a 15% growth buffer, and set the nearest tier below that number. Overcommitting by one tier costs more than staying a tier lower and paying overage at pay-as-you-go.

One detail Microsoft buries in the docs: the Sentinel commitment tier applies to the workspace, not the subscription. If you have five workspaces each doing 30 GB/day, you cannot pool them. Each workspace bills independently. This is a real architectural consideration for MSSPs.

Free Data Sources Are Real, But Scoped

Microsoft does not charge Sentinel ingestion fees for a specific list of first-party connectors. As of mid-2026 this includes:

Azure Activity logs
Microsoft Defender for Cloud alerts
Microsoft Defender XDR (advanced hunting tables: DeviceEvents, DeviceFileEvents, DeviceProcessEvents, etc.)
Microsoft Entra ID sign-in and audit logs (to a point, non-interactive and service-principal sign-ins are billable)
Microsoft 365 Defender incident and alert data

The catch is that "free" means no Sentinel surcharge. Log Analytics still bills for ingestion unless the table is one of the few fully exempt ones. Read the Microsoft Learn pricing exceptions list carefully before assuming a connector is zero-cost.

Non-interactive Entra sign-in logs are a common trap. High-volume tenants can produce 10–30 GB/day of AADNonInteractiveUserSignInLogs alone. That table is billable. We have seen it account for 20% of a client's total Sentinel spend before anyone noticed.

What Actually Blows Up the Bill

In order of frequency across the engagements we have run:

Verbose Windows Security Event forwarding. Sending all event IDs via the Windows Security Events connector. Audit Success events for object access on a busy file server can generate enormous volume. Scope to the UEBA-required event IDs (4624, 4625, 4648, 4688, 4697, 4698, 4719, 4732, 4740, 4776, and a few others) and volume typically drops 60–80%.
Raw firewall and NSG flow logs. These look cheap per event but aggregate to serious volume. Use Azure Monitor's transformation rules to filter RFC-1918-to-RFC-1918 flows before they land in the billable table, or route them to Basic Logs.
Diagnostic settings on every resource. Auto-enabling diagnostics across a subscription sounds like good coverage. AzureDiagnostics becomes a catch-all blob. Use resource-specific tables instead; they let you filter at the transformation layer.
Third-party CEF connectors running in verbose mode. A single misconfigured CEF forwarder for a DLP tool can send duplicate events, raw syslog noise, and debug output simultaneously.

Basic Logs and Auxiliary Logs for Cold Tables

Microsoft introduced Basic Logs (now called Auxiliary Logs in the newer naming) for tables you need to retain but rarely query in real time. The ingestion rate is around $0.60/GB versus $2.30/GB for Analytics Logs, but queries cost $0.006/GB scanned and the table cannot be used in most Sentinel analytics rules.

This tier fits long-retention compliance tables well: raw network flows, verbose audit trails, raw DNS query logs. You keep them for forensics and compliance, run scheduled KQL summarization jobs to push signal into Analytics-tier tables, and pay a fraction of the full rate for the raw data.

The setup is a one-line ARM/Bicep change on the table resource:

resource dnsTable 'Microsoft.OperationalInsights/workspaces/tables@2022-10-01' = {
  name: '${workspaceName}/DnsEvents'
  properties: {
    plan: 'Basic'
    retentionInDays: 365
  }
}

You cannot retroactively move historical data between tiers, so this decision belongs at workspace design time or during a connector migration.

KQL: Surface Your Ingestion Cost by Table

Before you make any commitment tier or architecture change, run this against your workspace. It shows 30-day ingestion volume by table, sorted by billable GB. Pair it with the published per-GB rates and you have a prioritized optimization list in under a minute.

Usage
| where TimeGenerated >= ago(30d)
| where IsBillable == true
| summarize
    TotalGB = round(sum(Quantity) / 1000, 2),
    DailyAvgGB = round(sum(Quantity) / 1000 / 30, 2)
    by DataType
| extend EstimatedMonthlyCost_USD = round(TotalGB * 4.76, 2)  // adjust rate for your region + tier
| sort by TotalGB desc
| project DataType, TotalGB, DailyAvgGB, EstimatedMonthlyCost_USD

Replace 4.76 with your actual blended rate once you know your commitment tier. If you are on a 100 GB/day commitment, your effective rate is closer to $2.50/GB and the cost column changes materially. The point of the query is not an exact dollar figure; it is the rank order, which tells you where to focus transformation rules and collection policy changes.

Run a variant filtering on DataType == "AzureDiagnostics" and break it out by Resource to find which services are producing the most noise inside that catch-all table.

Workspace Design Decisions That Cannot Be Undone

A few choices lock you in:

Single workspace versus multi-workspace. Sentinel's cross-workspace queries work, but commitment tiers do not aggregate. A single large workspace almost always yields better unit economics than several smaller ones, unless regulatory data residency or tenant isolation forces separation.

Log Analytics cluster. At sustained ingestion above 500 GB/day, a dedicated Log Analytics cluster unlocks customer-managed keys, better commitment economics, and capacity reservation pricing. Below that threshold a cluster adds operational overhead without proportional savings.

Table-level RBAC. Decide early which tables need read restrictions. Retrofitting table-level RBAC onto a workspace with existing Sentinel analytics rules that reference those tables is painful. Plan the permission model alongside the connector list.

For teams building Sentinel detections at scale, our detection engineering practice page covers the full KQL detection lifecycle from rule authoring through MITRE coverage gap analysis and continuous validation pipelines.

Next Steps

If you want us to run a Sentinel cost audit, architect a multi-workspace strategy, or build a KQL detection library scoped to your connector set, reach out at /contact.