Microsoft Sentinel cost: why the bill is bigger than the thing it protects
Somebody enabled every data connector on the list. It seemed like the responsible thing to do. Six weeks later the Log Analytics bill for a forty-person company is larger than the Microsoft 365 licensing, and the conversation about security monitoring has become a conversation about whether to keep security monitoring.
Microsoft sentinel cost is almost entirely ingestion. The analytics rules are free. The workbooks are free. The thing you pay for is every gigabyte that arrives, and the decision about what arrives is made once, casually, by whoever clicked through the connector gallery.
What drives microsoft sentinel cost
Two meters, and people usually only think about one.
Ingestion, charged per gigabyte as data lands. This is the large number.
Retention, charged per gigabyte per month beyond the included period. This is the number that creeps, because it compounds: a table ingesting steadily for two years at extended retention is paying for the same data repeatedly.
Rules, incidents, hunting queries and notebooks do not bill per use. So the lever is not "run fewer detections", it is "ingest less, and keep it for less time". Microsoft's Sentinel costs and billing documentation sets out the meters and the included retention, which is worth reading before choosing a plan rather than after.
Which tables earn their place on a small tenant
For a company of a few dozen people with no on-premises server estate, the useful set is small.
SigninLogs. Worth it, always. This is how you answer "who logged in, from
where, and did MFA happen". Almost every investigation on a small estate starts
here. Volume is proportional to headcount, so it stays affordable.
AuditLogs. Worth it. Directory changes, Conditional Access modifications,
role assignments, app registrations. This is the table behind most of the
configuration drift and privilege escalation detections in
the validation note, and it is low
volume because it records changes rather than activity.
AzureActivity. Worth it. Control-plane operations on subscriptions. Who
deleted the resource group, who changed the NSG rule. Low volume, high value.
OfficeActivity. Depends. Exchange and SharePoint activity is genuinely
useful for investigating data access, and it is also the table most likely to
surprise you on volume. Enable it if you have a reason, watch it for a fortnight,
and check the number before you settle.
SecurityEvent from Windows machines. Usually not, at small scale, unless
you filter hard. Unfiltered Windows security event collection from even a handful
of servers can exceed everything else combined. If you need it, use a data
collection rule to take specific event IDs rather than a whole level.
Network and firewall logs. Rarely worth it here. High volume, and the questions they answer are usually not the questions a one-person team is asking.
The general shape: tables that record changes are cheap and valuable. Tables that record traffic are expensive and only valuable if somebody is going to look.
Basic logs, and what you give up
Some tables can be set to a cheaper Basic tier. The saving is real and so are the restrictions, and the restrictions are the point.
Basic logs have short retention, a reduced query surface, and cannot be used in scheduled analytics rules. That last one matters most: if a table is on Basic, it is available for investigation after the fact but cannot drive a detection.
So the decision is not about the data's value, it is about its role. A table you
will search when investigating an incident can be Basic. A table a rule depends
on cannot. Putting AuditLogs on Basic to save money quietly disables every
detection built on it, which is the same silent-failure problem as an unvalidated
rule, arrived at from a different direction.
Commitment tiers
Once daily ingestion is predictable, a commitment tier prices a fixed daily volume below the pay-as-you-go rate. The mechanics are simple and the trap is not.
You pay for the committed volume whether you use it or not. On a small estate mid-tuning, ingestion is not stable: you are enabling and disabling connectors, which is exactly when a commitment is wrong. Commit after you have run steadily for a month or two, not before.
The other trap is worse and worth naming. If you are near a cap or a commitment and your daily total goes flat at exactly that number, that is not a measurement, it is data loss. A perfectly level line at the limit means ingestion was throttled or dropped, and the days that look tidiest on the graph are the days you cannot investigate.
Checking before the invoice
The query that answers "what is this costing" takes a minute and nobody runs it until the bill arrives:
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize GB = round(sum(Quantity) / 1000, 2) by DataType
| order by GB desc
Run it monthly. The output is usually one table you did not expect at the top, and the fix is a data collection rule rather than turning the connector off entirely.
For the trend rather than the total, group by day as well and look for a step
change. A step means somebody enabled something, and knowing which day narrows
it to a change you can find in AzureActivity.
Two things are worth setting up while you are in there. A daily cap, so a misconfigured connector cannot produce a surprise invoice, set high enough that normal days never touch it. And an alert on the cap being reached, because the cap silently discarding data is exactly the failure you would not otherwise notice.
The framing that survives a budget conversation
Security monitoring you cannot afford is not a security control, it is a liability with a monthly cost, because it will be switched off in a hurry at the worst possible moment and probably by someone who does not know which tables matter.
Choosing three tables deliberately, writing down why, and keeping the bill boring is a defensible position. Ingesting everything and hoping nobody looks at the invoice is not, and it ends with the whole workspace being questioned rather than one connector.
AzClean Detections is built around that constraint: twelve rules that run on the three tables above, so the detection surface does not require an ingestion budget you have to defend. The Azure cost notes cover the same argument for the rest of the estate.