The usual levers for a Microsoft Sentinel bill (cheaper table plans, ingest-time filtering, moving old data out of the workspace) can each do exactly what the change record says while quietly breaking something else. For a regional healthcare group, a cheaper table plan had left 33 of the workspace’s 83 enabled detections running against no data, and nothing reported an error. Measure detection coverage and the whole bill after every change, not only the setting you changed.
Where the money goes
The client’s central Sentinel workspace ingested about 1,365 GB a month. At the East US 2 pay-as-you-go list prices we used in the April 2026 assessment, an Analytics-plan table in a Sentinel workspace cost about $4.76 per GB (Log Analytics plus the Sentinel charge), against about $0.50 per GB on the Basic plan. Prices change, so check yours. With a gap that large the spreadsheet answer looks obvious, and our first assessment estimated about $32K a year in savings from moving four high-volume tables to Basic.
Lesson 1: a cheaper plan can silently drop a table out of your rules
Our first assessment said scheduled analytics rules could still query Basic tables within a 30-day window, and called the detection impact “minimal”. That was our error, and we have found no Microsoft documentation that supports it. Microsoft positions Basic for troubleshooting and incident-response data, limits alerting on Basic tables to simple log alerts, and recommends keeping primary security data such as authentication logs in the analytics tier. Table-plan capabilities have changed repeatedly, so check current docs rather than any assessment, ours included. The client was concerned about alert coverage and kept three of the four tables on Analytics. That was the right call.
Six weeks after the changes, a follow-up audit showed what Basic meant in practice. When we replayed rule queries through the Log Analytics query API, the standard query path, it rejected the Basic-plan tables. (Microsoft documents a separate search endpoint for Basic data.) ASIM parsers and many rule queries wrap their sources in union isfuzzy=true, which drops a table it can’t resolve and records only a warning in the query status. Nobody reads that warning on a scheduled run, so the rule “succeeds” every time against an empty dataset.
Several security tables, including SecurityEvent and SigninLogs, were on Basic in the live workspace although the design kept them on Analytics. This predated our changes. Our own export change had spotted the mismatch but treated it as a retention issue, not a detection one. 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 rules for about $330 a month and put 5.1 million security events back in front of the detections. Restoring the other 10 would have cost far more, so they were written up as an explicit risk acceptance for the client’s security lead to sign off.
How to check yours: for every enabled rule, list the tables it reads (including through parsers) and compare that list with each table’s plan. Replay each rule’s query and confirm it returns rows. Turn on Sentinel auditing and health monitoring, 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 into security data and everything else, so non-security data would stop paying the Sentinel charge. It’s a common recommendation that rests on an easily tested assumption.
We classified every billable table over 90 days. Of 4,110 GB ingested, 0.10 GB was not security-relevant: 99.997% security data. A split would have created an empty workspace and saved essentially nothing.
We told the client so, and still recommended the split for governance: the new workspace has no Sentinel, a 5 GB-a-day cap, and a convention that non-security workloads go there by default. It’s cheap insurance against application telemetry filling the SIEM, not a 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 transformation to drop lookups for five high-volume Microsoft domain 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 it didn’t target had grown. One workload’s DNS lookups rose roughly sevenfold, an application issue that filtering would only have hidden. And Microsoft telemetry was arriving under suffixes the list didn’t cover, such as *.trafficmanager.net and *.cloud.microsoft.
Measured only on its targets, the filter looked like a win. Judge it against the whole table’s baseline and review the top untargeted queries after each change.
We also got the process wrong. The change record required a security-lead review and a detection-fire test before go-live, and neither happened first. We recorded that and made both gates mandatory before any expansion, because filtering a security table is a detection change too.
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 the policy matched nothing. In this workspace every exported blob was an append blob, and lifecycle management can only change the tier of block blobs. The data would stay at Cool indefinitely. 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 instead of the designed figure. It looked cheap early on, which is 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, server-side, into block blobs at the Archive tier. The backfill rewrote 21,642 blobs (130 GB) with zero errors, with every copy checked against its source’s length. Two caveats apply. The job has to run on a schedule, because new export blobs age past 30 days every day. And the saving only arrives once the verified source blobs are deleted, because until then you pay for both copies.
What to take away
Each of these failures was silent and would have passed an “is the setting still there?” check. After any cost change, check detection coverage, judge filters by the whole table, test assumptions such as a workspace split with real usage data, and confirm your archive reaches the tier you’re paying for.
How we can help
We review Sentinel and Log Analytics estates for cost and coverage together, so savings don’t come out of your detections. The healthcare SIEM case study covers the full engagement.
