Cutting a Microsoft Sentinel bill 30–50% without losing detections

RG LABS · 20 JULY 2026 · 7 MIN READ

Microsoft Sentinel bills by the gigabyte you ingest. That single fact explains most runaway SIEM costs: connectors get switched on, data lands in the expensive tier by default, and nobody goes back to ask which of it a detection has ever actually queried. In most mid-market deployments we look at, a third to half the ingest volume is doing no detection work at all.

The good news is that cutting it is an engineering exercise, not a licensing negotiation. Below are the five levers, in the order we apply them. Done properly, the saving funds the work several times over, and the detections your team relies on don't change.

1. Find out what you're actually paying for

Start with ingest by table, ranked by volume. Sentinel's own Usage and estimated costs view plus the Usage table will tell you which sources dominate the bill. Nearly every time, the top five tables are 70–80% of the spend, and at least one of them is a surprise.

The usual offenders: firewall and proxy traffic logs shipped in full, verbose syslog from network appliances, non-interactive sign-in logs, Office activity at full fidelity, and duplicated endpoint telemetry. None of these are useless, but very little of the volume drives a detection.

2. Map every table to the detections that use it

This is the step people skip, and it's the one that makes the cuts safe. For each high-volume table, list the analytics rules, scheduled hunts and workbooks that query it. If a table hasn't been referenced by a rule, a hunt or an incident investigation in 90 days, it's a candidate for a cheaper tier or a filter. Not because it's worthless, but because you're currently paying premium rates for data nobody interrogates.

Keep a short "never touch" list as you go: identity sign-ins, EDR alerts, audit logs, and anything a compliance obligation requires you to retain. Those stay where they are.

3. Filter before it lands, not after

Once data is ingested, you've paid for it. The cheapest gigabyte is the one you never send. Data collection rules and ingestion-time transformations let you drop rows and columns at the collector: health-check and heartbeat noise, allowed-traffic records that no rule inspects, verbose fields nobody reads, chatty informational events from appliances.

The discipline here is to filter on what the detection needs, not on what looks noisy. A field you drop is a field an investigator can't pivot on six months from now, so document every transformation and the reasoning behind it.

4. Put data in the right tier

Not all logs deserve the analytics tier. Microsoft's cheaper tiers exist precisely for high-volume, low-query data that you still need to hold:

• Analytics tier. Anything your detections query in near real time. Leave it alone.
• Basic / auxiliary logs. High-volume sources you search occasionally during investigations rather than alert on. Typically firewall traffic, proxy logs, verbose network telemetry.
• Archive / long-term retention. Data you keep for compliance and hope never to read. Far cheaper per gigabyte than leaving it hot.

Re-tiering is usually the single biggest lever, and it changes nothing about what your analysts can find, only how quickly and at what price they reach it.

5. Stop paying twice, then commit

Check for duplicate ingestion paths. Endpoint and Defender XDR telemetry in particular can arrive through more than one connector, and some of it is free through the Microsoft 365 connector while a second path is being billed. Deduplicate before you tune anything else.

Only once volume is stable and predictable should you look at commitment tiers. Committing to a daily volume gets a meaningful discount over pay-as-you-go, but commit to your post-optimisation number, not your current one, or you'll simply lock in the waste.

What this looks like on paper

An illustrative mid-market environment, before and after the five levers. The shape is typical; your numbers will differ.

A 30–50% reduction in monthly ingest spend is a realistic outcome in an environment that has never been tuned. It is not a realistic outcome in one that already has been, and any consultant promising it without looking at your usage data first is guessing.

The part that matters to your CFO

This is one of the few security projects that pays for itself and keeps paying. The engineering work is a fixed, one-off cost; the saving recurs every month for as long as the platform runs. If a tuning engagement costs less than a few months of the saving it produces, the business case writes itself, and unlike most security spend, you can show the finance team the before and after on the invoice.

The trap to avoid: cutting cost by quietly cutting coverage. A cheaper SIEM that misses the incident is not a saving. That's why the mapping step comes second and the "never touch" list exists: every reduction should be traceable to a decision about detection value, not just volume.