From $17K to ~$1K: How We Optimized Azure Log Analytics Costs

 

Introduction

Cloud costs do not always rise because of growth. Sometimes they rise because of configuration. That was exactly the case in our environment.

We noticed that Log Analytics costs had climbed to roughly $17,000 per month. At first, nothing obvious stood out. There were no major application changes, no large-scale onboarding of new workloads, and no sudden increase in operational activity. But once we reviewed the ingestion data closely, the real issue became clear: a logging configuration was generating far more data than was actually needed.

This post explains what we found, what we changed, and how the environment moved from a high-cost logging model to a much more efficient one while still keeping the right operational and security visibility.

The Problem: High Log Analytics Ingestion

The first step was to understand which tables were driving ingestion.

Using the Usage table in Log Analytics, we reviewed billable ingestion over time and by data type. The results showed that AzureDiagnostics was by far the largest contributor. Daily ingestion was consistently landing around 400 to 450 GB per day, far above what we expected.

That level of ingestion was especially important because the workspace was configured with a 100 GB/day commitment tier. With actual usage running significantly above that level before the change, costs remained very high.

Root Cause: Audit Category Group Enabled

After reviewing the diagnostic settings, we identified the main driver.

The SQL diagnostic configuration for the Defender for Cloud Log Analytics workspace had the Audit category group enabled. That setting collects a broad set of SQL audit events and sends them into Log Analytics. In practice, that can result in extremely high-volume ingestion, especially when query-level or data-access-related audit events are included.

At the same time, SQL Security Audit Events were already being captured in the existing prod-bidatalog-la Log Analytics workspace. In other words, we were collecting more audit data than we needed in this particular workspace, and it was contributing directly to cost.

This was not a workload problem. It was a configuration-driven cost issue.

The Change We Made

To reduce unnecessary ingestion while preserving useful visibility, we updated the SQL diagnostic settings.

Previous state

• Audit category group enabled

New state

• Audit category group disabled

• DevOps Operations Audit Logs enabled only

This change kept operational and platform-level visibility, such as configuration changes and DevOps-related actions, while eliminating the high-volume SQL audit flow that had been filling the AzureDiagnostics table.

Importantly, this did not impact database availability, application functionality, or core operational monitoring.

What Happened After the Change

The post-change data told a very clear story.

Starting immediately after the logging change, daily ingestion dropped sharply. AzureDiagnostics no longer dominated the workspace the way it had before. Instead of running near 400–450 GB/day, ingestion came down to a much smaller range, approximately 15–40 GB/day based on the observed trend.

That drop was immediate and sustained, which confirmed that the audit category group had been the primary source of excessive ingestion.

This was one of the most important outcomes of the exercise: we had measurable proof that the fix addressed the real cause.

The Pricing Model: Why We Also Needed to Change the Tier

Even though ingestion dropped, the workspace was still configured with a 100 GB/day commitment tier.

That meant we were still paying for a capacity reservation that no longer matched actual usage. Once the logging volume had stabilized, the next logical step was to align the pricing model with the new baseline.

The proposed move was to switch from the 100 GB/day commitment tier to Pay-As-You-Go pricing.

Why this made sense:

• Current ingestion was now well below 100 GB/day

• Pay-As-You-Go would charge based on actual consumption

• The change was billing-related only and would not affect log collection or security monitoring

• If ingestion increased in the future, a smaller commitment tier could always be reintroduced

Cost Impact

Based on the observed reduction, the expected monthly cost fell dramatically.

• Before optimization: approximately $17,000/month

• After optimization: approximately $700 to $1,000/month in the lower observed range, or roughly $1,800/month using a conservative 40 GB/day estimate at $1.50/GB

That represents an estimated cost reduction of approximately 90% to 96%, depending on the final stabilized ingestion rate and pricing model used.

This was not just a logging cleanup. It was a meaningful FinOps win.

Queries Used During the Analysis

Total billable ingestion for the last 24 hours

Usage
| where TimeGenerated >= ago(24h)
| where IsBillable == true
| summarize TotalIngestedGB = sum(Quantity) / 1000

Billable ingestion by type for the last 30 days

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

Daily ingestion trend

Usage
| where TimeGenerated >= ago(30d)
| where IsBillable == true
| summarize DailyGB = sum(Quantity) / 1000 by bin(TimeGenerated, 1d)
| sort by TimeGenerated asc

Monthly projection using Pay-As-You-Go pricing

let CostPerGB = 1.50;
Usage
| where TimeGenerated >= ago(7d)
| where IsBillable == true
| summarize AvgGBPerDay = (sum(Quantity) / 1000) / 7
| extend Projected30DayCostUSD = AvgGBPerDay * 30 * CostPerGB

Lessons Learned

1. More logging is not always better

Collecting everything may feel safe, but it can create noise, increase cost, and make troubleshooting harder.

2. Diagnostic category groups should be reviewed carefully

A single category group can create a large downstream billing impact if it enables broad, high-volume event collection.

3. Separate operational logs from detailed audit logs

Not every workspace needs the same level of logging. Security audit data and operational telemetry can be routed differently depending on purpose.

4. Pricing tiers should be revisited after optimization

Reducing ingestion without adjusting the pricing model leaves savings on the table.

5. Cost optimization works best when it is measurable

The combination of usage analysis, root-cause identification, targeted configuration changes, and post-change validation is what makes the result defensible.

Final Thoughts

This effort was a good reminder that cloud cost optimization often starts with visibility and ends with precision.

We did not remove monitoring. We refined it.

We did not reduce security posture. We reduced duplication and unnecessary ingestion.

And in the process, we turned a costly logging pattern into a much more intentional and sustainable model.

Sometimes the biggest savings in the cloud come from understanding exactly what one checkbox is doing.

Jay