Azure Monitor Cost Optimization: How to Reduce Log Analytics Spend

Azure Monitor and Log Analytics costs can spiral unexpectedly. A 20-node auto scaling cluster that scales to 80 nodes during peak traffic can triple your monitoring bill in hours if you’re on pay as you go pricing. Beyond auto scaling surprises, most Azure Monitor bills hide costs in three places: data ingestion volume, retention duration, and workspace configuration. According to the 2024 CNCF Annual Survey, 68% of organizations cite observability cost as a top infrastructure challenge, with cloud monitoring tools like Azure Monitor frequently named as the largest line item.

This guide walks through proven strategies to reduce Azure Monitor and Log Analytics costs without losing the visibility your team needs. Each step includes real cost numbers, configuration examples, and gotchas that Microsoft’s documentation does not surface.

Prerequisites

Before optimizing Azure Monitor costs, you need:

• Access to Azure Cost Management + Billing to view current Log Analytics workspace spending
• Owner or Contributor role on the Log Analytics workspaces you want to optimize
• Basic understanding of Kusto Query Language (KQL) to write data transformation queries if needed
• Current baseline of data ingestion volume per workspace (find this in Workspace Usage under Monitoring)
• List of all data sources sending logs to each workspace (VMs, AKS clusters, Application Insights, diagnostic settings)

Step 1: Audit Current Log Analytics Spend by Data Source

The first step is understanding where your Azure Monitor costs actually come from. Most teams assume Application Insights or VM logs dominate spend, but often Kubernetes control plane logs, Azure resource diagnostics, or third party connectors account for 40 to 60% of ingestion without anyone realizing it.

Navigate to your Log Analytics workspace in the Azure portal. Under Monitoring, select Usage and estimated costs. Click on Data Ingestion to see a breakdown by table.

Sort by ingestion volume. The tables at the top are your cost drivers. Common high volume tables include:

• AzureDiagnostics — diagnostic logs from Azure resources like App Service, Storage, AKS
• ContainerLog — stdout/stderr from Kubernetes pods
• Perf — performance counters from VMs
• Syslog — Linux VM system logs
• AppTraces, AppDependencies — Application Insights telemetry

Run this KQL query to see ingestion volume by source over the last 30 days:

Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize IngestedGB = sum(Quantity) / 1024 by DataType
| order by IngestedGB desc

This shows you which log types are consuming the most data. A single misconfigured Azure diagnostic setting can generate 500 GB per month of logs you never use.

Azure charges $2.99/GB for pay as you go ingestion in most regions. If ContainerLog shows 800 GB last month, that table alone costs $2,392 monthly before retention charges.

Once you identify the top 3 to 5 tables, investigate what is sending that data. For ContainerLog, check which AKS clusters and namespaces. For AzureDiagnostics, check which Azure resources have diagnostic settings enabled. For Perf, check which VMs and which performance counters are being collected.

Gotcha: Azure does not surface which specific resource sent each log entry in the Usage view. You have to query the actual table to find the source. For example, to see which AKS clusters are generating ContainerLog volume:

ContainerLog
| where TimeGenerated > ago(7d)
| summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by Computer
| order by GB desc

Replace Computer with the relevant dimension for other tables.

Step 2: Filter Logs at the Source with Data Collection Rules

The cheapest log to store is the one you never ingest. Azure Monitor uses Data Collection Rules (DCRs) to define what data gets collected from VMs, AKS clusters, and other sources. Most teams use default DCRs that collect everything, which is expensive and noisy.

Create a custom DCR to filter logs before they reach Log Analytics. This is called a transformation at ingestion time.

Navigate to Monitor > Data Collection Rules. Select the DCR associated with your VM or AKS cluster. Under Data Sources, select the data source you want to filter (for example, Performance Counters or Linux Syslog). Click Transformations.

In the transformation field, write a KQL filter to drop unwanted rows. For example, to drop all performance counter samples where CPU usage is below 50%:

source
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where CounterValue > 50

This drops ~70% of performance counter rows if your VMs are mostly idle, cutting ingestion volume proportionally. At $2.99/GB, filtering 200 GB monthly saves $598 per month.

For container logs, filter out noisy debug logs or known benign errors:

source
| where LogEntry !contains "healthcheck"
| where LogEntry !contains "metrics endpoint"
| where LogEntry !contains "readiness probe"

Gotcha: Transformations reduce ingestion cost but also remove data permanently. You cannot query filtered logs later. Only filter logs you have confirmed are not needed for troubleshooting or compliance.

For Kubernetes clusters, you can also reduce collection frequency. Under the DCR data source, change the sample rate from 60 seconds to 300 seconds for metrics like memory and disk. This cuts volume by 80% with minimal loss of visibility for slowly changing metrics.

Important limitation: DCRs only work for data collected via the Azure Monitor Agent (AMA). They do not filter Application Insights telemetry, Azure resource diagnostic logs, or logs sent directly via API. For those sources, use workspace level transformations (covered in Step 4).

Step 3: Switch to Commitment Tier Pricing

Azure Log Analytics charges $2.99/GB on the pay as you go tier. If you ingest more than 100 GB per day consistently, commitment tier pricing cuts that rate significantly.

Commitment tiers lock you into a daily ingestion commitment in exchange for a lower per GB rate. The tiers are:

• 100 GB/day: $2.30/GB (23% savings vs pay as you go)
• 200 GB/day: $2.05/GB (31% savings)
• 300 GB/day: $1.90/GB (36% savings)
• 500 GB/day: $1.70/GB (43% savings)

Commitment tier pricing applies across all workspaces in a resource group or subscription depending on how you configure it. This means you can consolidate multiple low volume workspaces into a single workspace to hit the tier threshold.

To switch to commitment tier:

Navigate to your Log Analytics workspace > Usage and estimated costs > Pricing tier. Select the tier that matches or slightly exceeds your daily average ingestion.

Critical gotcha: If you commit to 200 GB/day but only ingest 150 GB on a given day, you are billed for 200 GB anyway. The commitment is a minimum daily spend. Check your Usage graphs carefully before committing.

Run this query to calculate your average daily ingestion over the last 30 days:

Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize DailyGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d)
| summarize AvgGB = avg(DailyGB), MaxGB = max(DailyGB), MinGB = min(DailyGB)

If your minimum is close to your average, commitment tier is safe. If you see high variance (for example, 80 GB some days and 250 GB others), you will overpay on low days and underutilize the discount on high days.

For a workspace ingesting 180 GB/day consistently, switching from pay as you go ($2.99/GB) to the 200 GB/day tier ($2.05/GB) saves:

• Pay as you go: 180 GB × $2.99 = $538.20/day
• Commitment tier: 200 GB × $2.05 = $410/day
• Savings: $128.20/day = $3,846/month

If ingestion drops to 120 GB/day in a slow month, you pay for 200 GB anyway, wasting $164/day.

Step 4: Reduce Retention and Use Archive Tier

Azure Log Analytics charges for two things: ingestion and retention. Default retention is 31 days at no extra cost beyond ingestion. Extending retention to 90 days or longer adds $0.12/GB/month for interactive retention and $0.026/GB/month for long term archive.

Most teams enable 90 day retention across all tables without considering which logs actually need it. This doubles or triples total cost.

Reduce retention to 31 days for high volume, low value tables. Keep longer retention only for security logs, audit logs, and compliance-required data.

Navigate to your workspace > Tables. Select a table like ContainerLog. Under Table settings, set Data retention to 31 days.

For tables you need to keep for compliance but rarely query, use the Basic Logs tier or Archive tier:

• Basic Logs: $0.65/GB ingestion (78% cheaper than Analytics tier), 8 day retention, limited query capability
• Archive tier: $0.026/GB/month storage, queries incur search job costs

To move a table to Basic Logs tier:

Navigate to Tables > [table name] > Table plan. Select Basic.

Gotcha: Basic Logs tables cannot be queried with full KQL. You can only use simple filters. Do not move tables you query frequently (like AppTraces or AzureDiagnostics) to Basic tier.

For long term compliance, enable Archive tier:

Navigate to the table > Table settings > Archive tier. Set the archive retention period to match your compliance requirement (for example, 2 years).

Archived data costs $0.026/GB/month to store. Querying it costs $0.005/GB scanned, which means retrieving 100 GB of archived logs costs $0.50.

Example cost breakdown for a 500 GB/month table:

• Analytics tier, 90 day retention: 500 GB × ($2.99 + $0.12 × 2 months extra) = $1,615/month
• Analytics tier, 31 day retention: 500 GB × $2.99 = $1,495/month
• Basic Logs tier, 8 day retention: 500 GB × $0.65 = $325/month
• Analytics tier 31 days + Archive 2 years: 500 GB × $2.99 + (500 GB × 23 months × $0.026) = $1,495 + $299 = $1,794/month total, but you keep 2 years of searchable compliance data

The correct choice depends on query frequency and compliance requirements.

Step 5: Consolidate Workspaces to Maximize Commitment Tier Discounts

Many Azure subscriptions have 5 to 10 Log Analytics workspaces created by different teams or for different environments. Each workspace ingests 30 to 80 GB/day, which is too low to benefit from commitment tier pricing.

Consolidating workspaces into a single shared workspace allows you to hit higher commitment tiers and get deeper per GB discounts.

For example, consolidating 5 workspaces each ingesting 60 GB/day (300 GB/day total) onto the 300 GB/day commitment tier saves 36% vs pay as you go.

To consolidate workspaces:

1. Identify workspaces with low ingestion that serve similar purposes (for example, dev and staging VMs, or multiple AKS clusters).
2. Reconfigure data sources (VMs, AKS, diagnostic settings) to send logs to the target consolidated workspace.
3. Update any KQL queries, alerts, or dashboards to reference the new workspace.
4. Delete the old workspaces after confirming all data flows to the new one.

Gotcha 1: Azure Role Based Access Control (RBAC) is workspace scoped. Consolidating workspaces means team A can now query team B’s logs unless you configure table level RBAC. This is possible but adds complexity.

Gotcha 2: Some compliance or data residency requirements mandate separate workspaces per region or per compliance boundary. Do not consolidate across these boundaries.

Use Azure Cost Management to model the savings. If workspace A ingests 50 GB/day at $2.99/GB and workspace B ingests 70 GB/day at $2.99/GB, consolidating both into a single workspace on the 200 GB/day tier ($2.05/GB) saves:

• Before: (50 + 70) GB × $2.99 = $358.80/day
• After: 200 GB × $2.05 = $410/day (commitment minimum, even though actual ingestion is 120 GB)
• Actual cost with 120 GB ingestion: 120 GB × $2.05 = $246/day
• Savings if ingestion stays above 120 GB: $358.80 – $246 = $112.80/day = $3,384/month

Step 6: Optimize Application Insights Sampling

Application Insights is part of Azure Monitor and sends telemetry to Log Analytics. By default, Application Insights uses adaptive sampling to keep ingestion under control, but it is not always aggressive enough for high traffic apps.

Enable sampling at the SDK level to reduce telemetry volume before it reaches Azure. Sampling discards a percentage of traces, requests, and dependencies while retaining representative samples for debugging.

For ASP.NET Core apps, configure sampling in appsettings.json:

{
  "ApplicationInsights": {
    "SamplingSettings": {
      "IsEnabled": true,
      "MaxTelemetryItemsPerSecond": 5,
      "EvaluationInterval": "00:00:15"
    }
  }
}

This limits telemetry to 5 items per second, which cuts ingestion by 80 to 90% for high traffic services while keeping enough samples to detect errors and latency spikes.

For client side JavaScript, configure sampling in the Application Insights JavaScript snippet:

var appInsights = new Microsoft.ApplicationInsights.ApplicationInsights({
  config: {
    instrumentationKey: "YOUR_KEY",
    samplingPercentage: 10
  }
});

A 10% sampling rate means 90% of page views, AJAX calls, and exceptions are discarded at the client. This is safe for most web apps because Application Insights aggregates metrics server side, so your charts and dashboards remain accurate.

Gotcha: Sampling reduces raw event volume but does not affect aggregated metrics like request rate, average response time, or error rate. These are computed before sampling. However, drilling into individual traces or exceptions shows fewer samples, which can make debugging harder for rare edge cases.

Cost impact: A single high traffic web app generating 200 GB/month of Application Insights telemetry costs $598/month at $2.99/GB. Enabling 20% sampling drops ingestion to 40 GB/month, reducing cost to $119.60/month — a $478 monthly saving.

Step 7: Use Azure Cost Management Alerts to Avoid Surprises

Azure Monitor costs can jump unexpectedly when a new service starts logging, an AKS cluster scales up, or a diagnostic setting is enabled by mistake. Setting up cost alerts prevents bill shock.

Navigate to Cost Management + Billing > Cost alerts > Add alert. Create a budget alert for your Log Analytics workspace resource group.

Set the alert threshold to trigger when forecasted spend exceeds your expected monthly budget by 10%. For example, if your baseline is $2,000/month, set the alert to fire at $2,200 forecasted.

Configure the alert to email your team’s ops channel or post to a Slack webhook.

For real time ingestion monitoring, create a KQL alert in Azure Monitor:

Usage
| where TimeGenerated > ago(1h)
| where IsBillable == true
| summarize HourlyGB = sum(Quantity) / 1024
| where HourlyGB > 10

This fires an alert if ingestion exceeds 10 GB in any single hour, which would extrapolate to 240 GB/day — well above normal for most workspaces.

Troubleshooting Common Issues

Issue: Commitment tier pricing is costing more than pay as you go because ingestion dropped after committing.

Fix: Downgrade to a lower commitment tier or switch back to pay as you go. Azure allows tier changes once per 31 days. Navigate to Pricing tier and select the new tier. The change takes effect the next day.

Issue: Filtering logs with DCRs is not reducing ingestion volume as expected.

Fix: Verify the transformation query syntax is correct by testing it in Log Analytics first. Transformations fail silently if the KQL is invalid. Also confirm the DCR is actually associated with the data source — check Monitor > Data Collection Rules > Associations.

Issue: Application Insights sampling is discarding critical error traces.

Fix: Application Insights uses priority based sampling that always keeps exceptions and failed requests. If exceptions are being sampled out, your sampling rate is too aggressive. Increase samplingPercentage from 10% to 50% or disable sampling entirely for error telemetry.

Issue: Workspace consolidation broke existing alerts and dashboards.

Fix: Update alert query scopes to point to the new workspace. For Azure dashboards, edit each tile and reselect the workspace. For Grafana or third party dashboards, update the workspace ID in the data source configuration.

Azure Monitor costs are predictable once you understand the ingestion and retention model. Teams that audit data sources, enable commitment tiers, and filter unnecessary logs typically cut Log Analytics spend by 40 to 60% without losing operational visibility.

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions