Azure Log Analytics Workspace Pricing: What Actually Drives Your Bill

A customer called us last quarter after their Log Analytics bill tripled in 60 days. Nobody had changed a policy. A new Defender for Servers P2 rollout had silently started pushing SecurityEvent at full verbosity across 800 VMs. Three meters were running; they were only watching one.

That story is common. The workspace pricing model has enough moving parts that a single onboarding decision, like enabling a Diagnostic Setting on an AKS cluster, can shift your monthly cost by thousands of dollars before anyone notices. This post walks through every meter and what to do about each.

How the Ingestion Bill Actually Works

Microsoft charges for data the moment it lands in the workspace, before any query ever touches it. There are two ingestion pricing tracks.

Pay-as-you-go runs at roughly $2.76 per GB in East US (other regions vary 5-15%). No commitment, no lock-in. It is the right choice up to about 80 GB/day; below that threshold, commitment tiers do not break even.

Commitment tiers are per-workspace reservations in steps: 100, 200, 300, 400, 500, 1000, 2000, and 5000 GB/day. At 100 GB/day the effective per-GB rate drops to around $1.96. At 500 GB/day it is closer to $1.50/GB. The tiers auto-renew daily and you pay for the reservation whether or not you hit it, so the math only works if your workspace is consistently 80-85% full on that tier.

One thing operators miss: commitment tiers apply per workspace, not per subscription. If you split your environment across four workspaces because someone once said "keep prod separate," you may be paying pay-as-you-go rates four times over instead of qualifying for a 100 GB/day commitment tier on a consolidated workspace. Workspace consolidation is often the single largest cost lever.

Basic Logs vs Analytics Logs

Every table in a workspace is one or the other. The distinction matters more than most teams realize.

Analytics Logs is the default. Full KQL, all aggregation functions, interactive query, ingestion at ~$2.76/GB, and 90 days of interactive retention included.

Basic Logs costs roughly $0.50/GB to ingest, eight days of interactive retention, and you lose most KQL operators. No summarize, no join, no time-series functions. You can still run simple where and project filters. The query charge is $0.006 per GB scanned rather than included in the ingestion fee.

The tables that make sense on Basic Logs are high-volume, low-query-frequency: ContainerLog, AzureDiagnostics from verbose resources, raw Syslog from appliances you rarely investigate, and AppTraces from dev environments. For a busy AKS cluster pushing 20 GB/day of container logs you might query twice a month during incidents, the math is clear: $0.50 versus $2.76 per GB, with a $0.006 per GB scan charge when you actually need the logs. At 600 GB/month, that is $300 versus $1,656 in ingestion alone.

To flip a table, navigate to the workspace in the portal, go to Tables, select the table, and set the plan to Basic. You can also do it via the REST API or ARM/Bicep:

resource logTable 'Microsoft.OperationalInsights/workspaces/tables@2022-10-01' = {
  name: '${workspaceName}/ContainerLog'
  properties: {
    plan: 'Basic'
    retentionInDays: 8
  }
}

Not every table supports the Basic plan. Microsoft publishes the supported list in their docs; check it before designing your table strategy.

Retention: Three Tiers, Two Meters

Interactive retention is the period during which you can run full KQL against the data. The default is 30 days for most tables. Tables associated with Microsoft Sentinel get 90 days at no extra charge. Beyond the interactive window, data moves to long-term (archive) retention automatically if you configure it, at around $0.02 per GB per month.

Archive retention supports "Search Jobs," which are asynchronous queries that restore data into a temporary Analytics table you can then query normally. Search Jobs cost $0.006 per GB scanned. This is cheaper than keeping data in interactive retention if you are holding it for compliance and querying it less than a few times per year.

The practical setup: set interactive retention to 30-90 days depending on SOC SLA, then archive for 1-2 years, then purge. Anything beyond two years usually belongs in cold storage, not a Log Analytics workspace.

Sentinel's Second Meter

If Microsoft Sentinel is enabled on the workspace, every billable byte pays two bills: the Log Analytics ingestion fee and the Sentinel ingestion fee. Sentinel's pay-as-you-go rate is around $2.46/GB. Sentinel also has its own commitment tiers (100 GB/day and up) that run independently of the workspace tiers.

There is a nuance most people miss: certain Microsoft-first data sources are free for Sentinel ingestion. Microsoft Defender for Cloud alerts, Azure Activity, Microsoft Entra sign-in and audit logs, Office 365 audit, and a handful of others do not count against the Sentinel meter even though they appear in the workspace. The workspace meter still runs; only the Sentinel surcharge is waived.

The implication: always enable those free connectors before reaching for a paid third-party connector that duplicates the same data. We have seen environments paying for a SIEM connector that pulled Entra sign-in logs from a third-party source when the native free connector was sitting unconfigured.

Cutting Volume with DCR Transformations

Data Collection Rules now support ingestion-time transformations using a subset of KQL. The data never lands in the workspace if you filter it out at the DCR layer, so you pay nothing for it.

A common pattern for SecurityEvent: filter out noise events before ingestion. Event IDs 4662, 4688 (process creation from non-critical sources), and 4703 generate enormous volume from domain controllers and rarely contribute to detections.

source
| where EventID !in (4662, 4688, 4703)
| project TimeGenerated, Computer, EventID, Account, Activity, EventData

That KQL goes into the DCR transformation field on the destination table. Dropped rows are gone permanently; this is a one-way door, so test on a low-priority workspace first and validate against your detection rules before applying to production.

DCR transformations also let you drop entire columns. If you ingest firewall logs and you do not need the raw packet payload field, dropping it at ingestion can cut table size 15-30% with no detection impact.

The KQL Query You Should Run Before Anything Else

Before optimizing, measure. This query gives you 30 days of ingestion by table, sorted by volume, with a rough pay-as-you-go cost estimate. Run it in your workspace and share the output with whoever owns the budget conversation.

Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize IngestedGB = round(sum(Quantity) / 1024, 2) by DataType
| order by IngestedGB desc
| project
    DataType,
    IngestedGB,
    EstimatedPayGoCostUSD = round(IngestedGB * 2.76, 2)

The top five tables by IngestedGB are almost always where the work is. We have run this across dozens of environments; ContainerLog, AzureDiagnostics, Syslog, SecurityEvent, and Heartbeat collectively account for 60-80% of ingestion in most production workspaces. Each of those has a mitigation path: Basic Logs eligibility, DCR filtering, or collection frequency reduction.

Once you know the breakdown, the optimization sequence is: consolidate workspaces to hit commitment tier thresholds, move high-volume low-query tables to Basic Logs, apply DCR transformations to filter noise before ingestion, then tune interactive retention windows. In most environments that sequence gets costs down 30-50% without losing any data you actually need.

For a deeper look at how this fits into a detection engineering architecture, see our detection engineering practice.

When you are ready to have someone audit your workspace configuration and benchmark it against what you should actually be paying, reach out and we will do the review.