Journal ·Economics
Why Sentinel Commitment Tiers Do Not Work for MSPs
Sentinel prices commitment tiers per workspace with no ability to pool across tenants. For MSPs managing 30 clients, that means 30 separate cost buckets with no optimization. Here is what a pipeline layer changes.
Zbigniew Gajuk · 2026-03-07 · 1 min read
For: CFO and FinOps
The per-workspace problem
Microsoft Sentinel prices commitment tiers per workspace per day. For an MSP with 30 clients, that means 30 separate commitment tiers with no ability to pool unused capacity. Over-provisioned workspaces waste budget. Under-provisioned workspaces trigger pay-as-you-go overflow rates. There is no optimization across the portfolio.
The rule cap
Analytics rules are capped at 512 per workspace. For MSPs running dozens of detection rules per client across multiple threat models, that cap becomes a constraint. Cross-workspace queries are recommended for a maximum of 5 workspaces before performance degrades, limiting correlation across tenants.
Basic Logs limitations
Basic Logs offer a cheaper tier but with severe constraints: 8-day retention and per-query charges make them unsuitable for investigation. Auxiliary Logs are cheaper still but nearly unusable for any analytical purpose. The tiering options within Sentinel do not solve the underlying cost architecture.
What a pipeline layer changes
A Cribl pipeline tiers data before it enters Sentinel. High-value security events flow to the Analytics tier. Verbose operational data routes to Azure Blob storage. Each workspace consumes less of its commitment tier because noise never reaches Sentinel. Cribl pre-normalizes to ASIM schema, reducing the number of analytics rules consumed on parsing edge cases.