Optimising Azure Monitor Ingestion Costs: What to Log and What Not To

Azure Monitor Log Analytics is billed primarily on data ingestion volume. As environments grow and diagnostic settings are enabled across more resources, ingestion costs can increase significantly, often without a corresponding increase in the value derived from the data being collected.

Cost optimisation is a key pillar of the Azure Well-Architected Framework. This post outlines a structured approach to reducing Log Analytics ingestion costs without compromising on operational visibility.

1. Understanding Ingestion Pricing

Log Analytics uses a tiered pricing model. The Pay-As-You-Go rate applies to all ingestion above any commitment tier purchased. Commitment tiers (100 GB/day, 200 GB/day, and higher) offer significant per-GB discounts for workspaces with consistent, predictable ingestion volumes.

Before optimising individual log sources, it is worth reviewing the workspace's current daily ingestion volume to determine whether a commitment tier would reduce overall cost.

Navigate to Log Analytics workspace > Usage and estimated costs to see the current daily ingestion volume and a comparison of what each commitment tier would cost at that volume.

2. Identifying High-Volume Log Sources

The first step in any ingestion optimisation exercise is understanding where the data is coming from.

Following is a KQL query to rank data types by ingestion volume:

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

In most environments, a small number of data types, typically AzureDiagnostics, SecurityEvent, or Syslog, account for the majority of ingestion. Focus optimisation effort on these sources first.

3. Reviewing Diagnostic Settings

Diagnostic settings control which log categories and metrics are sent from Azure resources to Log Analytics. Many resources have categories enabled by default that are rarely queried in practice.

Navigate to any Azure resource > Diagnostic settings and review the enabled categories. Common categories that can often be disabled without impacting operations include:

• AuditEvent logs for services with low change frequency
• AllMetrics when the same data is already available through Azure Monitor Metrics at no additional cost
• Verbose activity categories on services such as Azure API Management (GatewayLogs at DEBUG level)

Disabling a single verbose category on a high-throughput service can reduce ingestion by several gigabytes per day.

4. Using Data Collection Rule Transformations to Filter

Data Collection Rules (DCRs) support ingestion-time transformations using KQL. This allows specific rows or columns to be filtered out before they are written to the workspace, reducing billable ingestion volume.

Following is an example transformation that filters SecurityEvent rows to retain only events with EventID in a defined allow-list:

source
| where EventID in (4624, 4625, 4648, 4720, 4726)

Navigate to Azure Monitor > Data Collection Rules, select the relevant DCR, and open the Data sources tab to configure the transformation on the applicable data source.

5. Setting Table-Level Retention

Not all data needs to be retained in the hot (interactive) tier for the same duration. Log Analytics supports per-table retention settings, with data beyond the interactive period moving to low-cost archival storage.

Navigate to Log Analytics workspace > Tables, select a table, and choose Manage table to configure the interactive retention period. For high-volume, low-query-frequency tables such as AzureDiagnostics, reducing interactive retention from 90 days to 30 days can meaningfully reduce workspace cost.

Summary

Reducing Log Analytics ingestion costs requires understanding the workspace's data profile before making any changes. Identifying the top ingestion sources, reviewing diagnostic settings for unnecessary categories, applying DCR transformations to filter noisy data, and right-sizing table retention periods are the four most impactful levers available, none of which require compromising on the logs that matter.