| |

Microsoft Sentinel Cost Optimisation: A Complete Engineer’s Guide for 2026

Microsoft Sentinel · Cost Optimisation

Microsoft Sentinel Cost Optimisation: A Complete Engineer’s Guide for 2026

Sentinel billing can be unpredictable and expensive if not managed deliberately. This guide covers every lever available to reduce your Sentinel costs without compromising detection coverage — from workspace architecture to data ingestion filtering to commitment tier selection.

Understanding the Sentinel Billing Model

Sentinel pricing has three components, and confusing them is the root cause of most budget surprises. Understanding each one is the prerequisite for any optimisation work.

Log Analytics Workspace Ingestion

This is typically 60–80% of your total Sentinel cost. You are charged per gigabyte of data ingested into your Log Analytics workspace. The pay-as-you-go rate is £2.76 per GB (UK, May 2026) but commitment tiers can reduce this to as low as £1.38 per GB for workspaces ingesting 100GB/day or more.

Key point: you pay for ingestion, not for retention up to 90 days for Analytics tier tables. Retention beyond 90 days is billed separately at the archive rate.

Microsoft Sentinel Capacity Reservation

In addition to Log Analytics ingestion costs, Microsoft Sentinel charges a separate capacity fee for the SIEM layer — analytics rules, incident management, UEBA, threat intelligence, and so on. This is also billed per GB of billable data ingested into the workspace, but at a separate rate. For workspaces under 100GB/day, this is the pay-as-you-go rate of approximately £2.30/GB. Commitment tiers exist here too.

Free Data Sources

Not all data ingested into Sentinel is billable. Microsoft provides the following at no additional ingestion cost: Microsoft Defender for Office 365 alerts, Microsoft Entra ID (basic sign-in and audit logs up to a threshold), Microsoft Defender for Endpoint alerts (not raw device telemetry), and Azure Activity logs. Maximising your use of free data sources is the easiest cost reduction win.

Common mistake: Many organisations ingest raw Defender for Endpoint device telemetry (DeviceProcessEvents, DeviceNetworkEvents, etc.) into Sentinel when they already have this data in Defender XDR. This can add 15–40GB/day of billable ingestion for no additional detection value. Review your connector configuration carefully.

Analytics vs Basic vs Auxiliary Tiers

The introduction of the Basic and Auxiliary ingestion tiers in 2024–2025 fundamentally changed the cost optimisation landscape for Sentinel. Understanding when to use each tier is now one of the most valuable skills a Sentinel architect can have.

Analytics Tier

The standard, full-feature tier. Data in Analytics tier tables can be queried in real time, used in analytics rules, referenced in hunts, and retained for up to 90 days at no additional cost (beyond ingestion). This is appropriate for: high-value security tables (SigninLogs, SecurityEvent, DeviceProcessEvents), any table you run scheduled analytics rules against, and data you need to pivot on during active investigations.

Basic Tier

Introduced to address the cost problem of high-volume, low-query-frequency data. Basic tier tables cost approximately 65% less to ingest than Analytics tier tables. The trade-offs: you cannot use Basic tier data in analytics rules or UEBA, interactive queries are limited, and data is retained for only 8 days by default.

Best for: verbose firewall logs where you only need data during an active investigation, network flow data (CommonSecurityLog from high-volume firewalls), proxy and web filter logs, and verbose application logs that are rarely queried.

Auxiliary Tier

The newest tier, designed for compliance and archival use cases. Even lower ingestion cost than Basic, but effectively read-only — you cannot run analytics rules or perform interactive queries against Auxiliary data without first running a Search Job to bring it into an Analytics-compatible format.

Best for: long-term retention of compliance data, archiving historical logs beyond your Analytics retention window, and data you need to be able to retrieve but will rarely actively analyse.

KQL — Identify Tables by Daily Ingestion Volume
Usage | where TimeGenerated > ago(30d) | where IsBillable == true | summarize TotalGB = round(sum(Quantity) / 1024, 2) by DataType | order by TotalGB desc | take 20

Run this query monthly to identify your top cost contributors. Tables consistently in your top 5 but rarely queried are the best candidates for tier downgrade.

Data Ingestion Reduction Strategies

Before changing tier configurations, look for opportunities to reduce the volume of data you actually ingest. Every gigabyte you don’t ingest costs nothing and requires no storage tier management.

DCR-Based Filtering with Transformation Rules

Data Collection Rules (DCRs) with transformation support let you filter and transform data at the ingestion point — before it reaches your workspace and before you’re billed. This is the most powerful cost reduction tool available, and it’s still underutilised by most organisations.

KQL Transformation — Filter Low-Value Windows Events
source | where EventID in (4624, 4625, 4648, 4672, 4688, 4698, 4720, 4728, 4732, 4756, 4768, 4769, 4771) | where not (EventID == 4624 and LogonType == 3 and AccountName endswith "$")

This transformation retains only the most security-relevant Windows event IDs and drops the machine-account network logon noise that makes up a large proportion of Windows Security event volume in domain-joined environments. In large organisations, this alone can reduce Windows Security event ingestion by 40–70%.

Verbose Log Source Review

The following log sources are consistently the worst offenders for unnecessary volume:

  • Firewall/NSG logs: Log only Deny actions and anomalous Allow patterns. Logging all Allow traffic from internal subnets is usually unnecessary and expensive.
  • DNS logs: Consider logging only query failures and queries to newly registered domains rather than all DNS activity.
  • Windows Security Audit logs: Disable verbose audit categories (Object Access, Detailed Tracking) on workstations unless you have a specific detection use case that requires them.
  • IIS/web server logs: Log only error responses (4xx, 5xx) plus specific GET/POST patterns relevant to your application security requirements.

Duplicate Data Elimination

Organisations that have both Microsoft Defender for Endpoint and Microsoft Sentinel connected frequently ingest duplicate data. The most common example: raw device events (DeviceProcessEvents, DeviceNetworkEvents) ingested into Sentinel when the exact same data is already available through Defender XDR’s native query interface. If you use Defender XDR for your endpoint investigations, consider removing the Advanced Hunting connector for device telemetry and saving 10–25GB/day.

Commitment Tier Selection

Commitment tiers offer significant discounts in exchange for a 24-hour or 31-day minimum commitment to a daily ingestion volume. Choosing the right tier requires accurate forecasting of your daily ingestion volume.

KQL — 30-Day Average Daily Ingestion
Usage | where TimeGenerated > ago(30d) | where IsBillable == true | summarize DailyGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d) | summarize AvgDaily = round(avg(DailyGB), 1), MaxDaily = round(max(DailyGB), 1), P90Daily = round(percentile(DailyGB, 90), 1)

Use the P90 value (90th percentile) rather than the average for commitment tier selection. This ensures your commitment tier covers your typical peak ingestion while avoiding overage charges on your highest outlier days.

As a rule of thumb: if your P90 daily ingestion is consistently within 10% of a commitment tier boundary (e.g., consistently between 45–55GB/day when the tier boundaries are 50GB and 100GB), choose the lower tier and accept occasional pay-as-you-go overage. The overage cost at pay-as-you-go rates is almost always cheaper than committing to the higher tier.

Workspace Design for Cost

Workspace architecture decisions made at deployment time are difficult to reverse and have long-term cost implications. These are the principles I apply when designing new Sentinel deployments:

Single vs. Multi-Workspace

Microsoft’s default recommendation has shifted toward single-workspace deployments for most organisations. The operational complexity of multi-workspace Sentinel (cross-workspace queries, split detection coverage, duplicated analytics rules) rarely justifies the cost savings. The exception: organisations with strict data residency requirements that mandate geographic separation of log data.

Dedicated Sentinel Workspace

Avoid sharing your Sentinel workspace with non-security workloads. Application logs, infrastructure monitoring data, and development environment telemetry in the same workspace as your security data creates three problems: cost unpredictability (spikes from non-security sources affect your Sentinel commitment tier), query noise (non-security tables appear in all queries and autocomplete), and access control complexity (security data has different access requirements than operational data).

Cost Monitoring & Alerting

Cost optimisation is not a one-time project — it requires ongoing monitoring. Set up these three alerts in your Azure environment:

KQL — Daily Ingestion Anomaly Alert
Usage | where TimeGenerated > ago(2d) | where IsBillable == true | summarize DailyGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d) | order by TimeGenerated desc | extend PrevDay = prev(DailyGB, 1) | extend PctChange = round(((DailyGB - PrevDay) / PrevDay) * 100, 1) | where PctChange > 30 | project TimeGenerated, DailyGB, PrevDay, PctChange

Schedule this as a medium-severity analytics rule. A 30%+ day-over-day ingestion spike is almost always caused by a misconfigured connector or a new data source being added without a corresponding budget allocation.

Cost Optimisation Checklist

Quick Win Actions (Week 1)

  • Run the ingestion volume query and identify your top 5 cost contributors
  • Check whether any Defender XDR device telemetry tables are being duplicated in Sentinel
  • Review all DCRs — are Windows Security Event filters applied?
  • Confirm free data sources (Defender alerts, Entra ID) are connected and not being duplicated via paid paths

Medium-Term Actions (Month 1)

  • Evaluate firewall and network flow tables for Basic tier migration
  • Calculate P90 daily ingestion and review commitment tier alignment
  • Implement DCR transformation rules for Windows Security events
  • Set up the daily ingestion anomaly alert
  • Review verbose log sources and adjust audit policies

Need help designing a cost-efficient Sentinel architecture for your organisation? I offer Sentinel architecture consultancy and can review your current setup to identify the highest-impact cost reduction opportunities.

Sujit Mahakhud

Microsoft Sentinel Expert · 8+ years in cybersecurity · SOC architect, detection engineer, and hands-on trainer specialising in Azure Security and Microsoft Sentinel.

View Full Profile →

Similar Posts

Leave a Reply