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

The first Sentinel bill that surprises a team is almost always the same story. They budgeted from a per-GB rate they found in an old blog post, then turned on a few connectors that ship far more data than expected. The pricing model itself is simple now. What drives the bill is volume, and which tier each table lands in.

All prices below are Microsoft's published East US list prices as of September 2026, pulled from the Azure Retail Prices API. Your region, currency and agreement will change them. Check the Microsoft Sentinel pricing page or the cost estimator before you commit budget.

One Meter, Not Two

Since July 2023, Sentinel uses simplified pricing. One per-GB price covers both the Log Analytics ingestion and the Sentinel analysis. Workspaces created before then may still sit on the "Classic" tiers, which bill the two separately. If any Sentinel meter on your invoice starts with "Classic", you are on classic pricing. Microsoft's billing doc recommends switching to simplified to unify the meters.

At pay-as-you-go, the analytics tier costs $4.30 per GB ingested.

A team ingesting 50 GB/day at pay-as-you-go spends about $6,450 a month. At 200 GB/day it is about $25,800 a month, and staying on pay-as-you-go at that volume is hard to justify to finance.

Retention is separate. The first 90 days in a Sentinel-enabled workspace are included. After that, analytics tier retention costs $0.10 per GB per month.

Commitment Tiers: The Real Numbers

A commitment tier is a fixed daily fee for a reserved volume. Usage above the commitment is billed at the same discounted per-GB rate, not at pay-as-you-go.

Three rules decide which tier you pick:

• Break-even is lower than the tier size. The 100 GB tier pays for itself from about 69 GB/day, since $296 buys 68.8 GB at pay-as-you-go. The 50 GB tier breaks even at about 38 GB/day.
• Upgrades are easy, downgrades are not. You can move up at any time, and that restarts a 31-day commitment period. You can only move down once the period ends.
• Tiers are per workspace. Five workspaces at 30 GB/day each cannot pool into one 100 GB tier on their own. The exception is a Log Analytics dedicated cluster, which starts at a 100 GB/day commitment and bills all linked workspaces in the same region against one tier. This is a real architecture decision for MSSPs and multi-subsidiary tenants.

The 50 GB tier is a public preview promotion. Sign-ups run through December 31, 2026, and the promotional price holds until March 31, 2027. Plan for what happens after that date.

We model a client's 30-day average ingestion, add a growth buffer, and pick the highest tier the average clears after break-even. Because overage bills at the tier's discounted rate, sitting one tier low costs little. Sitting one tier high means paying every day for capacity you do not use.

To run your own numbers, use our free Sentinel pricing calculator. Enter GB per day and retention, and it picks the cheapest tier and prices the data lake option from the same list prices.

Free Data Sources Are Real, But Narrow

Microsoft does not charge for a short list of data types. Per the billing doc, the free ones are:

• Azure Activity logs (AzureActivity)
• Sentinel health data (SentinelHealth)
• Office 365 audit logs in OfficeActivity, covering SharePoint, Exchange admin and Teams
• Security alerts and incidents from the Defender family (SecurityAlert, SecurityIncident), including Defender XDR, Defender for Cloud, Endpoint, Identity, Office 365 and Cloud Apps

The catch is that alerts are free, raw logs are not. Defender XDR advanced hunting tables such as DeviceProcessEvents and DeviceNetworkEvents are billable. So are Microsoft Entra ID sign-in and audit logs.

Two benefits can offset some of that:

• Microsoft 365 E5, A5, F5 and G5 customers get up to 5 MB per user per day of free ingestion for eligible Microsoft 365 and Entra data. See the offer page for the covered tables.
• Defender for Servers Plan 2 grants 500 MB per server per day for security data types such as SecurityEvent, pooled across the subscription. It only applies when Plan 2 is also turned on for the Log Analytics workspace itself. Creating a data collection rule alone does not enable it.

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

What Actually Blows Up the Bill

In order of frequency across the engagements we have run:

1. 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 generate enormous volume. Scope the collection to the "Common" or a custom event set and volume typically drops 60 to 80%.

2. Raw firewall and NSG flow logs. These look cheap per event but add up fast. Filter internal-to-internal flows with a transformation before they land, or send the table to the data lake tier.

3. 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, so you can filter each one at the transformation layer.

4. 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 at the same time. Watch the AdditionalExtensions field too. Vendors stuff extra fields there and it can outweigh the standard CEF columns.

The Data Lake Tier for Cold, Noisy Tables

The Microsoft Sentinel data lake is now the main lever for high-volume, low-value logs. You set a table to the lake tier and it skips the analytics tier price entirely. The meters are:

• Ingestion: $0.05 per GB, plus processing at $0.10 per GB, so $0.15 per GB in total for lake-only tables
• Storage: $0.026 per GB per month, billed on compressed size at a flat 6:1 ratio
• Query: $0.005 per GB scanned by KQL queries and jobs

Compare $0.15 to $4.30. For firewall, proxy, NSG flow and raw DNS logs, the saving is large.

The trade-off is detection. Lake-tier tables are for hunting, investigation and compliance, not real-time analytics rules. The usual pattern keeps the raw table in the lake and runs a scheduled KQL job that summarizes the signal into an analytics-tier table your rules can use.

Tables that live in the analytics tier are also mirrored into the lake at no extra ingestion cost. Once their analytics retention ends, lake storage charges apply. That makes long retention far cheaper than extending analytics retention at $0.10 per GB per month.

Workspaces that have not onboarded to the data lake still have the older Basic and Auxiliary log plans. Basic Logs analysis bills at $1.00 per GB under simplified pricing. If you are planning new work, onboard to the data lake instead. Once you onboard, Microsoft bills through the data lake meters instead of the old archive, search and auxiliary meters.

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.30, 2)  // pay-as-you-go East US; use your tier's effective rate
| sort by TotalGB desc
| project DataType, TotalGB, DailyAvgGB, EstimatedMonthlyCost_USD

Replace 4.30 with your tier's effective rate from the table above. On a 100 GB/day commitment it is $2.96, and the cost column changes materially. Free tables report IsBillable == false, so they drop out of this query on their own. 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.

Transformation Rules Before the Data Lands

Data Collection Rule transformations run at ingestion time and let you drop rows or strip columns before the data is stored. This is the right place to cut volume on noisy sources.

A simple example: dropping Windows Security Event 4688 (process creation) entries where the process is a known-clean system binary. You still capture process creation for interesting binaries; you just do not pay to store svchost.exe starting ten thousand times a day.

// DCR KQL transformation, drop known-clean 4688 events
source
| where EventID != 4688 or (
    EventID == 4688
    and NewProcessName !in (
        "C:\\Windows\\System32\\svchost.exe",
        "C:\\Windows\\System32\\conhost.exe",
        "C:\\Windows\\System32\\WerFault.exe"
    )
)

This runs in the ingestion pipeline. Data that gets dropped never touches your billable storage. Volume reductions of 20-40% on SecurityEvent are common with targeted transformation rules.

The same principle applies to AzureDiagnostics: you can filter out specific ResourceType values at the DCR level and route only the types you actually analyze to Analytics tables.

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 across standalone workspaces. A single large workspace almost always yields better unit economics than several smaller ones, unless data residency or tenant isolation forces separation.

Log Analytics dedicated cluster. From 100 GB/day across your workspaces in one region, a dedicated cluster lets them share one commitment tier and unlocks customer-managed keys. It has no pay-as-you-go option and bills from the moment it is provisioned, so size it from real ingestion, not a forecast.

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.