Microsoft Sentinel data tiers: what they cost, and what they cost you

01 / 13

What do Microsoft Sentinel data tiers actually cost?

Less than you think at the bottom, more than you think at the top, and in two places you cannot find out at all. That last part is not a figure of speech — there is a category of Sentinel charge for which no current Microsoft pricing page publishes a rate.

Start with the number most people carry around. The figure circulating in decks and blog posts is roughly 2.46 US dollars per GB for pay-as-you-go Sentinel analysis. It appears nowhere on either official pricing page. Searched twice, on two separate renders, on 31 August 2026: no match. What the page shows now is $4.3 USD per GB.

Before that frightens anyone: it is a single combined meter, and adding the Log Analytics rate of 2.30 dollars per GB on top of it overstates cost by around half. An easy mistake, because the two rates sit on two pages and neither explains its relationship to the other.

02 / 13

Two sets of tier names for one product

Before any of the money makes sense, the vocabulary has to. Microsoft currently documents Sentinel's storage tiers twice, differently, and the two sets do not line up.

Sentinel's own pages describe an analytics tier and a data lake tier, plus an XDR default tier for Defender hunting data. The words Basic and Auxiliary do not appear on Sentinel's log-tiers page at all. Azure Monitor's pages describe three table plans — Analytics, Basic, and one now labelled Auxiliary / Lake. Both documentation sets cross-reference each other's tables as though a mapping existed.

It does not. The closest Microsoft comes is a line in the table-feature reference noting that Auxiliary tables are also referred to as lake-only ingestion. No page states that the data lake tier is the Auxiliary / Lake plan. So do not write that equivalence into a design document, and be careful with any guidance that assumes it — including guidance that is otherwise correct.

03 / 13

The prices, as of 31 August 2026

Everything below was read from an official Microsoft pricing page on 31 August 2026, in East US, in US dollars, twice. Both pages render prices only after a region selection, so none of these is a global list price — and the Sentinel pricing page has moved, from the old Azure pricing-details URL to a new one under microsoft.com security pricing.

04 / 13

Two prices you cannot find anywhere

This is the finding worth taking to a vendor conversation, because it is checkable in about ninety seconds and it surprises people who sell Sentinel for a living.

The Azure Monitor pricing page carries a footnote stating that if a workspace has Microsoft Sentinel enabled, ingestion for Auxiliary and Basic logs is billed using Sentinel meters rather than the rates printed on that page. Reasonable enough. Except the Sentinel pricing page publishes no Basic meter and no Auxiliary meter.

• So the two cheap-tier rates that a cost-optimisation exercise turns on are not published for the customers most likely to use them. The Monitor rates are disclaimed; the Sentinel page has no substitute. Neither page acknowledges the gap.
• The same footnote moves long-term retention, search jobs and queries onto Sentinel meters once the data lake is enabled. The Sentinel page's only storage meter is data lake storage at 0.026 per GB per month, which is not the same number as Monitor's 0.02, and no page says one replaces the other.
• Practical consequence: model cheap-tier savings from your own invoice, not from a pricing page, and get the applicable rate in writing before a tiering project is signed off on a spreadsheet.

05 / 13

Moving a table down a tier turns its alerts off

This is the sentence the whole article exists for. Microsoft's table-plan documentation states it plainly in its list of consequences for changing a plan from Analytics to Auxiliary or Lake: alerts stop working. The feature-comparison table says the same thing in a single cell — Alerts, supported on Analytics, supported on Basic as simple log alerts, not supported on Auxiliary or Lake.

A cost-optimisation exercise that routes a noisy, high-volume table to the cheapest tier is therefore also a decision to stop detecting on it. Nothing warns you at the time, the saving is immediate and visible, and the loss is invisible until an incident that table would have caught.

• Restore does not work either. Tables on the Auxiliary plan do not support data restore. Search jobs are the only documented way back.
• The query language is materially reduced. On Basic and Auxiliary tables, join, find, search, externaldata and user-defined functions are unsupported, and lookup and union reach at most five Analytics tables. Much published detection content depends on parsers implemented as functions — our reading of those facts, not a Microsoft statement, but worth testing against your own rules first.
• You cannot purge personal data from Basic and Auxiliary tables. For anyone with a subject access request process, that is a first-order constraint, not a footnote.
• Commitment discounts do not follow the data down. Basic and Auxiliary ingestion is billed at flat per-GB rates outside any commitment-tier discount, so moving volume out of Analytics can leave you paying for a commitment you no longer fill.
• Plan changes are rate-limited to one switch per table per week, and data ingested under the Auxiliary plan before a switch back to Analytics is not available to interactive queries afterwards. This is not a setting to experiment with in production.

06 / 13

What Microsoft says breaks, and what it declines to say

Sentinel's own comparison of the analytics and data lake tiers contains exactly one sentence about lost capability: limitations on some features, including analytics rules, hunting queries, parsers, watchlists, workbooks, and playbooks. Note the wording. Limitations, not unsupported. It does not say which rules, which queries, or in what way.

That is the entire published warning, and it is worth being honest about the consequence: there is no per-tier feature support matrix. For near-real-time rules, user and entity behaviour analytics, notebooks, threat intelligence matching analytics and incident creation, Microsoft publishes no tier statement at all. Watchlists are named in the sentence above as limited and then never explained anywhere.

If someone hands you a neat per-feature tier matrix, ask where it came from. It is not Microsoft, because Microsoft has not published one.

07 / 13

Free is narrower than it looks

Sentinel has a genuinely useful free list — Azure activity logs, Sentinel health, Office 365 audit logs covering SharePoint, Exchange admin activity and Teams, and security alerts from across the Defender family. Then there is one sentence that redraws the boundary.

Although alerts are free, the raw logs behind several of those same products are paid. The free unit is the alert or incident record. The telemetry that produced it — device events, email events, identity logon events, cloud app events, Entra sign-in and audit logs — is chargeable. Connecting Defender XDR costs nothing; ingesting Defender XDR advanced hunting data is a bill.

08 / 13

The filtering exemption Sentinel's own documentation never mentions

Azure Monitor charges you for over-filtering. If an ingestion-time transformation reduces incoming data by more than half, you are billed for the filtered volume above that 50 per cent threshold — a rule that quietly discourages the aggressive filtering that would save the most money.

Except that if Microsoft Sentinel is enabled on the workspace, there is no cost for transformation to Analytics tables regardless of how much the transformation filters. That sentence is marked as important in the Azure Monitor documentation and appears in none of Sentinel's own pages on data transformation or cost reduction. A team reading only the Sentinel documentation would either miss the exemption entirely or apply the generic penalty and under-filter.

Two caveats. The exemption covers Analytics tables only; the Auxiliary processing charge applies to all incoming data before filtering, so filtering into an Auxiliary table saves ingestion cost but not processing cost. And enrichment is billed — columns added in a transformation count toward billable size.

09 / 13

Getting data back when an auditor asks

Cheap storage is only cheap if retrieval works. Here is what the documented retrieval path actually looks like, which is less comfortable than most retention designs assume.

10 / 13

One line to read twice if you run this for other people

Search jobs do not support cross-tenant execution, and they do not support Azure Lighthouse delegated access — even with the correct permissions. Summary rules, which are Microsoft's sanctioned way to run detections against cheap-tier data by aggregating it into an Analytics table, carry the same restriction on cross-tenant Lighthouse queries.

Put those two facts next to the earlier one — that restore does not work on Auxiliary tables, leaving search jobs as the only way back — and the conclusion is uncomfortable. A managed service provider operating through Lighthouse cannot retrieve a customer's archived or Auxiliary-tier data from its own tenant. Any cost model built on cheap tiers plus we will just search-job it when the auditor asks fails on that line.

One newer option is worth watching: Sentinel scoping, which offers row-level access control without workspace separation. It is preview and Defender-portal only — plan for it, do not rely on it.

11 / 13

Where the documentation disagrees with itself

Naming the contradictions is more useful than picking a winner. All were checked on 31 August 2026.

12 / 13

How I would tier a workspace

Author-proposed, not vendor guidance. Deliberately conservative, because the failure mode here is silent.

• Decide tiering by detection value, not by volume. The question is never what is expensive, it is what would I want an analytics rule on. Anything you would alert on stays in the analytics tier whatever it costs.
• Filter before you tier. In a Sentinel-enabled workspace, filtering into Analytics tables is free at any ratio. Dropping 80 per cent of a verbose source at ingestion keeps the remainder fully alertable, and is almost always better than moving the whole table down a tier.
• Separate non-security data into its own workspace. Microsoft's own first cost recommendation, and the cleanest one — everything in a Sentinel-enabled workspace is analysed and charged as security data.
• Check the Microsoft 365 grant is landing before you optimise anything else. It is worth 5 MB per user per day, it applies automatically, and it appears on the bill as its own meter. At a few thousand seats it changes what is affordable to ingest.
• Before any tier move, write down what detection you are giving up. If the answer is nothing, this table has no rules on it, the move is safe. If nobody can answer, that is the finding.
• Model from your own invoice. Two of the rates you need are not published for Sentinel workspaces, Microsoft publishes no ranked list of expensive data sources, and its own guidance is to measure your workspace. The workspace usage report workbook separates free from billable volume, which is the number that matters.

13 / 13

When is this worth bringing in outside help?

Not for reading a pricing page, and not for a first tiering pass on a small workspace — the usage workbook and an afternoon will tell you most of it.

It is worth help at three points. The first is a tiering decision on an estate that already has detection content, where the question is which of your existing rules stop working and nobody has a tested answer. The second is the March 2027 portal move combined with a data lake onboarding, which is not reversible per workspace and changes your billing meters as a side effect. The third is a managed or multi-tenant estate, where the Lighthouse restrictions on search jobs and summary rules can invalidate an otherwise sensible cost model.

Disclosure: Avalon Web Services sells Microsoft security work, including the Sentinel deployment and tuning package linked below — which, worth saying plainly, excludes data ingestion and Log Analytics costs, because those are yours and they are the subject of this article. Every rate and rule above is cited to a Microsoft page you can open yourself.