One misconfigured diagnostic setting can quietly become your biggest Azure expense.
Cloud costs have a way of hiding in plain sight. What started as a routine FinOps review turned into a significant discovery: a full third of the entire Azure cloud bill was being driven by a single service, the Azure Log Analytics workspace.
The root cause was not a rogue application or runaway infrastructure. It was a default setting that nobody had questioned. This post walks through what we found, what we changed, and what it means for teams running hub-and-spoke architectures in Azure.
The Problem: Paying for Logs You Don’t Need
When we began drilling into the Log Analytics costs, two contributing factors stood out.
The first was architectural. We ran a hub-and-spoke network model, which meant traffic traversed at least two Azure firewalls before reaching its destination. Each hop generated logs, and those logs added up to a substantial ingestion volume measured in gigabytes.
The second factor was a configuration default. The diagnostic settings across the environment were sending all logs into a general Azure diagnostic table, a catch-all that includes a large amount of metadata that is rarely useful for day-to-day operations or troubleshooting.
Neither issue was obvious on its own. Together, they were responsible for a significant and growing cost.
The Fix: Route Logs to Resource-Specific Tables
The solution was straightforward once we understood the problem. We switched from the default diagnostic configuration to resource-specific based logs.
This setting routes logs directly into dedicated, purpose-built tables rather than dumping everything into the general diagnostic pool. This meant firewall logs went into their own specific table, stripped of the unnecessary metadata that had been inflating ingestion volumes.
The change had an immediate secondary benefit: Kusto queries became significantly easier to write and read. With the general diagnostic table, extracting useful information required manual parsing of raw message fields. With resource-specific tables, the data was already structured the way you needed it.
The Result
By optimizing firewall and application gateway logs alone, we saved approximately 20,000 Swedish kronor per month. The only adjustment required was rewriting existing dashboards to accommodate the new table structure. A manageable one-time effort compared to the ongoing cost savings.
What This Means for Your Azure Environment
If your team is running a hub-and-spoke network model and has not reviewed your diagnostic settings, there is a good chance you are paying for the same problem.
A few things worth checking:
- Are your diagnostic settings using the general Azure Diagnostic table?
This is the default and almost always the wrong choice for production environments. - How many network hops are your logs traversing?
In hub-and-spoke architectures, each firewall is a log multiplier. - Do you have visibility into Log Analytics ingestion costs by table?
Without this, it is easy to miss where the volume is actually coming from.
Resource-specific logs are available for most Azure services and are the recommended approach for any environment where cost visibility and query performance matter.
Summary
A default diagnostic setting was costing roughly 20,000 SEK every month. Switching to resource-specific logs reduced log volume, improved query usability, and delivered immediate savings. The fix required no infrastructure changes and no additional tooling.
FinOps is often described as a cultural or organizational discipline, and it is. But it starts with visibility, and visibility starts with knowing what you are actually sending to your logging infrastructure, and why.
