Why the bill drifts
- Diagnostic settings enabled with "all categories", by default, on hundreds of resources.
- New sources plugged in project after project: firewalls, proxies, Entra ID, endpoints, applications.
- Applications logging in debug mode in production, sometimes in a loop.
- Logs sent twice to several workspaces.
- On a workspace where Sentinel is enabled, GBs ingested as Analytics logs are billed a second time by Sentinel.
An incident of this kind can cost tens of thousands of euros a day. That is why ingestion alerting is part of the method.
Step 1: measure what is ingested
Before cutting anything, you need to know where the volume comes from. The workspace's Usage table gives the billable volume per table:
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize GB = sum(Quantity) / 1000 by DataType
| sort by GB descA handful of tables usually account for most of the volume: AzureDiagnostics, firewall, proxy and container logs, Windows security events. You then drill down to the resource or category, for example with the _BilledSize column.
Step 2: filter at the source
- Diagnostic settings: select only the categories that are actually used.
- Data Collection Rules (DCR): with the Azure Monitor agent, filter what is collected on VMs (for example only certain Windows events), and apply ingestion-time transformations to drop useless rows or columns.
- Duplicates: send each log to a single workspace.
- Application log level: no debug in prod, except temporarily and under control.
Step 3: choose the right table plan
| Plan | Ingestion cost | Best for |
|---|---|---|
| Analytics logs | The highest | Logs queried often, detection rules, alerts |
| Basic logs | Much lower | High-volume logs queried occasionally, for troubleshooting |
| Auxiliary logs | The lowest | Very large volumes kept for audit or investigation |
Basic and Auxiliary logs come with trade-offs: more limited queries, billed on data scanned, and not every feature. The choice is made table by table, with the teams that use these logs.
Step 4: adjust the commitment tier
On pay-as-you-go, every GB is billed at full price. From about 100 GB a day, a commitment tier brings a discount, and higher tiers exist for large volumes. Sentinel has its own commitment tiers. The right tier should be recalculated regularly, especially after a filtering campaign has reduced the volume.
Step 5: adjust retention
Interactive retention is included up to 31 days (90 days on a workspace where Sentinel is enabled). Beyond that, it is billed. For compliance, long-term retention (archive) costs much less. Retention is set table by table: there is no point keeping two years of debug logs.
Step 6: work with the SOC
On Sentinel, a poorly designed saving can cost you a security alert. So every filter is validated with the security team, against the detection rules actually in use. Some sources are free in Sentinel, such as Azure Activity logs: there is no reason to go without them.
Stay in control
- An alert on daily ingestion per workspace, to catch a drift the same day.
- A quarterly review of the largest tables and of the commitment tier.
- A FinOps by design rule: every new diagnostic setting only enables the categories needed.
A workspace daily cap can serve as a one-off guardrail, but it stops collection once reached: avoid it on a security workspace.