Log Analytics cost guardrails are the difference between “we understand our telemetry spend” and “why did Tuesday cost more than the team lunch budget?” Azure Monitor is powerful, but a Log Analytics workspace gets expensive fast when every diagnostic setting, agent and solution sends everything forever.
This guide shows how to control ingestion, retention, table plans and daily-cap blast radius without going blind. The goal isn’t collecting less because Finance is unhappy; it’s collecting the right logs, keeping them at the right temperature, and still having evidence when production breaks.
Log Analytics cost guardrails start with what’s billable
The cost model is workspace-based, driven by the services enabled, the number and type of resources monitored, and how much data each sends. One enthusiastic diagnostic setting forwarding every verbose category can change the bill overnight.
Start with the Usage table, which Microsoft documents for understanding billable volume:
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000 by bin(StartTime, 1d), DataType
| render columnchartIf your workspace has the Plan column, break ingestion down by table plan too:
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000 by bin(StartTime, 1d), Plan
| render columnchartA triage loop for ingestion spikes
When ingestion jumps, don’t reach for a daily cap first. A cap stops collection at the threshold, which can break monitoring, alerting and troubleshooting. Treat it as an airbag, not the steering wheel.
- Confirm the spike with Workspace Insights, Usage and estimated costs, and the
Usagetable. - Identify the contributor by solution, table, resource and diagnostic setting.
- Check recent changes: new diagnostic settings, VM or AKS onboarding, verbose app telemetry, Sentinel onboarding or duplicate forwarding.
- Apply the narrowest fix: filter noise, change a table plan, shorten interactive retention or route audit-only data to storage.
- Verify for several days and keep an alert in place.
A diagnostic setting can send to one destination of each type, and a resource can have up to five settings, so duplicate routing is easy. If policy deploys your settings, see Azure diagnostic settings policy, and use Azure Resource Graph queries to catch configuration drift.
Use table plans deliberately
Log Analytics offers Analytics, Basic and Auxiliary table plans. Choose by how people and automation use the data: tables behind alerts, dashboards and incident response stay hot; tables you only query for occasional audits may suit a cheaper plan where supported.
| Plan | Good fit | Watch out for |
|---|---|---|
| Analytics | Alerts, near-real-time troubleshooting, dashboards, complex KQL. | Higher ingestion cost; don’t default every noisy table to it. |
| Basic | Debugging, troubleshooting and infrequently queried audit logs. | Limited features and query charges; check alert and report dependencies. |
| Auxiliary | Verbose, high-volume, long-term data and trend storage. | No alerts on that table, and access patterns change. |
Plans can only be switched once per table per week, so test before you change.
Retention: keep hot data hot and cold data cheap
Microsoft distinguishes analytics retention, for active queries and troubleshooting, from long-term retention, which is cheaper and accessed through search jobs. Total retention can run far longer than the interactive period, so you don’t pay premium rates for evidence you rarely touch.
- Operational troubleshooting: enough analytics retention for your incident and postmortem patterns.
- Audit and evidence: long-term retention or export to storage where interactive query isn’t needed.
- Development noise: reduce it at the source rather than paying to retain it.
- Sentinel workspaces: be deliberate, since security and operational data have different cost and access needs.
Set retention per table by purpose. If everything has identical retention, make sure that’s a requirement and not just an untouched slider.
Filter predictable noise before ingestion
If the same low-value records arrive daily, filter them before they land. Standard transformations use KQL in a data collection rule, and newer multi-stage transformations process data through ordered pipeline stages. Good candidates: chatty informational events, known health-check noise, verbose custom app logs, and fields that should be dropped before storage. Reduce the data before the meter runs.
Daily caps are emergency brakes
A daily cap stops collection of billable Analytics and Basic data once the workspace hits the threshold for the 24-hour period. Microsoft is clear that monitoring can be affected and events lost; Auxiliary tables aren’t subject to it.
- Alert first, at a warning threshold below the cap.
- Set the cap above normal so it catches runaway spikes, not ordinary Tuesdays.
- Document the blast radius: which alerts, dashboards and teams depend on the workspace.
- Review every hit as an incident signal.
Log Analytics cost guardrails runbook
| Step | Action | Output |
|---|---|---|
| 1 | Export 31 days of billable ingestion by table and solution. | A baseline and top contributors. |
| 2 | Review diagnostic settings for duplicate destinations and noisy categories. | Cleaner routing. |
| 3 | Classify high-volume tables by operational need. | Analytics, Basic or Auxiliary candidates. |
| 4 | Set table-specific retention. | Useful hot data, cheaper cold evidence. |
| 5 | Add ingestion alerts, then a cautious daily cap. | Warning before monitoring goes dark. |
| 6 | Recheck after onboarding new services or policies. | No surprise bills. |
The useful log is the one you can afford to keep and find during an incident. Log Analytics cost guardrails make monitoring more intentional, not weaker: measure, classify, tune retention, filter noise, alert early and keep daily caps for true runaways. Pair this with Azure Service Health alerts for platform-level signals.
Last reviewed: October 2026
Sources
- Azure Monitor Logs cost calculations and options (Microsoft Learn)
- Set a daily cap on a Log Analytics workspace (Microsoft Learn)
- Manage data retention in a Log Analytics workspace (Microsoft Learn)
- Configure table plans (Microsoft Learn)
- Analyze usage in a Log Analytics workspace (Microsoft Learn)
- Transformations in Azure Monitor (Microsoft Learn)
- Cost optimization in Azure Monitor (Microsoft Learn)
Discover more from Cloud Osprey
Subscribe to get the latest posts sent to your email.
