How to Reduce Microsoft Sentinel Costs: 9 Levers That Don’t Cost You Detection

Microsoft Sentinel estates can cut ingestion cost by 10-30% without losing detection coverage. That makes Sentinel one of the few places in a security budget where a double-digit saving is recoverable; most of the rest is personnel and licences, neither of which changes within a quarter. We return at the end to show where the 10-30% comes from.
But it is only recoverable if you pull the right levers, in the right order. There are nine. Three levers are changes you can make this week with no risk to coverage. Four levers need real engineering and deliver most of the money. Two levers prevent overspend that has not happened yet, which is the cheapest money on the list, because you never spend it.

Here’s a deep dive into the key takeaways from their discussion.

How much does Microsoft Sentinel cost?

Microsoft Sentinel is billed per gigabyte ingested. Pay-as-you-go list price is about $4.30/GB; commitment tiers start around $2.96/GB and discount up to 52% at the top tiers [INDSÆT: region og dato for listepriser + link til Microsofts prisside]. Retention beyond the included period, Basic-tier queries and data lake storage are billed separately. The nine levers below are where that bill can be cut.

The Nine Levers

1. Buy the capacity correctly

Pay-as-you-go runs about $4.30/GB at list; the entry commitment tier is roughly $2.96/GB, and the discount reaches up to 52% at the top tiers. Overage above your commitment bills at the same discounted rate, so the only way to lose is to commit above what you use. Two things most teams get wrong: size the tier on billable volume after the free tables and the E5 and Defender for Cloud allowances you already pay for and stack a pre-purchase plan on top of it, which almost nobody does. Microsoft’s own example: A 200 GB/day tier saves 39%; a $100,000 pre-purchase plan bought for $78,000 adds 22% more; 51% combined. Purchases are final and cover analytics tier only, so bring finance in before signing.

(Source: Microsoft Learn & Azure Pricing, sep. 2026)

2. Buy the capacity correctly

Defender and Sentinel overlap by design. Defender collects endpoint, identity, email and cloud-app telemetry and detects on it; Sentinel connectors can ingest much of that same telemetry into your workspace,

where it bills per gigabyte ingested. If both paths are running, nothing looks broken. Two connectors, both healthy, both doing exactly what they were configured to do, while the same activity gets detected, and paid for, twice.

If that is happening, the call is easy: Defender’s alerts and incidents arrive in Sentinel free, the raw telemetry behind them is charged at full rate, so you keep the verdict and drop the duplicate. The work is establishing whether it is happening at all. Nothing in the invoice or the connector list tells you two paths are carrying the same data. In practice this most often means the Defender advanced hunting tables. DeviceProcessEvents and DeviceNetworkEvents are the two that typically sit in Sentinel at full ingestion cost while Defender is already detecting on the same activity, and they are usually the first two to remove from the workspace.

3. Set retention per table, not per workspace

Retention is a table-level setting and most workspaces still run one default value across everything. Default extended analytics-tier retention is one of the more expensive defaults in Sentinel, and fixing it barely touches what you collect or detect. Sometimes you save even more, if a log source already comes with free retention you can use(Source: Microsoft Learn & Azure Monitor Documentation, 2026). The obvious candidates are the high-velocity tables: Set retention on firewall data to the shorter default of three months, rather than carrying it for a year or more at analytics-tier prices.

See it on your own Sentinel. Book a demo: 30 minutes, your workspace, your numbers.

Four that pay for the programme

4. Assess every log source on cost against gain

You are probably thinking that some of what you ingest is not worth what it costs. The problem is that nobody can say which, so the cutting never starts, and the bill stays where it is.

Give every log source a score on two things.

The first is what it costs you: Take it at list rates and estimate it for the sources you have not turned on

The second, call it gain, is how many alert rules map to that source. Map, not enable. What you need to know is how much detection a source is capable of powering, not how many rules happen to be switched on today.

Read the two together and the decisions make themselves. High gain at low cost is a critical data flow at optimal expense: Leave it alone. Low gain at high cost is your savings list, and the first place to look. High gain at high cost stays: it earns its money, and cheaper storage is what you reach for there instead of a cut.

What you end up holding is a ranked list of candidates with the coverage consequence attached to each, which is what turns a cost conversation into a decision rather than an argument. And because you estimated cost for sources you have not enabled, the same assessment runs in reverse, showing where detection coverage can be bought cheaply. A cost review that ends with you onboarding a log source is the analysis working, not failing.

5. Re-tier what does not need to be in the analytics tier

Most of your bill sits in a handful of very large data sources: Firewall, proxy, NetFlow, verbose compliance logs. Most of them are read backwards, after you already know something happened. They do not need to live where detection runs.

Sentinel gives you three places to put a log. What separates them is what you can do with the data, not how it is stored.

Analytics is the working tier: Rules run against it, analysts query it live.

Basic is cheaper and still searchable, but you pay per gigabyte scanned every time you look, and queries run against one table at a time.

Auxiliary/Lake is the cheapest, meant for verbose logs and data you keep for auditing and compliance. Detection rules do not run against it, and there is no export or restore, but it stays queryable for up to 12 years and can be promoted back into the analytics tier when an investigation needs it. Queries are slower by design, built for auditing rather than real time.

The gap between them is not marginal: Comparing 50 GB/day over three months in North Europe comes to Analytics €6,023, Basic €843, Auxiliary/Lake €368 for the same exact data. (Source: Azure Pricing Calculator & MS Learn: Log Tiers, sep. 2026)

So the question is never “is this log expensive.” You already assessed from a value point of view, that you needed it. The question is “does anything need to get detected on as it arrives.” Where the answer is no, move it and keep the access. One condition routes per record rather than per table, so high-severity firewall denies land in analytics, where rules see them, while the other 95% of the traffic log goes to the lake, so you are not forced to make the call for the whole table at once.

6. Summarise what you retire, and keep detecting on it

The obvious objection to the previous lever is that moving a table out of the working tier means no rules run against it anymore. For a lot of high-volume data, that objection dissolves once you look at what the rules are reading.

Take DNS. You may ingest millions of queries a day, but almost no detection cares about an individual query. What detection wants is the pattern: how many distinct domains a host resolved in an hour, how much data it moved over DNS, whether a machine suddenly started resolving something nobody else in the estate touches. Those are aggregates, and an aggregate is tiny. A summary rule produces exactly that: A scheduled query that runs across the raw data, computes the counts and totals you care about, and writes the compact result into a table in the working tier. Your detection rules run against the summary. The raw records sit in the lake at archive prices, and the analyst investigating an incident still has every one of them to go back to. The test for where this fits is whether detection is about patterns or about individual records. DNS, firewall, proxy, NetFlow, authentication volumes are all patterns. Two mechanical limits to design around: a summary rule cannot raise an alert by itself, so it needs an ordinary analytics rule pointed at the summary table, and each execution writes at most 500,000 rows.

7. Trim what survives with DCR transformations

Applied to each record before it is written, so whatever it drops never bills. Row filtering is the obvious half: Removing redundant data. The internal DNS resolutions and Microsoft service endpoints no rule will ever match. Column trimming is the bigger, quieter half: Firewall and CEF records routinely carry

sixty-odd columns, of which detection logic typically touches only a handful. Keep every record, project only the referenced fields.

With Sentinel enabled on the workspace, transformations on Analytics tables carry no filtering charge, however much you drop. Basic tables are different: they are charged when a transformation drops more than 50% of incoming data. Trimming can make a major cost impact.

Two that stop the overspend before it happens

8. Extrapolate against budget, per table, with a stop attached

Your invoice arrives after the month has closed, by which point every gigabyte on it is already bought. You do not have to wait for it. At any point in the month, you can take what has been ingested so far, work out the daily average and project it forward to month end. A forecast of the bill while there is still month left to act in.

On day 10, a forecast running 25% over budget is something you can act on: Throttle or pause whatever is driving it, and you still land on plan. On day 31 the same number is a variance report.

Do it per table and for the workspace as a whole. A workspace-level forecast tells you that you are heading over budget. A table-level forecast tells you which table is doing it, and therefore whose change caused it, which turns a budget problem into a specific conversation with a specific team.

9. Detect ingestion spikes and stop them automatically

A spike can be an attack, or – far more often – a change nobody told you about: Debug logging left on after a release, a cluster onboarded at default verbosity, a forwarder looping. Monitor ingestion spikes and every one of those gets caught in hours rather than at month end: money that never leaves. That is the structural point worth taking to finance: Sentinel cost is largely driven by decisions made outside the security team, by people who never see the invoice. Notify the SOC and the platform owner at +200% against the table’s own baseline; auto-stop at +400% sustained, with a named approver to resume. Remember to baseline both per table and per weekday, because ingestion can vary a lot across the week and the day.

Five questions for the SOC lead

Which log sources cost us the most, and how much detection does each of them actually carry? If the answer only covers cost, or only covers rules, we have half the picture.

Are we ingesting raw telemetry for anything Defender is already detecting on? If nobody has checked, that is one of the first places to look.

What is our billable volume after allowances, what tier are we on, and is there a pre-purchase plan on top of it? Three parts, and most estates get at least one of them wrong.

How much of what sits in the analytics tier does nothing need to detect on as it arrives? That number is the size of the retiering opportunity.

If we are 25% over budget on day 10, what can we actually do about it? If the answer is “wait for the invoice,” we have reporting, not control.

None of these are technical questions. They are governance questions that happen to have technical answers.

Cutting ingestion is half the picture; the other half is what the remaining data produces. See Eliminating Sentinel alert fatigue: automated tuning vs. manual rules.

As promised: Where the 10-30% comes from

None of this is exotic. Every lever above is documented and achievable by a competent platform engineer with time. That last clause is the problem: This is continuous work, not a project. Tiers drift, estates grow, allowances move with your licence count, connectors get re-enabled, and somewhere every quarter a developer turns on debug logging.

That continuity is what Seculyze automates. It keeps the value-versus-cost calculation current for every log source, so the question in lever 4 has an answer on a screen rather than after a week of analysis. Seculyze ranks your largest storage and SKU-level opportunities as one-click changes rather than engineering tickets, and detects ingestion anomalies against each table’s own baseline while extrapolating spend against budget early enough to act on it.

Cost is a part of Calibrate for best-practice configuration. Calibrate is one of the four pillars in a single product, alongside Tune for AI-driven alert noise reduction, automation for agentic SOC and SOAR, and Unify for multi-workspace and multi-tenant estates. All of it runs on top of your existing Sentinel: API-native to Sentinel and Defender, nothing to deploy.

Across customers that lands a 10-30% reduction in Sentinel cost without losing detection fidelity. [INDSÆT: datagrundlag, fx antal kunder og periode] One global manufacturing SOC took 24% out of its Sentinel cost while lifting MITRE ATT&CK coverage by 65%, which is the point. Automating the cost work does not mean handing over the SOC. Seculyze is an optimization layer, not an MSSP. Your team keeps the console, the decisions and the control.