A Practical, Detection-First Guide to Reducing Cost Without Weakening Security

Microsoft Sentinel is often described as expensive.

In most real-world environments, Sentinel becomes expensive not because of the platform — but because of architecture decisions.

Cost typically increases due to:

• Unclassified log ingestion
• Overuse of Analytics Tier
• No table-level retention strategy
• Lack of Data Collection Rule (DCR) filtering
• Inefficient KQL execution
• Compliance misunderstanding

This guide presents a practical, Microsoft-aligned cost engineering framework grounded in real Sentinel tables, operational tradeoffs, and compliance realities.

Last verified against Microsoft documentation: Feb 2026

---

1️⃣ Understanding What Actually Drives Sentinel Cost

Official pricing reference:
https://azure.microsoft.com/en-us/pricing/details/microsoft-sentinel/

Sentinel cost is primarily driven by:

• Analytics Tier ingestion (GB/day)
• Analytics retention beyond included period
• Long-term storage (Data Lake / Archive)
• Query compute behavior

Cost engineering begins with classification — not deletion.

---

2️⃣ High-Volume Logs in Analytics Tier — Practical Handling

One of the most common cost drivers is ingesting full high-volume telemetry into Analytics Tier without classification.

The issue is not that logs exist.
The issue is that they are not separated by detection value.

---

🔹 Firewall Logs — A Practical Example

Example tables:

• AzureDiagnostics
• AzureFirewallNetworkRule
• AzureFirewallApplicationRule

Firewall telemetry generally includes:

• Allow traffic
• Deny traffic
• Threat intelligence matches
• Informational/system logs

The correct approach is tier separation.

Practical Tier Strategy

Analytics Tier

• Deny actions
• ThreatIntel matches
• High-risk outbound connections
• Events referenced in analytics rules
• Indicators tied to active detections

Data Lake

• Allow traffic
• Detailed session logs
• Investigation-driven telemetry

Archive (if required)

• Compliance-driven retention

---

🔹 DNS Logs — Clarified

Common tables:

• DnsEvents
• DeviceNetworkEvents (Defender XDR)

DNS telemetry is extremely high volume.

Analytics Tier

• Queries to newly registered domains
• Suspicious TLD patterns
• DNS tunneling indicators
• Queries to known malicious domains

Data Lake

• Full DNS resolution logs
• Normal internal traffic
• Long-term query history

---

3️⃣ Compliance Reality — Retention Is Not Optional

Many organizations must comply with:

• PCI-DSS
• ISO 27001
• SOX
• NIST frameworks

Compliance requires retention. It does not require keeping everything in Analytics Tier.

Practical Compliance-Aware Strategy

Purpose	Recommended Tier
Active detection window	Analytics Tier
Investigation lifecycle	Data Lake
Long-term regulatory retention	Data Archive

---

4️⃣ Analytics Retention — Practical Enterprise Baseline

A practical baseline for many organizations:

• 90–120 days in Analytics Tier
• Extended retention in Data Lake
• Archive for regulatory obligations

Analytics Tier should cover your active detection and investigation window — not your compliance window.

---

5️⃣ CommonSecurityLog — Handle With Care

CommonSecurityLog is frequently one of the highest ingestion contributors. Retention decisions for this table must not be volume-driven alone.

• Identify which categories power detections
• Keep those within your defined Analytics investigation window
• Route non-detection telemetry to Data Lake
• Archive only if regulation requires

---

6️⃣ Basic Logs — When They Make Sense

Basic Logs are appropriate for:

• Verbose firewall allow logs
• High-volume DNS allow events
• Web proxy allow telemetry
• Informational diagnostic logs

Do not move identity or authentication failure logs to Basic Logs.

---

7️⃣ KQL Time Range Optimization — Severity-Based

Instead of using fixed long windows, tune by severity:

• High severity: 5–15 minute lookback
• Medium severity: 15–60 minute windows
• Lower severity anomaly: 1–3 hour windows

---

8️⃣ Data Collection Rules (DCR) — Core Cost Lever

DCRs allow event-level filtering, field transformation, log routing, and noise reduction. DCRs are often the single biggest cost-control mechanism in Sentinel.

---

9️⃣ Data Lake Promotion Strategy

In hybrid scenarios: run hunting queries in Data Lake, promote findings to Analytics Tier, then temporarily enable detections. This allows historical coverage, detection control, and cost efficiency.

---

🔟 Realistic Cost Modeling Approach

1. Use the Usage table to identify high-ingestion tables
2. Classify by detection value
3. Apply DCR filtering
4. Adjust retention strategy
5. Re-measure ingestion after 30 days

---

Final Cost Engineering Checklist

Architecture

• ⬜ Detection tables clearly identified
• ⬜ Investigation telemetry separated
• ⬜ Compliance retention mapped

Ingestion

• ⬜ DCR filtering implemented
• ⬜ High-volume logs classified
• ⬜ Basic Logs evaluated

Detection

• ⬜ Query windows severity-based
• ⬜ Rule frequency reviewed
• ⬜ Heavy joins minimized

Retention

• ⬜ 90–120 day Analytics baseline (contextual)
• ⬜ Data Lake used for extended investigation
• ⬜ Archive used for regulatory retention only

---

Final Architect Perspective

Microsoft Sentinel does not become expensive by default. It becomes expensive when storage tiers are misunderstood, detection and compliance are mixed, ingestion is not classified, and query design is ignored.

Cost engineering is architecture discipline applied to telemetry.

When done correctly, Sentinel becomes predictable, scalable, and operationally efficient — without weakening security posture.

---