How to reduce Log Analytics costs and keep the logs you need

To reduce Azure Log Analytics costs, first find the three or four tables that hold most of your billable volume (the Usage table tells you in one query). Then stop collecting what nobody reads, move verbose tables to the Basic or Auxiliary plan, shorten interactive retention and push compliance data into long-term retention. Consider a commitment tier only after the volume has come down.

The order matters. The tempting first move is the commitment tier, because it is a single setting. Do it first and you lock in a daily volume for 31 days, then cut ingestion underneath it and pay for capacity you no longer use.

What are you actually paying for?

Azure Monitor Log Analytics bills mostly on two things: the gigabytes you ingest and how long you keep them. Each table in a workspace has a table plan, a per-table setting that decides the ingestion price, whether queries cost extra and how retention behaves. One workspace can mix all three plans.

List prices as of October 2026, East US, pay-as-you-go:

Some data is free: the AzureActivity, Heartbeat, Usage and Operation tables carry no ingestion charge, and the _IsBillable column on every record tells you whether it was billed. The first 5 GB per month per billing account on pay-as-you-go Analytics ingestion is also free.

Which tables are costing you the most?

Open the workspace, select Logs, and run this. It is the query from Microsoft's own usage analysis guide, with an illustrative dollar column added.

// Billable GB per table over the last 31 days
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableGB = round(sum(Quantity) / 1000, 1) by DataType, Solution
| extend EstMonthlyUSD = round(BillableGB * 2.30, 0) // Analytics PAYG list, East US
| order by BillableGB desc

// Billable GB per table over the last 31 days
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableGB = round(sum(Quantity) / 1000, 1) by DataType, Solution
| extend EstMonthlyUSD = round(BillableGB * 2.30, 0) // Analytics PAYG list, East US
| order by BillableGB desc

// Billable GB per table over the last 31 days
Usage
| where TimeGenerated > ago(32d)
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableGB = round(sum(Quantity) / 1000, 1) by DataType, Solution
| extend EstMonthlyUSD = round(BillableGB * 2.30, 0) // Analytics PAYG list, East US
| order by BillableGB desc

The Usage table also has a Plan column (added in mid-May 2026), so you can add Plan to the by clause and see which plan each table is on. Older rows have it empty.

In mid-market tenants the list is usually short and top-heavy. The names that keep coming back:

• AzureDiagnostics, fed by diagnostic settings created with every log category ticked, often for Key Vault, Application Gateway, SQL or Front Door.

• ContainerLog or ContainerLogV2, every line of stdout from every pod in every AKS namespace, including the chatty ones.

• AKSAudit from the kube-audit category. Microsoft's AKS monitoring guide calls out kube-audit as a source of substantial cost.

• AppTraces and AppDependencies from Application Insights with sampling turned off.

• Perf and InsightsMetrics, with counters polled far more often than anyone charts them.

If you inherited several workspaces, run the same query in each. Then list them all with Azure Resource Graph to see retention, commitment tier and daily cap in one place:

resources
| where type =~ 'microsoft.operationalinsights/workspaces'
| project name, resourceGroup, location,
    sku = tostring(properties.sku.name),
    commitmentGBPerDay = toint(properties.sku.capacityReservationLevel),
    retentionDays = toint(properties.retentionInDays),
    dailyCapGB = todouble(properties.workspaceCapping.dailyQuotaGb)
| order by retentionDays desc

resources
| where type =~ 'microsoft.operationalinsights/workspaces'
| project name, resourceGroup, location,
    sku = tostring(properties.sku.name),
    commitmentGBPerDay = toint(properties.sku.capacityReservationLevel),
    retentionDays = toint(properties.retentionInDays),
    dailyCapGB = todouble(properties.workspaceCapping.dailyQuotaGb)
| order by retentionDays desc

resources
| where type =~ 'microsoft.operationalinsights/workspaces'
| project name, resourceGroup, location,
    sku = tostring(properties.sku.name),
    commitmentGBPerDay = toint(properties.sku.capacityReservationLevel),
    retentionDays = toint(properties.retentionInDays),
    dailyCapGB = todouble(properties.workspaceCapping.dailyQuotaGb)
| order by retentionDays desc

A daily cap of -1 means no cap.

Step 1: stop collecting what nobody reads

The cheapest gigabyte is the one never sent. For each table at the top of your list, ask who queried it in the last 90 days and which alert depends on it. If nobody can answer, it is a candidate.

The common fixes:

• Diagnostic settings. Edit them to send only the categories you use. For AKS, Microsoft recommends disabling kube-audit when it is not required and collecting kube-audit-admin instead, which excludes get and list events.

• VM insights. If nobody uses the Map feature, disable process and dependency collection.

• Performance counters. Lower the polling frequency in the data collection rule.

• Duplicates. Machines that send the same data to two workspaces, or run both the legacy Log Analytics agent and the Azure Monitor agent, pay twice.

• Container logs. Use the Container insights logs presets, and collect stderr without stdout for namespaces where stdout is noise.

When you need to keep part of a stream, use an ingestion-time transformation: a KQL statement inside a data collection rule (DCR) that filters rows or drops columns before they are stored. Diagnostic settings cannot filter by row, so for those you use the workspace transformation DCR, provided the destination table supports it. A typical example keeps only warning and error rows from a verbose application table.

There is one billing rule to know. For Analytics and Basic tables, if a transformation drops more than half of the incoming data, you pay a processing charge on the portion above 50 percent. Microsoft's example: 20 GB arrives, the transformation drops 12 GB, so 2 GB is billed as processing and 8 GB as ingestion. That is still far cheaper than ingesting all 20 GB, but if you can filter at the source (fewer diagnostic categories, a quieter logger), do that first. In a workspace with Microsoft Sentinel enabled, transformations into Analytics tables carry no processing charge regardless of how much they drop.

Step 2: move verbose tables to Basic or Auxiliary

Many tables are written constantly and read only during an incident. Paying the Analytics price for those is the most common overspend we see in Log Analytics.

Before you switch a table, check three constraints. Not every table supports every plan: as of October 2026, Microsoft's table support reference lists ContainerLogV2, AppTraces, AKSAudit, StorageBlobLogs and the Azure Firewall resource-specific tables as Basic-eligible, but not AzureDiagnostics or the older ContainerLog table. That is one more reason to switch diagnostic settings to resource-specific mode and to move Container insights to ContainerLogV2. Second, you can change a table's plan once a week. Third, moving an Analytics table to Auxiliary stops the alerts that read it, so check alert rules first.

Example, with the list prices above: an AKS cluster writes 10 GB a day to ContainerLogV2, about 300 GB a month. On Analytics that is roughly $690 a month. On Basic it is $150, and even if the team scans the full 30 days ten times during incidents that month (3,000 GB scanned), the query charge is $15.

az monitor log-analytics workspace table update \
  --resource-group rg-monitoring \
  --workspace-name law-prod \
  --name ContainerLogV2 \
  --plan Basic

az monitor log-analytics workspace table update \
  --resource-group rg-monitoring \
  --workspace-name law-prod \
  --name ContainerLogV2 \
  --plan Basic

az monitor log-analytics workspace table update \
  --resource-group rg-monitoring \
  --workspace-name law-prod \
  --name ContainerLogV2 \
  --plan Basic

Step 3: set retention per table, not per workspace

Workspace retention is the default for every Analytics table that has no table-level setting. Teams raise it to 365 or 730 days "for compliance" and every table inherits it, including the noisy ones nobody will ever query a year later.

Each table has two numbers: analytics (interactive) retention, and total retention, which can go up to 12 years. The gap between them is long-term retention, read back through search jobs. Example: a workspace ingests 300 GB a month into Analytics tables and keeps everything interactive for 365 days. At steady state about 3,300 GB sits beyond the included 31 days, which is roughly $330 a month at $0.10. Keeping the same data in long-term retention instead costs about $66.

Rules worth knowing before you change anything:

• Setting analytics retention below 31 days saves nothing; those days are included in the ingestion price.

• When you shorten total retention, Azure Monitor waits 30 days before removing the data, so a mistake can be reverted.

• Purging data does not lower retention charges, and deleting a custom table does not delete its data. Only a shorter retention period does.

• Usage and AzureActivity keep 90 days at no charge. Application Insights tables also get 90 days included.

Step 4: pick a commitment tier last

A commitment tier is a daily ingestion volume you commit to per workspace in exchange for a lower per-GB rate. As of October 2026 in East US, the 100 GB/day tier lists at $196 a day, which works out to $1.96 per GB against $2.30 on pay-as-you-go. The break-even is about 85 GB a day of Analytics ingestion. Higher tiers discount more.

The rules: the commitment lasts 31 days, you can move up at any time (which restarts the 31 days), and you can only move down or back to pay-as-you-go after the period ends. If you pick the wrong tier, you have six hours to lower it. Overage above the tier is billed at the tier's effective rate. Commitment tiers apply only to Analytics ingestion; Basic and Auxiliary are flat rates.

The workspace's "Usage and estimated costs" page shows what your last 31 days would have cost at each tier. Do steps 1 to 3 first, wait two weeks for the new baseline, then read that page.

What changes when Microsoft Sentinel is on the workspace?

When Microsoft Sentinel is enabled on a workspace, all data in that workspace is subject to Sentinel charges on top of Log Analytics. That is why Microsoft suggests keeping operational and security data in separate workspaces. The exception is when neither stream is big enough for a commitment tier alone but the combined volume is.

Two more details. With Sentinel enabled, Basic and Auxiliary ingestion is billed through Sentinel meters, so the table plan saving looks different on the invoice. And if you run Microsoft Defender for Servers, it grants 500 MB per server per day of allowance for a defined set of security tables, such as SecurityEvent, which changes the economics of moving those tables.

Keep it from creeping back

Ingestion grows quietly: a new diagnostic setting here, a debug log level left on there. Two controls catch it early. Create a log search alert on the Usage table (Microsoft's sample fires when billable volume in 24 hours passes 50 GB; pick your own threshold). And turn on Azure Advisor alerts for the Log Analytics cost recommendations, which flag tables eligible for Basic and ingestion anomalies. Advisor will not tell you who owns the table, which is the gap we describe in what Azure Advisor does not do.

Avoid the daily cap as a cost tool. It stops collection for the rest of the day once reached, which is usually the day you need the logs.

If Log Analytics shows up as the line that moved in your bill this month, the 30-minute bill diagnosis will confirm it before you start cutting. Workspace retention above 90 days is one of the checks Elos runs every week; the per-table review above still needs someone who knows which logs the team reads. If you want a quick sense of where you stand overall, the FinOps Score takes ten questions.

Frequently asked questions

How much does Azure Log Analytics cost per GB?

As of October 2026, pay-as-you-go list price in East US is $2.30 per GB for the Analytics plan, $0.50 per GB for Basic and $0.05 per GB for Auxiliary, which also carries a processing charge. Analytics includes 31 days of retention. Prices vary by region and agreement, so check the Azure Monitor pricing page for your own region before you build a business case.

What is the difference between Basic Logs and Auxiliary Logs?

Both are cheaper table plans than Analytics, and both charge per GB scanned when you query. Basic keeps fast queries for 30 days and supports simple log search alerts. Auxiliary is the cheapest to ingest, queries are slower, and alerts stop working on the table. Use Basic for troubleshooting data and Auxiliary for audit data you rarely read.

Does reducing Log Analytics retention below 31 days save money?

No. The ingestion price of an Analytics table already includes 31 days of analytics retention, so setting a table to 7 or 14 days removes data without lowering the bill. Savings start when you shorten retention that is above 31 days, or when you move older data into long-term retention, which is billed at a much lower per-GB monthly rate.

Should I set a daily cap on my Log Analytics workspace?

Only as a safety net. A daily cap stops data collection for the rest of the day once the limit is reached, which means you lose the logs you would need during an incident. Microsoft's own guidance says not to use it as a cost reduction method. Fix ingestion at the source and add an alert on billable volume instead.

Sources

• Azure Monitor Logs cost calculations and options

• Analyze usage in a Log Analytics workspace

• Manage data retention in a Log Analytics workspace

• Configure a table plan in a Log Analytics workspace

• Data collection transformations in Azure Monitor

• Cost optimization in Azure Monitor

• Azure Monitor pricing