Microsoft Sentinel charges per gigabyte of data ingested. In large enterprise environments, monthly bills can run into tens of thousands of dollars — often driven by a handful of noisy data sources that contribute volume without proportionate detection value. The good news: with the right architecture and tooling, organisations routinely cut Sentinel costs by 30–50% without losing meaningful security coverage.

This guide walks through every lever available in 2026 — from commitment tiers and log storage tiers to DCR-based pre-ingestion filtering and KQL-driven ingestion auditing.

1. How Sentinel Billing Works

Sentinel pricing has two components:

• Data ingestion — charged per GB of data written to the Log Analytics workspace. This is the dominant cost driver for most customers.
• Data retention — first 90 days are free. Days 91–730 are charged at a lower rate. Beyond 730 days requires Archive tier or exporting to long-term storage.

2. Commitment Tiers vs Pay-As-You-Go

Pay-As-You-Go (PAYG) is the default but also the most expensive ingestion model. Commitment tiers offer significant discounts in exchange for a daily GB commitment.

3. Log Tiers: Analytics, Basic & Archive

Not all log data needs to be in the expensive Analytics tier. Sentinel supports three storage tiers for Log Analytics tables:

Tables to consider moving to Basic tier

• CommonSecurityLog — firewall/proxy logs with very high volume
• Syslog — Linux system logs, especially from non-critical hosts
• AzureDiagnostics — often contains enormous Azure service telemetry
• AppServiceHTTPLogs / AppServiceConsoleLogs — web app noise

4. DCR-Based Ingestion Filtering

Data Collection Rules (DCRs) let you filter, transform, and route logs before they are ingested — meaning you pay nothing for dropped rows. This is the most powerful cost reduction tool available in 2026.

Common DCR filter patterns

• Drop SecurityEvent IDs that have no detection value (4799, 4985, 5379)
• Filter SigninLogs to only ingest failed sign-ins and sign-ins from non-trusted locations
• Drop AzureDiagnostics rows from non-critical resource types
• Filter CommonSecurityLog to exclude internal-to-internal traffic

// Identify low-value SecurityEvent IDs worth filtering
SecurityEvent
| where TimeGenerated > ago(7d)
| summarize Count = count() by EventID
| order by Count desc
| take 30
// Review: EventIDs like 4799 (local group membership enumeration) and
// 4985 (state of transaction changed) are typically safe to filter

5. Auditing Your Ingestion with KQL

Before optimising, you need to know exactly where your GB are going. The Usage table is the authoritative source for billable ingestion data.

// Top tables by ingestion volume — last 30 days
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize TotalGB = round(sum(Quantity) / 1024, 2) by DataType
| order by TotalGB desc
| take 20

// Daily ingestion trend — detect spikes
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize DailyGB = round(sum(Quantity) / 1024, 2) by bin(TimeGenerated, 1d)
| render timechart

// Monthly cost estimate by table (USD approximation at PAYG rate $2.76/GB)
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize MonthlyGB = sum(Quantity) / 1024 by DataType
| extend EstimatedCostUSD = round(MonthlyGB * 2.76, 2)
| order by EstimatedCostUSD desc

// Top contributing computers per noisy table
Heartbeat
| where TimeGenerated > ago(1d)
| summarize HeartbeatCount = count() by Computer, ComputerEnvironment
| order by HeartbeatCount desc
| take 20

// Find tables contributing the most raw rows
union withsource=TableName *
| where TimeGenerated > ago(1d)
| summarize
    RowCount   = count(),
    EstGB      = round(sum(_BilledSize) / (1024.0 * 1024 * 1024), 4)
  by TableName
| order by EstGB desc
| take 25

6. Top 7 Cost Reduction Wins

1. Switch to a Commitment Tier — the single biggest lever. Even the 100 GB/day tier saves 15% vs PAYG immediately.
2. Move high-volume, low-query tables to Basic tier — Syslog, CommonSecurityLog, and AzureDiagnostics are prime candidates.
3. Use DCR transformation rules to drop low-value event IDs and internal traffic before ingestion.
4. Scope AMA data collection to only the servers and event IDs you actually have detection coverage for.
5. Remove duplicate data sources — many environments have both the legacy MMA agent and AMA sending the same logs. Check Heartbeat for dual-reporting machines.
6. Archive completed investigations — move old incidents and their associated log exports out of Analytics tier after 90 days.
7. Set workspace daily ingestion caps as a safety net — but set them above your peak operational need to avoid alert gaps.