Why Is Azure Log Analytics So Expensive? What to Check First

01 / Read the charges

What are you actually paying for?

A Log Analytics workspace is where Azure stores collected logs in tables. Those logs can come from your applications, virtual machines, containers, and other services.

The word ingestion means bringing data into that workspace. It is an important number because a busy application can send a large amount of data every day.

• Ingestion: the billable data you send in, measured in GB. The rate depends on the table plan, region, and pricing arrangement.
• Retention: keeping data beyond the period included for that data and plan.
• Queries and other features: Basic and Auxiliary tables charge for data scanned by queries. Search jobs, exports, and other enabled features can add costs too.

Open Cost Management → Cost analysis for the subscription. Find the workspace and examine its billing meters: the individual types of usage Azure charged for. If Microsoft Sentinel is enabled, check its charges too, because some workspace costs may appear under Sentinel meters.

If ingestion is the large line, shortening retention alone will not solve it. If you are still unsure which service caused the increase, start with the Azure bill investigation checklist.

02 / Find the source

Which tables are collecting the most data?

In the Azure portal, open the affected Log Analytics workspace → Usage and estimated costs. Review the data volume and the breakdown by data type. Start here even if you are comfortable writing queries.

For a simple ranked list, open Logs, switch to KQL mode, and run the query below at workspace scope. KQL is the language Azure uses to search and summarise log data.

Usage
| where TimeGenerated > ago(8d)
| where StartTime >= startofday(ago(7d))
    and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableGB = sum(Quantity) / 1000.0 by DataType
| order by BillableGB desc

This shows billable ingestion by table over the last seven complete UTC days. Quantity in the Usage table is measured in MB, so dividing by 1,000 gives GB. DataType is the table name.

This ranks data volume, not the exact cost. Tables can have different prices, and the query does not include retention or other charges. Usage reporting can also lag behind collection. Match the result to the billing meters before putting a money figure on it.

Look at the top few rows. If ContainerLogV2 is large, investigate container output. If AppTraces is large, examine application logging. If AzureDiagnostics stands out, check the resources and diagnostic categories feeding it.

Compare the busy period with an earlier one. Then inspect a small sample from the largest table. You are looking for a repeated message, a particular resource, or a change that explains the growth.

03 / Look at the messages

Why can a small app produce so many logs?

Log volume depends on what happens inside the app as well as how many people use it. One customer action might create a request record, several dependency records, and dozens of trace messages.

These are useful places to look:

• Debug logging left on. A developer increases the detail to investigate a problem. The problem is fixed, but the setting stays.
• Repeated failures. A background job retries every few seconds and records the same error each time. Fixing the job reduces both the failure and the log traffic.
• Large messages. Logging full request bodies or long database results makes each record bigger, even when the number of requests stays flat.
• Broad collection settings. Diagnostic settings or data collection rules collect categories nobody has reviewed. Routine container output can be especially noisy.
• Duplicate collection. Overlapping agents, rules, or logging integrations send the same information more than once. Confirm the duplicate path before removing it.

Workspace-based Application Insights also stores its data in a linked Log Analytics workspace. Include its logging and sampling configuration in the review, even if your team usually opens Application Insights through a separate portal screen.

04 / Change what you collect

Reduce unnecessary logs before they reach the workspace

Start with a specific source you understand. For example, reduce an overly detailed logging category, stop recording a large payload you never use, or remove a confirmed duplicate collection path.

Keep the information needed to investigate failures and meet security or audit requirements. A routine message may look unimportant until you discover that an alert depends on it.

For Application Insights, review sampling: keeping a portion of the application's telemetry rather than every trace. The right settings depend on the SDK or OpenTelemetry distribution and version. Do not assume that changing trace sampling also changes every application log. Test a failed request and check that the diagnostic details your team needs still arrive.

If source changes are difficult, supported data collection transformations can filter records or fields before they are stored. Check the collection path and table support first. Transformations can have processing charges, so estimate the total before applying a broad filter.

Make one change, record when it happened, and watch both the data volume and the monitoring it supports. That makes it much easier to tell whether the change helped.

05 / Review stored data

Do all these logs need the same retention period?

A payment audit record and a routine development trace serve different purposes. They may need different retention settings too.

Check retention at both workspace and table level. Table settings can override the workspace default. Also check the included retention period for the data you are reviewing; Application Insights and Sentinel can have different allowances.

For each large table, find out who uses it, how far back they normally search, and whether a policy requires longer storage. Agree on those requirements before reducing retention. For data kept mainly for occasional investigations, compare long-term retention and the cost of retrieving it later.

Reducing paid retention can lower storage costs. It does not refund the cost of bringing the data in. If incoming volume remains high, address collection as well.

06 / Check the pricing choice

Would a different table plan cost less?

Azure offers Analytics, Basic, and Auxiliary table plans. You can use different plans for eligible tables within the same workspace.

• Analytics suits data used regularly for monitoring and investigations. Interactive queries do not add a charge based on data scanned.
• Basic has a lower ingestion rate, with charges for data scanned by queries. Check its supported alert and monitoring features.
• Auxiliary is aimed at data accessed less often. It has a lower ingestion rate, but processing, query costs, and feature limits still matter.

A table read once a month needs a different comparison from one powering a dashboard that refreshes all day. Check table eligibility, query frequency, alerts, and regional availability against Microsoft's current plan comparison.

For steady Analytics ingestion, also review commitment tiers. These start at 100 GB per day and have a 31-day commitment period. You pay for the committed amount even on quieter days; usage above it is charged as overage. Basic and Auxiliary ingestion are not covered by this discount.

Review commitments after removing unnecessary collection. Otherwise, you could commit to a daily volume that your app no longer needs.

07 / Avoid monitoring gaps

What happens when you set a daily cap?

A daily cap can limit unexpected ingestion by stopping collection when the workspace reaches a threshold. That sounds convenient when the bill is high, but it has a practical consequence: logs you need during an incident may stop arriving.

The workspace cap applies to billable ingestion into Analytics and Basic tables. Auxiliary tables are not covered. Collection can also go beyond the threshold before it stops, and Azure still bills that excess data.

Use a cap as a backup measure. Set an alert before usage approaches it, give someone responsibility for responding, and understand the workspace's reset time. Other costs, including retention, are not stopped by this cap.

If you hit the cap regularly, return to the sources producing the logs. Daily gaps in monitoring will make the next production problem harder to explain.