Stop paying Analytics-tier rates for logs you never meant to keep. One noisy connector can turn a sane workspace into a monthly surprise, and Sentinel will bill you for every careless row you let through.
In this guide, you’ll start by checking the pricing model your workspace is actually using. Then you’ll cut noisy events at ingestion, route the right tables to cheaper storage, and finish by proving the change with KQL so the savings are visible instead of hypothetical.
Prerequisites
If you want to follow along hands-on, you’ll need:
-
An Azure subscription with Microsoft Sentinel already enabled, because the pricing and table choices only matter after the workspace exists.
-
Log Analytics ContributorplusData (manage)permissions in the Defender portal, because table plans and transformations are locked down; skip the write access if you are only auditing the current state. -
The Azure CLI and a shell that can run KQL examples and
azchecks, because this workflow stays scriptable instead of wandering through the portal. -
A workspace with at least one noisy source, because the fastest savings show up when you can measure a table that is already bloating your bill.
Start With The Bill, Not The Dashboard
Microsoft Sentinel pricing is driven by the tier you ingest into, not by the comforting thought that we’ll tune it later. The current billing guidance and pricing page both make the same point: analytics, retention, and data-lake usage are separate cost decisions, and commitment tiers begin at 100 GB per day.
That means the first job is not to delete anything. It is to identify which part of the meter is hurting you.
| What to check | Why it matters | What usually changes first |
|---|---|---|
| Analytics tier ingestion | This is the expensive hot path for live detections and hunting. | The biggest noisy table. |
| Retention | Extra retention adds cost long after the event was useful. | Old tables nobody queries anymore. |
| Commitment tier | Predictable ingest can be cheaper than pay-as-you-go. | Teams that stabilize above a steady daily volume. |
| Dedicated cluster | Shared clusters can pool workspace volume in one region. | Large estates with multiple workspaces. |
If you already know your daily volume is steady, a Log Analytics dedicated cluster can pool multiple workspaces and share the commitment discount. That is a cost play, not a performance toy. The trap is treating it like a first move when you have not measured the ingest curve yet.
[Image: images/sentinel-cost-path.svg]Cost flow map
Once you see the path from source to tier, the rest of the work stops feeling like guesswork. You are no longer using Sentinel less. You are deciding which bytes deserve expensive storage and which ones do not.
Filter Before You Store
The strongest cost reduction happens before the data hits the workspace. Microsoft documents this in both Azure Monitor DCR overview and Microsoft Sentinel data transformation guidance: data collection rules can transform records before they are stored, and Sentinel-enabled workspaces are not charged the Azure Monitor filtering ingestion fee for Analytics tables.
That gives you a clean rule: if a row is noisy enough that you would never alert on it, do not pay to keep it in the hot path.
{
"transformKql": "source | where EventID in (4798, 4799)"
}
That example is intentionally small. It keeps only the events you care about and drops the rest before they become billable payload. If you are filtering firewall or proxy logs, the pattern is the same: keep the security-relevant rows, not the chatty ones that turn every incident review into a scavenger hunt.
You can also use the same ingestion-time logic to route records by severity instead of deleting them outright.
source
| extend Route = iif(Severity in ('High', 'Critical'), 'Analytics', 'DataLake')
| project TimeGenerated, Computer, Severity, Route
The exact shape depends on the connector and the table plan, but the decision is always the same. Either the record is important enough for hot storage, or it is not. Anything in the middle is usually a polite way of saying you have not decided yet.
Warning: Test the transform on a low-volume source first. A bad filter does not save money; it saves the wrong rows.
Put The Right Data In The Right Tier
Once the stream is clean, the next saving comes from storage shape. Microsoft’s log retention tiers guidance and data-tier management docs separate the problem into primary security data and secondary security data. The current data-lake guidance is explicit: keep primary security data in Analytics, and push secondary, verbose, or compliance-heavy data to cheaper tiers when real-time alerting is not the point.
[Image: images/sentinel-tier-decision.svg]Tier decision matrix
| Tier | Use it for | What you give up |
|---|---|---|
| Analytics | Primary security data, live detections, hunting, and investigations. | Highest cost. |
| Basic | Tables you can query without needing live alerting on every row. | Less interactive depth and fewer real-time features. |
| Data lake | Secondary security data, long retention, and on-demand investigations. | Not a real-time alerting tier. |
If a table only gets queried after an incident is already underway, it is usually a bad candidate for Analytics. That is not a moral judgment. It is just math.
Quick Win: If a table only matters after the fact, move it out of your hottest tier before you touch anything else.
Measure The Damage With KQL
You cannot optimize what you cannot name. The Usage table gives you hourly per-table usage, and Microsoft’s example queries for Usage show the same fields you need here: IsBillable, _BilledSize, and DataType.
Start by finding the table that burns the most billable bytes.
Usage | where TimeGenerated > ago(7d) | where IsBillable == true | summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by DataType | top 10 by GB desc
If one source dominates the list, do not just stare at it. Drill into the shape of the growth.
Usage
| where TimeGenerated > ago(24h)
| where IsBillable == true
| where DataType in ('SecurityEvent', 'CommonSecurityLog')
| summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by bin(TimeGenerated, 1h), DataType
| order by TimeGenerated asc
That second query tells you whether the problem is a steady firehose, a scheduled burst, or a single connector behaving like it has a grudge. Once you know the pattern, the fix stops being vague. You can move the source, add a filter, or stop pretending the table belongs in Analytics.
Roll Out In The Right Order
The safest path is boring. That is a compliment.
| Order | Change | What to verify |
|---|---|---|
| 1 | Confirm the current billing model and retention. | The billing page and current table plans match what you think you pay for. |
| 2 | Claim the free ingestion allowances that already exist in your tenant. | Billable bytes drop where the free source applies. |
| 3 | Filter the noisiest connector with DCR logic. | The Usage table shows the table shrinking. |
| 4 | Move secondary data to the cheaper tier that fits it. | Alert coverage stays intact where it matters. |
| 5 | Revisit commitment tier or cluster design after the ingest curve settles. | The monthly bill becomes predictable instead of chaotic. |
Microsoft’s billing documentation also calls out the current free data sources and ingestion allowances, so check that page before you spend time engineering around a cost you may already be entitled to avoid.
If you are running enough volume to justify shared cluster economics, revisit the dedicated-cluster page after the filters are in place. If you do it first, you are just giving the meter a better chair.
Conclusion
Sentinel cost optimization is not one trick. It is a sequence: verify the bill, cut noise at ingestion, tier the remaining data correctly, and then validate the change with KQL. If you skip that order, you end up paying Analytics prices for logs that should have been cheap from the start.
The practical rule is simple. Keep primary security data hot, keep secondary data colder, and keep measuring until the bill reflects that split. That is how you reduce Azure consumption without sanding off the security signal you still need.
