Microsoft Sentinel Pricing: Where the Bill Comes From and How to Control It

The bill is usually the first honest feedback you get on a Sentinel deployment. A customer brings us in, we pull up Cost Analysis, and there is $40k sitting in a single month for a workspace that was supposed to cost $8k. The culprit is almost always the same: a handful of verbose tables nobody audited, combined with a pay-as-you-go rate on a volume that should have been on a commitment tier weeks earlier.

This is the walkthrough we give every engagement before we touch a single detection rule.

What You Are Actually Paying For

Microsoft Sentinel pricing has two components that show up on the same bill but are billed separately: the Log Analytics workspace ingestion cost and the Sentinel per-GB add-on for data analyzed by the SIEM engine.

Pay-as-you-go ingestion runs roughly $2.30-$2.60 per GB depending on region. The Sentinel add-on on top of that sits around $2.46/GB at PAYG rates. So unoptimized, you are paying somewhere between $4.50 and $5.00 per GB of data that flows into an Analytics-tier table and gets analyzed. At 50 GB/day, that is $6,750-$7,500 per month before retention costs.

The 90-day interactive retention window is included. Past that, you pay for extended retention or archive, which is cheap at roughly $0.10-$0.12/GB/month. The retention bill rarely shocks people. The ingestion bill does.

There is also the question of which tables are even subject to the Sentinel add-on. Microsoft-native sources like Microsoft Entra ID sign-in logs, Microsoft Defender XDR alerts, and Office 365 activity data come in through free data connectors. You do not pay ingestion for those. Third-party sources, custom logs, and anything arriving via the Azure Monitor Agent or a Syslog forwarder hits your bill at full rate.

The Commitment Tier Decision

Commitment tiers (Microsoft still calls them Capacity Reservations in some parts of the portal) give you a fixed daily ingestion allowance at a discount. The tiers run at 100, 200, 300, 400, 500, 1000, 2000, and 5000 GB/day. The discount versus PAYG scales from about 15% at 100 GB/day to over 50% at the high end.

The math is straightforward. If your 30-day average daily ingest is above 75-80% of a tier threshold, commit to that tier. PAYG above 100 GB/day is almost always wrong. The reservation bills hourly even if you do not hit the daily cap, so an environment with wildly spiky ingest needs smoothing before committing.

One thing people miss: commitment tiers apply at the workspace level. If you have split your logs across multiple workspaces for compliance reasons, each workspace's tier is evaluated independently. Consolidating workspaces often unlocks a tier discount that more than offsets the architectural inconvenience.

The Tables That Will Eat Your Budget

Pull this KQL in any Sentinel workspace and run it against the last 30 days. It tells you exactly where your ingestion cost is concentrated.

Usage
| where TimeGenerated >= ago(30d)
| where IsBillable == true
| summarize
    TotalGB = round(sum(Quantity) / 1024, 2),
    DailyAvgGB = round(sum(Quantity) / 1024 / 30, 2)
    by DataType
| extend EstimatedMonthlyCost_USD = round(TotalGB * 2.50, 2)
| sort by TotalGB desc
| take 20

The $2.50 factor is a placeholder. Substitute your actual blended per-GB rate from your EA or MCA agreement. The point is the ranking. In most environments we audit, the top five tables account for 70-80% of total ingest. Common offenders:

AzureDiagnostics is the worst. It is a catch-all schema that swells when you enable diagnostics on every Azure resource without filtering. A single busy Application Gateway or Azure Firewall can push hundreds of GB per day into this table.

CommonSecurityLog collects syslog-CEF from firewalls and IDS appliances. The volume is proportional to how chatty your network gear is. Palo Alto traffic logs are a classic example of data that sounds security-relevant but is mostly noise at the connection-level.

Syslog from Linux hosts, especially those running verbose services.

SecurityEvent from Windows hosts, especially if you have auditing set to the most verbose profile without filtering via DCR transformation rules.

Basic Logs and Auxiliary Logs as Cost Levers

Microsoft added two cheaper log tiers that most customers either do not know about or have not deployed. They change the economics substantially.

Basic Logs ingest at roughly $0.50/GB. The tradeoff: queries are limited to 8 days of interactive data, and you cannot use them in analytics rules or workbooks directly. They support KQL queries via the search operator and direct table queries, but with a per-GB query charge around $0.005/GB scanned.

Auxiliary Logs (in preview for some time, now generally available in most regions) go even cheaper, closer to $0.08/GB for ingest, with queries charged at scan rate and a 30-day hot window.

The right pattern: put verbose, high-volume, low-detection-value tables on Basic or Auxiliary. AzureDiagnostics for non-critical resource types is a strong candidate. So is raw DNS query logs, verbose web access logs you keep for forensics rather than real-time detection, and network flow data you use for hunting but not alerting.

Analytics tables stay reserved for data that feeds your detection rules. A safe heuristic: if no scheduled analytics rule queries the table, it probably does not need to be on Analytics tier.

You set the tier per-table via DCR (Data Collection Rule) configuration or directly in the workspace table settings blade. It is not a workspace-wide switch.

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.

What a Properly Sized Deployment Actually Costs

For a 500-person organization with a modern endpoint stack and Azure-first infrastructure, we typically see 10-25 GB/day of Analytics-tier data after optimization. At the 100 GB/day commitment tier, that lands between $6,000 and $9,000 per month all-in including the Sentinel add-on and 90-day retention. Unoptimized PAYG on the same volume with noisy sources enabled runs $18,000-$28,000.

The gap is the work. It takes a week of investigation, DCR tuning, and table-tier adjustments to get there. But it is mechanical work with a clear ROI. We have never done this pass on a Sentinel deployment without finding at least 25% to cut.

For detection engineering guidance on what to actually keep in Analytics tier, see our detection engineering practice.

When to Revisit the Pricing Model

Sentinel pricing is not static. Microsoft has adjusted tier thresholds and Basic Logs availability several times. Review your commitment tier quarterly against the actual 90-day rolling average. If you are consistently using less than 70% of your committed tier, step down. If you are consistently bursting 20%+ above it, step up before PAYG overage compounds.

Set a Cost Management alert at 80% of your monthly Sentinel budget. Do not wait for the invoice.

When ingestion spikes unexpectedly, the Usage table query above is always the first stop. Sort by the last 24 hours versus the 30-day average; any table more than 3x its baseline warrants immediate investigation, either a new data source someone connected without review or a logging configuration that changed upstream.

Contact us if you want a one-day Sentinel cost audit with concrete tuning recommendations before your next billing cycle.