In many of the Azure environments I review, Log Analytics costs keep climbing month after month, and once Sentinel is added the bill can grow quickly. Teams are often surprised that most data goes into the Analytics plan by default, even for tables nobody queries in depth very often. Using table plans, targeted retention and a bit of KQL, you can get Log Analytics costs under control and still keep the visibility you actually need.

Every table in a workspace runs on the Analytics, Basic or Auxiliary plan

Since 2023 you can assign one of three plans to each table in a Log Analytics workspace: Analytics, Basic or Auxiliary. Analytics is the default. It gives you full KQL, fast search, alerts, workbooks and integration with Sentinel, Defender XDR and other services. Basic costs much less per GB but has serious limitations. Many advanced KQL operators (like 'join', 'parse', 'summarize' for long time spans) are blocked, and those logs can't feed workbooks or most automations. If all you need is cheap storage for occasional, targeted incident investigations, Basic can still work. Auxiliary sits between the two and usually suits high-volume app or diagnostic logs that you rarely query. Not every table supports every plan. To see what's available for a given table, open your Log Analytics workspace → Tables (official docs).

The cheaper plans charge for every GB a query scans

The Analytics plan bills per ingested GB, and all interactive queries (plus most exports) are included. Basic and Auxiliary cost much less at ingestion, but each interactive query is billed per GB scanned. This catches people out. If someone starts hunting through several months of data, the query charges can easily outweigh whatever you saved. Retention works differently as well. Analytics offers interactive retention (free for up to e.g. 30 days, then paid) plus long-term retention for up to 12 years, which is cheaper but only exportable, with no interactive KQL. Basic and Auxiliary also support retention, but only for basic search, not for advanced queries or long-term analytics. The retention documentation has the details.

To change the plan for a table, go to Log Analytics workspace → Tables → Pick a table → Manage table → Table plan. I much prefer this to cutting retention across the board. Keep in mind that commitment tiers (the volume discounts in Log Analytics) only apply to Analytics data. Basic and Auxiliary usage is always billed separately.

The Usage table shows which tables drive your costs

Before I change any plans, I check which tables are actually responsible for the costs. The Usage table makes this easy. In Log Analytics workspace → Logs, the following KQL query lists the data types (tables) that consumed the most GB over the last 30 days:

Usage
| where TimeGenerated > ago(30d)
| summarize DataGB=sum(Quantity) by DataType
| sort by DataGB desc

The result shows your top cost drivers within seconds, and that's where your table plan and data collection work should start. Microsoft has more guidance on usage analysis.

DCR transformations drop noise before it reaches your bill

Transforming logs at ingestion is an effective option that few teams use. Data Collection Rule (DCR) transformations let you filter or drop events before they're stored at all. For noisy sources such as Windows Security events, Diagnostics or App Insights logs, this makes a big difference. In the Azure portal, go to Data Collection Rules → Select a DCR → Transformations and define your KQL filters there. To keep only certain EventIDs, for example:

where EventID in (4624, 4625, 4634)

My tip: Work out which events and fields you really need before you filter anything, and test DCR transformations in a non-production workspace first.

My guide on replacing the Log Analytics Agent has more practical advice on this.

In my experience, visibility beats blind cuts

When Log Analytics costs get too high, the first instinct is often to reduce retention everywhere. What works better in practice is finding your largest tables, picking table plans carefully and dropping data you don't need with DCR transformations. Add a well-chosen commitment tier and log costs stay manageable even as the environment grows. Analyzing usage first always pays off, and it spares you unpleasant surprises on the invoice.

flowchart TD
    A["Log source"] --> B["DCR transformation"]
    B --> C["Table in workspace"]
    C --> D["Choose table plan"]
    D --> E["Configure retention"]
    C --> F["Usage analysis (KQL)"]

Figure: Each step from log source through DCR, table plan and usage analysis helps keep Log Analytics costs in check.