Microsoft Sentinel Cost Optimization: Data Tiers, Workspace Design, and Log Ingestion Strategy
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most Sentinel deployments spend their first year on pay-as-you-go pricing with no data tier strategy, ingesting every available log table from every connector. The first cost optimization review typically reveals that 20-30% of ingested volume comes from 3-5 high-volume tables with low detection value. Addressing those tables and switching to the correct commitment tier can reduce Sentinel costs by 40-60% with no reduction in detection coverage.
Understanding Sentinel's Three Data Tiers
Sentinel has three log tiers with different prices and capabilities. Assigning each table to the correct tier is the primary cost optimization lever.
Analytics Logs: the default tier for security-relevant tables
Analytics Logs is the full-featured SIEM tier: tables in this tier support scheduled analytics rules (detection queries that run every 5 minutes), workbooks, hunting queries, and the full 31-day default retention window. Price: approximately $2.46/GB ingested. Use for: SecurityEvent, SigninLogs, AuditLogs, DeviceEvents, CommonSecurityLog, Syslog (servers), and any table referenced by active detection rules.
Basic Logs: query-on-demand for high-volume low-detection-value tables
Basic Logs is approximately 80% cheaper than Analytics Logs ($0.50/GB vs $2.46/GB for a 100 GB/day workspace). Limitations: tables in Basic Logs cannot be used in scheduled analytics rules, only in manual KQL queries with a 30-day maximum query window. Use for: verbose DNS query logs, network flow logs, raw web proxy logs, verbose endpoint telemetry tables (DeviceNetworkEvents when not actively hunting). You can still hunt these tables manually: you just cannot run scheduled detections on them.
Auxiliary Logs: archival storage at near-zero cost
Auxiliary Logs is the cheapest tier (approximately $0.08/GB) but has the most limitations: queries require a transformation step and cannot be used for real-time detection or hunting. Use for: compliance archival (firewall logs retained for 7 years for PCI DSS), historical forensic data that you only query during investigations, and log sources that have regulatory retention requirements but zero operational detection value.
How to change a table's tier
In the Azure Portal: Log Analytics Workspace > Tables > find the table > Manage > change Data Type from 'Analytics' to 'Basic' or 'Auxiliary'. The change takes effect for new data; historical data in the table retains its original tier and retention settings. Before moving a table to Basic Logs, verify it is not referenced by any active Sentinel analytics rule: run SHOW TABLES REFERENCED IN ACTIVE RULES against the workspace.
Commitment Tiers: The Highest-Impact Single Change
If your workspace ingests more than 100 GB/day, switching from pay-as-you-go pricing to a commitment tier is the single highest-ROI cost optimization: typically 15-30% savings per GB for the first tier step.
Calculate your current daily ingestion volume
Run this KQL query to get your 30-day average daily ingestion: Usage | where TimeGenerated > ago(30d) | summarize avg(Quantity) by DataType | order by avg_Quantity desc. Sum the total to get your average daily GB. This shows the top tables by volume: the starting point for both tier selection and high-volume table investigation.
Select the commitment tier that matches your usage
Commitment tiers: 100 GB/day, 200 GB/day, 300 GB/day, 400 GB/day, 500 GB/day, 1000 GB/day, 2000 GB/day, 5000 GB/day. Select the tier just above your current average daily volume: if you average 180 GB/day, choose the 200 GB/day tier. Overages beyond the committed amount are charged at the per-GB rate, so it is acceptable to pick slightly above current usage for headroom. Commitment tiers require a 31-day minimum commitment but can be changed up or down after that period.
Apply commitment tiers to Microsoft Defender integrations
Workspaces using the Microsoft Sentinel + Microsoft Defender for XDR integration get a data grant for data ingested from Defender products (MDVM, MDE, MDO, MDA, MDI). The grant amount scales with the Sentinel commitment tier: higher commitment tiers receive larger Defender data grants. Verify the grant is applying: the Usage table shows ingestion with a zero-charge flag for granted data. Misconfigured Defender integrations that are not using the grant are the most common billing surprise.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Data Collection Rules: Filter Before Ingestion
Data Collection Rules (DCRs) process log data before it reaches the workspace. Filtering at the DCR avoids the ingestion cost entirely: unlike KQL queries, which filter after the cost has already been incurred.
Filter Windows Security Events to high-value event IDs
The default Windows Security Event connector ingests all event IDs. Many are low value for detection. Use a DCR transformation to filter: source: SecurityEvent | where EventID in (4624, 4625, 4648, 4656, 4663, 4670, 4688, 4698, 4702, 4719, 4720, 4726, 4728, 4732, 4735, 4740, 4756, 4767, 4776, 4798, 4799, 7045) | project TimeGenerated, EventID, SubjectUserName, TargetUserName, Computer. This retains the event IDs used by most Sentinel analytics rules while discarding verbose events (4634 logoff, 4648 explicit credential, noise events from highly active systems).
Drop DNS query logs for internal resolution traffic
DNS logs are high volume: a mid-size network generates millions of DNS queries per day, the vast majority of which are internal resolution requests with no detection value. DCR transformation: DNSEvents | where Computer !startswith 'internal-dns' OR QueryType != 'A' OR DnsQuery !endswith '.internal.corp'. This drops all normal internal A record lookups while retaining external queries, unusual query types (TXT, MX), and failed lookups: which are the detection-relevant subset.
Sample verbose telemetry tables for hunting workloads
For tables that are too valuable to move to Basic Logs (they ARE referenced by rules) but too verbose for full ingestion, use DCR-based sampling: take 10% of events from noisy table partitions. Source transformation: NetworkCommunicationEvents | where rand() < 0.1 OR RemotePort in (22, 443, 445, 3389, 4444, 8080). This ingests 10% of benign-pattern events but always ingests events on known attack ports. Sampling reduces cost while preserving the detection signal.
Workspace Architecture for Multi-Team Environments
Sentinel workspace architecture decisions affect both cost and operational complexity. The right architecture depends on team structure, compliance requirements, and data sovereignty constraints.
Single workspace is cheaper and operationally simpler
A single Sentinel workspace with a single commitment tier is easier to manage, avoid cross-workspace query costs (which are charged at the Analytics Logs per-GB rate), and is sufficient for most organizations up to 2,000 employees. Create separate resource groups per team for cost allocation without creating separate workspaces. Use workspace-level RBAC and Azure Monitor roles to limit which teams can see which tables.
Regional workspaces for data sovereignty requirements
If your organization operates across regions with data residency requirements (EU GDPR requiring EU data to stay in the EU, India PDPB, Australian Privacy Act), create separate workspaces in each required region. This increases management overhead but satisfies data locality requirements. Cross-region queries are expensive and latency-sensitive: scope detection rules to their local workspace rather than querying cross-workspace.
Use the Sentinel Cost Management Workbook to track spend
Deploy the built-in Sentinel Cost Management workbook (Sentinel > Workbooks > Sentinel Central > Cost Management): it shows daily ingestion by table, projected monthly cost, commitment tier utilization, and tables that could be moved to Basic Logs based on their usage in detection rules. Review this workbook monthly to catch ingestion spikes from newly deployed connectors.
The bottom line
The three actions that reduce most Sentinel cost with the least detection risk: (1) switch to the correct commitment tier if you are above 100 GB/day on pay-as-you-go: this alone saves 15-30% immediately; (2) move high-volume tables not referenced by active analytics rules to Basic Logs (DNS verbose, raw flow, verbose endpoint telemetry): this often saves another 20-30%; (3) deploy DCR transformations on Windows Security Events to filter event IDs the rules do not use. Together, these three changes typically reduce a Sentinel environment's cost by 40-60% in the first quarter of optimization work without removing a single active detection rule.
Frequently asked questions
What is the difference between Microsoft Sentinel and Log Analytics Workspace pricing?
Microsoft Sentinel and Log Analytics Workspace have separate pricing components that combine. Log Analytics Workspace charges for data ingestion and retention. Microsoft Sentinel charges an additional per-GB ingestion fee on top of the Log Analytics cost for any data used by Sentinel features (analytics rules, hunting, etc.). The effective combined cost is approximately $2.46/GB (Sentinel + Log Analytics) for data in the Analytics Logs tier at pay-as-you-go pricing. When you commit to a Sentinel commitment tier, you pay a flat daily rate for Sentinel's component that includes a per-GB credit; Log Analytics ingestion is separate. Always model both costs together when comparing tiers.
What tables should I move from Analytics Logs to Basic Logs first?
Priority candidates for Basic Logs: AzureDiagnostics from non-security resources (Azure PaaS resource diagnostics that are not referenced in Sentinel rules), raw DNS query logs (verbose, high-volume, manually huntable), NetFlow/NSGFlowLogs (very high volume; useful for hunting but rarely in analytics rules), verbose endpoint network events (DeviceNetworkEvents for benign process/port combinations), and storage access logs from low-risk storage accounts. Verify each table is not referenced by active Sentinel analytics rules before moving: a broken rule is worse than a high cost.
How do I identify which log tables are causing my ingestion spikes?
Run: Usage | where TimeGenerated > ago(7d) | summarize TotalGB = sum(Quantity)/1024 by DataType, bin(TimeGenerated, 1d) | order by TotalGB desc. This shows daily ingestion in GB per table for the past 7 days. Compare the last 24 hours against the 7-day average to identify newly elevated tables. Newly deployed connectors, verbose debug logging enabled by an application change, or a newly onboarded data source are the typical causes of spikes. Sentinel's Ingestion Anomalies workbook automatically alerts on tables with ingestion 50% above their 7-day baseline.
Can I still use Basic Logs tables for threat hunting?
Yes. Tables in Basic Logs can be queried manually using KQL in Sentinel's Log Analytics interface with a 30-day query window. The limitations compared to Analytics Logs: (1) you cannot run scheduled analytics rules against Basic Logs tables: no automatic detection; (2) query cost is charged per-GB queried rather than a flat rate ($0.006/GB scanned vs. included in Analytics Logs); (3) Basic Logs queries have a 30-day maximum lookback. For a hunting workflow where an analyst manually searches DNS logs for tunneling indicators after an alert fires, Basic Logs is appropriate and significantly cheaper than Analytics Logs.
What is a Data Collection Rule transformation and how does it filter data?
A Data Collection Rule (DCR) transformation is a KQL expression applied to incoming data before it is written to the Log Analytics workspace. The transformation runs in the Azure Monitor data pipeline, before the data costs any ingestion credit: data dropped by a DCR transformation is never charged. DCR transformations support: filter (WHERE clause to drop events), parse (extract fields from messages), rename fields (normalize column names), and enrich (add columns based on logic). Transformations are applied per data collection rule, which can be associated with one or more data sources. They do not support joins against workspace tables at transformation time: transformations can only reference the current event's fields.
How does the Microsoft Defender data grant work with Sentinel commitment tiers?
The Microsoft Defender data grant provides free ingestion into Sentinel for data from Microsoft security products (MDE, MDO, MDI, MDCA, MDVM) when both Sentinel and Defender licenses are active. The grant amount scales with your Sentinel commitment tier: 100 GB/day Sentinel tier gets a 1:1 data grant for Defender data; higher tiers get proportionally larger grants. The grant applies automatically: you do not need to configure it, but you should verify it is active by checking the Usage table for zero-charge Defender events. If Defender data is appearing with a charge, verify that your Sentinel and Defender tenants are linked correctly in the Security Center connector settings.
What is the most common Sentinel cost mistake organizations make?
The most common mistake is ingesting the AzureDiagnostics table from all Azure resources without filtering. AzureDiagnostics is a catch-all table that receives diagnostic data from dozens of Azure resource types: many of which have zero security value (Azure SQL Database query performance advisors, Azure Cache for Redis client connections, App Service HTTP logs from non-security-relevant applications). This table routinely appears as the top volume contributor in cost audits, often contributing 30-50% of daily ingestion volume. The fix: in the Diagnostic Settings for each Azure resource, enable only the specific diagnostic categories that have detection value rather than enabling all categories.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.