Introduction
Costs associated with Microsoft Sentinel can quickly become excessive if your logs are miscategorized or unnecessary volumes are ingested into expensive storage tiers. This article guides you through precise optimization to reduce these expenses: adjust ingestion rules, sort data by importance, and validate your savings using KQL.
[IMAGE:index:images/sentinel-cost-path.svg:Microsoft Sentinel cost flow]
Good to know
Microsoft Sentinel primarily bills based on the ingestion level, called "tier", and not solely based on the total amount of stored data.
Prerequisites
Before following this guide, ensure you have the following:
- An active Azure subscription with Microsoft Sentinel integrated: adjustments and table choices only impact if your workspace is configured.
- Log Analytics Contributor and Data (manage) permissions in the Defender portal: necessary to modify table rules and apply transformations.
- Azure CLI installed and a KQL compatible shell: some steps work better via scripts.
- At least one noisy source in your Sentinel workspace: the most immediate results come from reducing excessive volumes at the table level.
Step 1: Analyze Costs
Begin by examining your data volumes and their storage tiers. Microsoft Sentinel divides costs into several axes:
| What to check | Why it matters | What changes often |
|---|---|---|
| Ingestion to Analytics tier | The expensive path for active detections and investigations | Most noisy table |
| Retention | Unnecessary data costs long after its useful life | Old tables rarely queried |
| Commitment tier | Regular volume can reduce unit fees | Teams with stabilized volumes |
| Dedicated cluster | Shared clusters group regional volumes | Large domain with multiple workspaces |
Practical Analysis with KQL
Identify tables consuming the most storage using the following examples:
1Usage2| where TimeGenerated > ago(7d)3| where IsBillable == true4| summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by DataType5| top 10 by GB descThis allows you to rank tables by billed volume. Next, analyze hourly growth patterns to target the most problematic sources:
1Usage2| where TimeGenerated > ago(24h)3| where IsBillable == true4| where DataType in ('SecurityEvent', 'CommonSecurityLog')5| summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by bin(TimeGenerated, 1h), DataType6| order by TimeGenerated ascWarning
Incorrect filtering can result in loss of important data. Always test your transformations on small volumes before full implementation.
Step 2: Filter Data Before Ingestion
Apply filtering rules using Data Collection Rules (DCR) to block unnecessary events before they are billed. Here is an example of a simple transformation:
1{2 "transformKql": "source | where EventID in (4798, 4799)"3}Severity-Based Routing
If you want to classify data by severity instead of removing it, use routing logic as shown below:
1source2| extend Route = iif(Severity in ('High', 'Critical'), 'Analytics', 'DataLake')3| project TimeGenerated, Computer, Severity, RouteStep 3: Assign the Right Data to the Right Tiers
Once flows are cleaned, configure your storage levels based on data relevance.
| Tier | Usage | What you lose |
|---|---|---|
| Analytics | Primary data for active detections, investigation | Highest cost |
| Basic | Tables queried without real-time alerts | Less interactive depth |
| Data Lake | Secondary data for long-term retention | No real-time alert capability |
Tip
Data rarely queried or post-incident is a good candidate for Basic or Data Lake tiers.
Step 4: Validate and Deploy in Order
Validation is essential for achieving measurable savings. Proceed as follows:
Verify current billing model
Ensure that the model on the billing page matches the table configuration plans.
Use available free data
Reduce billable bytes where free sources apply.
Filter the noisiest sources
Apply DCR logic to tables identified as the most bulky to reduce volumes.
Reassign secondary data to cost-effective tiers
Ensure alert coverage remains intact for important information.
Review clusters or tier after stabilization
Organize clusters or adjust tier commitments once volumes are fixed.
Conclusion
Reducing ingestion costs in Microsoft Sentinel requires a methodical approach: examine current costs, filter unnecessary data, assign each data type to the appropriate tier, and validate savings with KQL. Follow this order to avoid unnecessary expenses while maintaining your security level.
[IMAGE:index:images/sentinel-tier-decision.svg:Sentinel tier decision]
