Cutting Microsoft Sentinel cost without blinding your detections
By Matthew Gray on Oct 6, 2026
Most of a Microsoft Sentinel bill is ingestion, and the usual ways to cut it are cheaper table plans, ingest-time filtering and moving old data out of the workspace. For a regional healthcare group we found that each of these can do exactly what its change record says while quietly damaging something else: in one case, 33 of the workspace’s 83 detections were running against no data. Measure the detections and the whole bill after every change, not only the setting you changed.
Where the money goes
The client’s central Sentinel workspace was ingesting about 1,365 GB a month. At East US 2 list prices, a table on the Analytics plan in a Sentinel workspace costs about $4.76 per GB ($2.76 for Log Analytics plus a $2.00 Sentinel uplift). The Basic plan costs about $0.50 per GB. With a gap that large, the spreadsheet answer is obvious. Our first assessment estimated about $32K a year in savings from moving four high-volume tables to Basic.
What happened next is why this post exists.
Lesson 1: a cheaper plan can silently drop a table out of your rules
The documented position at the time was that scheduled analytics rules can query Basic tables within a 30-day window, with some operator restrictions. Our first assessment repeated it and called the detection impact “minimal”. The client pushed back on three of the four tables, so they stayed on Analytics in the final plan. That was the right call, for more reasons than anyone knew then.
Six weeks after the changes, we ran a follow-up audit. In that workspace, the query path that scheduled rules use rejected Basic-plan tables. Microsoft’s rule templates and ASIM parsers wrap their sources in union isfuzzy=true, so a table that can’t be queried is skipped without an error. The rule “succeeds” on every run, against an empty dataset.
Several security tables, including SecurityEvent and SigninLogs, were on Basic in the live workspace, against the design. This predated our changes, but nobody had reconciled it with the rules that depended on those tables. The result:
- 33 of 83 enabled detections were evaluating nothing.
- The DNS and threat-intelligence rules had produced zero alerts in 180 days.
- Sentinel health monitoring had never been enabled, so nothing could tell “no threats” apart from “rules silently failing”.
We moved SecurityEvent and SigninLogs back to Analytics with 90-day retention. That restored 23 of the 33 affected rules for about $330 a month and put 5.1 million security events back in front of the detections. The client accepted the remaining 10 as a documented, signed risk decision, because restoring them would cost far more.
How to check yours: for every enabled rule, list the tables it reads (including through parsers), then compare that list with each table’s plan. Run a rule’s query through the same API path that rules use, and check whether it returns rows. Turn on Sentinel auditing and health monitoring. It is the control that would have surfaced this within a day.
Lesson 2: measure before you split a workspace
The original request was to split the workspace in two, one for security data and one for everything else, so that non-security data would stop paying the Sentinel uplift. It is a common recommendation, and it rests on an assumption that is easy to test.
We ran a 90-day classification of every billable table. Of 4,110 GB ingested, 0.10 GB was not security-relevant. That is 99.997% security data. A split would have created an empty workspace and saved about nothing.
We told the client that plainly. We still recommended the split, for a different reason: governance. The new workspace has no Sentinel, a 5 GB-a-day cap, and a routing rule saying non-security workloads go there by default. It is cheap insurance against application telemetry slowly filling up the SIEM. We just didn’t present it as a cost saving.
Lesson 3: a filter can work perfectly while the bill goes up
DNS activity was one of the largest tables. We added a data collection rule (DCR) ingest transform that dropped lookups for five high-volume Microsoft suffixes. After a 10-day soak, it was doing exactly what it should:
| What we measured | Before | After |
|---|---|---|
| Targeted suffixes (each) | baseline | down 99.0–99.4% |
| Untargeted DNS events per day | ~13.8M | ~23.5M |
| Whole table, GB per day | 6.23 | 7.40 |
The filter worked, and total volume still rose about 19%. Two things the filter didn’t target had grown. One workload’s DNS lookups went up roughly sevenfold, which is an application issue that filtering would only have hidden. And Microsoft telemetry was arriving under other suffixes (*.trafficmanager.net, *.cloud.microsoft) that the original list didn’t cover.
If we had measured only the targeted suffixes, we would have reported a win. Measure the whole table against a baseline, and look at the top untargeted queries after every change.
We also got the process wrong. The change record called for a security-lead review and a detection-fire test before the filter went live, and neither happened first. We recorded that openly and made both gates mandatory before any filter expansion. Filtering a security table is a detection change as well as a cost change.
Lesson 4: long-term retention belongs in Blob, but check the blob type
For a 7-year compliance window, keeping data in the workspace is the expensive option. We exported six security tables to Blob storage, with a lifecycle policy to move data from Cool to Archive after 30 days. The design estimate was about $18 a month at steady state, against about $302 for in-workspace archive of the same data.
The follow-up audit found that the policy matched nothing. Log Analytics data export writes append blobs, and lifecycle tiering works only on block blobs. The data was stuck at Cool permanently. At the observed export volume of about 258 GB a month, the as-built cost at year seven was heading for about $334 a month, not the designed figure. It looked cheap in the early months, which is exactly why nobody noticed.
No lifecycle setting fixes this. The data has to be rewritten. We built an idempotent, fail-closed job that copies aged append blobs into block blobs at the Archive tier, server-side. The backfill rewrote 21,642 blobs (130 GB) with zero errors, and every copy was verified against its source. The job has to run on a schedule, because new export blobs age past 30 days every day.
What to take away
- Check detection coverage, not just cost, after any table-plan change.
- Test the split hypothesis with a usage classification before building anything.
- Judge a filter by the whole table’s volume, not by the traffic it targets.
- Confirm your archive actually reaches the tier you’re paying for.
Every one of these failures was silent. Each would have passed an “is the setting still there?” check indefinitely. Measured, not assumed.
How we can help
We review Sentinel and Log Analytics estates for cost and for coverage at the same time, so savings don’t come out of your detections. The healthcare SIEM case study shows the full engagement. If your bill or your audit is the concern, talk to us.