Why Sentinel Costs Are So Variable — and So Often Surprising
Microsoft Sentinel is a consumption-based SIEM. You pay for data ingested into the Log Analytics workspace, and the volume of that data depends on every data source you connect, every event type you configure, and every agent you deploy. There is no fixed per-user or per-endpoint price. The result is a cost structure that is genuinely difficult to predict before deployment and easy to mismanage after it.
Organisations that deploy Sentinel without a structured ingestion management approach routinely face bills that are 2–4 times higher than initial estimates. The culprits are almost always the same: Windows Security Event logs enabled at the wrong verbosity level, Azure Activity logs enabled tenant-wide without filtering, firewall logs ingested at full verbose detail, and diagnostic logs from every Azure resource forwarded without scoping. None of these individual decisions seems unreasonable — and none individually is catastrophic — but in combination they create ingestion volumes that can make Sentinel the most expensive line item in the Azure bill for security-mature organisations.
The good news: the same consumption model that creates cost unpredictability also means that targeted optimisation delivers direct, immediate cost reduction. Unlike seat-based licensing where the cost reduction requires negotiation, Sentinel cost reduction requires configuration changes and architectural decisions that reduce ingestion without reducing security coverage. This guide provides the framework.
The Sentinel Pricing Model: Pay-As-You-Go vs Commitment Tiers
Sentinel charges for data ingestion on two models:
Pay-As-You-Go (PAYG): Approximately £2.15/GB ingested (rates vary by Azure region and are updated periodically — confirm current rates in the Azure pricing calculator). No commitment, no minimum. This is the starting point for most new Sentinel deployments and the right model until ingestion volume is well-understood.
Commitment Tiers: Fixed daily commitment in exchange for a lower per-GB effective rate. Tiers step from 100 GB/day to 5,000 GB/day, with per-GB effective rates decreasing at each step.
| Commitment Tier | Daily Cost (approx.) | Effective Per-GB Rate | Monthly Cost (approx.) | Saving vs PAYG |
|---|---|---|---|---|
| PAYG (no commitment) | Variable | ~£2.15/GB | Variable | — |
| 100 GB/day | ~£172/day | ~£1.72/GB | ~£5,160 | ~20% |
| 200 GB/day | ~£307/day | ~£1.54/GB | ~£9,210 | ~28% |
| 500 GB/day | ~£688/day | ~£1.38/GB | ~£20,640 | ~36% |
| 1,000 GB/day | ~£1,290/day | ~£1.29/GB | ~£38,700 | ~40% |
| 2,000 GB/day | ~£2,364/day | ~£1.18/GB | ~£70,920 | ~45% |
A commitment tier reserves capacity at a reduced rate — but you pay for the full tier regardless of whether you use it. If your actual ingestion falls below the committed tier on a given day, you still pay the full daily rate. Commitment tiers should only be selected when you have 30+ days of stable ingestion data showing consistent volume at or above the tier threshold. Selecting a tier based on initial deployment spikes leads to overpayment for underutilised capacity.
Free Data Sources: What You Can Ingest at No Cost
Microsoft has progressively expanded the list of data sources that are free to ingest into Sentinel. This is strategically important — the free sources include the Microsoft security products that are most likely to be deployed by Sentinel customers, which means many of the highest-value security signals come at zero ingestion cost.
Free Microsoft Security Product Data
The following data sources from Microsoft security products are ingested at no Sentinel charge:
- Microsoft Defender XDR alerts and incidents (Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps)
- Microsoft Entra ID sign-in logs and audit logs (for E5 and Entra P2 tenants — E3 and P1 tenants incur ingestion charges for these)
- Microsoft Defender for Cloud alerts
- Microsoft Purview Data Loss Prevention alerts
- Microsoft 365 Defender Advanced Hunting data forwarded to Sentinel
- Activity logs from Azure services (Basic Activity Logs — not Diagnostic Logs)
The M365 E5 free ingestion benefit is particularly significant: M365 E5 subscribers receive 5 MB of free Sentinel data ingestion per licensed user per day for specific M365 data types. For a 2,000-user M365 E5 organisation, this represents 10 GB/day of free ingestion — approximately 300 GB/month that would otherwise cost £645 at PAYG rates. Over a year, this is a £7,740 ingestion saving that most E5 organisations are not explicitly tracking in their Sentinel cost analysis.
The Top Cost Drivers: What Creates the Bill
Understanding which data sources drive Sentinel costs is the prerequisite for any optimisation programme. Based on analysis across enterprise Sentinel deployments, the following categories consistently generate the highest proportion of chargeable ingestion volume:
1. Windows Security Event Logs
Windows Security Event logs are the single largest cost driver for most enterprise Sentinel deployments. The Windows operating system generates thousands of security events per endpoint per day, and ingesting the full event stream at "All Events" or "Common" collection tier creates enormous volumes. For a 2,000-endpoint environment, unconstrained Windows Security Event ingestion can exceed 50 GB/day — approximately £39,000/year at PAYG rates.
The solution is Data Collection Rules (DCRs) — Azure Monitor configurations that filter event types at the agent level before they reach Log Analytics. For most environments, the XPath-filtered collection approach can reduce Windows Security Event ingestion by 60–80% without losing the events relevant to detection rules. The specific events to retain depend on your Sentinel analytics rules, but a well-configured DCR focusing on logon events (4624, 4625, 4768, 4769), process creation (4688), and privileged operation events typically covers 90%+ of detection coverage with 20–30% of the raw volume.
2. Azure Diagnostic Logs
Azure resource diagnostic logs — enabled for every resource in a subscription — generate significant volume in complex Azure environments. The Azure Activity Log (the tenant-level audit trail of resource operations) is relatively low volume and free. The resource-level diagnostic logs — individual storage accounts, Key Vault operations, NSG flow logs, Azure Firewall logs, SQL audit logs — can each generate multi-GB/day volumes depending on activity level.
The governance failure that creates this cost: diagnostic log forwarding is often configured as part of a compliance or monitoring initiative without Sentinel cost visibility. An IT team enabling Key Vault audit logging for security reasons does not typically know or care about the Sentinel ingestion cost. Without cross-team governance that connects diagnostic log enablement to the Sentinel cost model, diagnostic log costs grow silently with the Azure estate.
3. Network and Firewall Logs
Perimeter firewall and network traffic logs are high-volume by nature — every accepted and denied connection generates at least one log entry. Enterprise firewalls in busy network environments generate tens of gigabytes per day. Forwarding all of this to Sentinel is almost never necessary for detection purposes and is frequently the result of a "log everything" philosophy applied without consideration of ingestion economics.
The right approach: ingest deny logs and anomalous traffic logs; route accepted traffic logs to a lower-cost storage tier (Azure Storage with Basic ingestion, or Azure Data Explorer for long-term retention). Detection coverage for network-based threats does not require full accepted-traffic visibility in the Sentinel Analytics engine — it requires anomaly detection, which can operate on sampled or filtered data.
4. Verbose Application Logs
Application logs from custom-built or third-party applications can be highly verbose. Debugging-level log output, audit trails for every user action, and session-level telemetry from high-traffic applications can individually contribute multiple GB/day. These logs are often forwarded to Sentinel as part of a generalised "centralise all logs" initiative rather than a specific security detection requirement. The governance question to ask: is there a Sentinel analytics rule that uses this data, or is it being ingested "just in case"?
Log Tiers: Analytics, Basic, and Archive
Microsoft Sentinel and Log Analytics support three data tiers with different cost and query profiles. Using the right tier for the right data is one of the most impactful single cost optimisation decisions available.
| Tier | Ingestion Cost | Retention | Query Cost | Best For |
|---|---|---|---|---|
| Analytics (Hot) | Standard rate (~£2.15/GB PAYG) | 90 days interactive (default) | None (included) | Active detection, hunting, high-frequency queries |
| Basic Logs | ~£0.65/GB (70% discount vs Analytics) | 8 days interactive | ~£0.86/GB for queries beyond daily free allowance | High-volume, infrequently queried data (verbose firewalls, diagnostics) |
| Auxiliary Logs | ~£0.10/GB (95% discount vs Analytics) | 30 days interactive | ~£0.86/GB per query | Compliance retention, rarely queried verbose data |
| Archive | ~£0.03/GB (for data moved from Analytics) | Up to 12 years | ~£0.10/GB for search jobs | Long-term retention for compliance, rarely accessed |
The practical application: network flow logs, verbose diagnostic logs, and application verbose logs that are retained for compliance but not actively used in detection analytics should be routed to Basic Logs or Auxiliary Logs rather than the Analytics tier. For a 50 GB/day volume of this category of data, the cost difference between Analytics and Basic Logs is approximately £27,000/year — a reduction achievable through a table configuration change, not an architectural redesign.
Detection rules and analytics rules in Sentinel require data to be in the Analytics tier — they cannot query Basic or Auxiliary Logs in real-time. The tier decision therefore requires a clear categorisation of each data source: "do we have active detection rules using this data?" If yes, Analytics tier. If no, Basic or Auxiliary.
Selecting the Right Commitment Tier
The commitment tier decision should be made only after completing the ingestion optimisation work described above. Selecting a tier before optimisation means committing to a cost baseline that includes avoidable waste. The sequence should be: (1) identify and eliminate or re-tier unnecessary ingestion, (2) establish stable baseline ingestion volume over 30+ days, (3) evaluate commitment tier economics against the stabilised volume.
The Break-Even Calculation
For each tier step, calculate the break-even daily ingestion volume — the volume at which the tier's fixed daily cost equals the PAYG cost for that volume. Only select a tier if your average daily ingestion consistently meets or exceeds this break-even point, with sufficient headroom to justify the commitment risk.
For the 100 GB/day tier (~£172/day): break-even at 100 GB/day (by definition). If your average daily ingestion is 95 GB/day, you are slightly under break-even on average — but the tier rate applies to all data including the first 100 GB, so a 95 GB/day average at the 100 GB tier costs exactly the same as a 100 GB/day average. The decision is whether the effective rate saving for the 95 GB you actually consume (£1.72/GB vs £2.15/GB) outweighs the risk of lower-than-average days. For most deployments with stable ingestion at 80–100 GB/day, the 100 GB tier is net positive.
The guidance from our experience across Sentinel deployments: select commitment tiers at 80% of average daily ingestion. This cushion accounts for normal day-to-day variation and protects against waste on quieter days (weekends, holidays) while capturing the tier discount for the bulk of your ingestion volume.
Sentinel Cost Governance: Preventing Cost Creep
The most expensive aspect of Sentinel cost management is not the initial deployment — it is the ongoing cost creep as the Azure estate grows, new data sources are connected, and log verbosity settings are changed without cost visibility. A governance framework that maintains cost discipline is worth more in the long run than any single optimisation.
Monthly Ingestion Review
Review the Sentinel workspace ingestion breakdown monthly using the Microsoft Sentinel: Workspace Usage Report workbook (available in the Sentinel workbook gallery). Identify any data source showing greater than 10% month-on-month volume growth and investigate the cause. Growth that is unexplained or driven by a newly connected data source should trigger a tier classification decision before the next billing cycle.
Data Collection Rule Governance
Every DCR configuration change that increases event verbosity (moving from "Minimal" to "Common" Windows events, adding new XPath queries, disabling event filtering) should require a cost impact assessment before approval. The Sentinel pricing calculator and workspace cost estimate tools can model the impact of a proposed change before it is applied. Without this gate, verbosity creep will gradually inflate ingestion volume.
New Connector Checklist
Any new Sentinel data connector enablement should require a documented answer to four questions: (1) What is the estimated daily ingestion volume? (2) Does a detection rule exist that uses this data, or is a rule being created? (3) Is this data covered by the M365 E5 free benefit or is it chargeable? (4) Should this data be in Analytics or Basic/Auxiliary tier? Without this four-question gate, the connector library grows and so does the bill.
UEBA Licensing Cost: The Often-Missed Component
Microsoft Sentinel's User and Entity Behaviour Analytics (UEBA) feature carries an additional per-user cost beyond standard ingestion. UEBA analyses user activity signals to produce investigation priority scores and entity page enrichment. The cost is approximately £1.97/active user/month for identities analysed by UEBA — this is separate from and additive to ingestion costs.
For large organisations, UEBA costs are meaningful. At 5,000 users with UEBA enabled, the monthly UEBA cost is approximately £9,850/month, or £118,200/year. This cost is often invisible in the initial Sentinel budget because it appears as a separate line item and is enabled by default for all users when UEBA is activated.
The optimisation lever: UEBA scope can be limited to specific user populations or groups. Enabling UEBA only for privileged users (administrators, privileged access workstations), high-risk roles, and users with access to sensitive data — rather than the full user population — reduces UEBA cost by 60–80% for most organisations while retaining coverage for the highest-risk users.
See our companion guide to Microsoft Sentinel licensing and pricing for the full cost component breakdown, including UEBA, automation playbook execution costs, and the relationship between Sentinel and Log Analytics workspace pricing.
Sentinel Cost Optimisation Checklist
- Audit all connected data connectors and classify each as: high-value detection data (Analytics tier), compliance data (Basic/Auxiliary tier), or unnecessary (disable)
- Implement Data Collection Rules for Windows Security Event logs — targeting only the event IDs required by active analytics rules
- Route high-volume, low-detection-value data (verbose firewall logs, accepted traffic logs, diagnostic logs without active rules) to Basic Logs or Auxiliary Logs
- Confirm M365 E5 free ingestion benefit is correctly applied for qualifying data types
- Review interactive retention settings — reduce from default 90 days to a compliance-justified period; move older data to Archive tier at £0.03/GB
- Scope UEBA to high-risk user populations rather than all users; validate UEBA cost vs E5 Security UEBA benefit
- Establish monthly ingestion review process with ownership assigned to security engineering team
- Implement new connector approval gate requiring cost impact assessment before enabling any additional data source
- Select commitment tier only after 30 days of stable, optimised ingestion data — and at 80% of average daily volume to account for variation
- Review commitment tier selection quarterly and adjust as ingestion patterns evolve
Frequently Asked Questions
Does Microsoft Sentinel cost apply to the Log Analytics workspace or to Sentinel separately?
Both. Log Analytics charges for ingestion and retention of data in the workspace. Sentinel has an additional charge for data that is ingested into a Sentinel-enabled workspace. The Sentinel charge is additive to the Log Analytics charge. When comparing Sentinel total cost to alternative SIEMs, ensure both Log Analytics and Sentinel charges are included in the model. The Microsoft Sentinel pricing page in the Azure portal shows the combined cost including both components.
Can Sentinel data be sent to an external storage account to reduce costs?
Yes — Data Export Rules allow log data to be exported from Log Analytics to Azure Storage or Azure Event Hubs. This is appropriate for long-term retention at lower cost than Sentinel's Archive tier in specific scenarios. However, data exported out of Log Analytics cannot be queried through Sentinel analytics rules — it is effectively out of scope for real-time detection. Export is appropriate for compliance archiving; it should not be used as a cost reduction strategy for data that is actively used in detection.
What is the difference between Microsoft Sentinel and Microsoft Defender XDR for cost purposes?
Microsoft Defender XDR (the unified XDR portal covering Defender for Endpoint, Defender for Identity, Defender for Office 365, and MDCA) does not charge based on ingestion. It is included in the relevant product licences (E5, E5 Security). Microsoft Sentinel is a separate SIEM that ingests data from Defender XDR and other sources and has its own ingestion-based pricing. For M365 E5 organisations, Defender XDR provides significant SIEM-adjacent capability at no incremental ingestion cost — reducing the scope of data that must be ingested into Sentinel for investigation purposes.