Explanation
Why the waste happens and who it affects.
Azure Monitor's documentation states that when Sentinel is enabled, all data collected in the workspace is subject to Microsoft Sentinel charges along with Log Analytics charges. Operational telemetry that has nothing to do with threat detection, such as performance counters, application traces, container logs and verbose resource diagnostics, therefore pays the security analytics rate if it lands in the SOC workspace.
This happens through consolidation: a single central workspace is created for everything, Sentinel is later enabled on it, or diagnostic settings and agents across the estate default to the same workspace. Microsoft's guidance is direct: Sentinel's cost reduction page recommends a separate workspace for non-security operations data so it doesn't incur Sentinel costs, and the Azure Monitor cost checklist asks teams to decide deliberately whether to combine operational and security data. The main exception Microsoft notes is when neither data set alone is large enough to reach a commitment tier but the combined volume is.
Billing model
The pricing dimensions that drive this cost.
Sentinel-enabled workspaces are billed on Sentinel meters for the data they receive.
- Analytics tier ingestion
- Billed per GB on pay-as-you-go or through commitment tiers starting at 100 GB per day; on simplified pricing tiers this single Sentinel charge includes Log Analytics ingestion
- Classic pricing tiers
- Older workspaces pay Sentinel analysis charges on top of separate Log Analytics ingestion charges
- Data lake tier
- Lower-cost ingestion, processing, storage and query meters for secondary security data kept out of the analytics tier
- Free data sources
- Some sources, such as Azure Activity logs, Office 365 audit logs and Microsoft security alerts, are not charged
How to detect
4 checks to find it in your estate.
- For each Sentinel-enabled workspace, query the Usage table for billable volume by DataType over the last 30 days and flag large operational tables such as Perf, AppTraces, AppRequests, ContainerLogV2, InsightsMetrics and AzureDiagnostics
- Use Log Analytics workspace insights to see billable data by table and by source resource, and identify which resources and data collection rules send operational data to the SOC workspace
- Review diagnostic settings and data collection rules that target the Sentinel workspace for categories used only for application or infrastructure monitoring
- Check whether operational data is in the same workspace only to reach a commitment tier, by comparing security-only volume with the lowest commitment tier
How to fix
5 ways to remove the waste.
- Create a separate Log Analytics workspace without Sentinel for operational monitoring and repoint diagnostic settings, Azure Monitor Agent data collection rules and Application Insights resources to it
- Move lower-fidelity or secondary security data that is not needed for real-time detection to the Sentinel data lake tier under Data management, Tables
- Filter Windows Security Events and other agent-collected sources with data collection rules so only the events used by detections are ingested
- Recheck the commitment tier after moving data, since the analytics volume will drop; lowering a commitment tier is allowed only after the 31-day commitment period
- Keep cross-workspace queries in mind: splitting workspaces means some investigations must query both, which Sentinel and Log Analytics support
Documentation
Vendor references for pricing and configuration.