Control Log Analytics ingestion and retention costs

Log Analytics is one of the few security-and-operations line items that is a genuine spend decision rather than a near-free configuration fix. The bill scales with the gigabytes ingested and the days retained, so a single untuned diagnostic setting or a chatty new workload can move it materially month over month. That makes it a forecasting problem, not a one-off remediation: the question finance should ask is not 'is this switched on?' but 'do we know what we are collecting, is it the data we actually use, and is the trend explained?'

The trap is to treat the bill as pure waste and squeeze it blindly. The data in that workspace is what an engineer queries at two in the morning to find why a service is down, so cutting it is not free: cut the wrong table and you lengthen the next outage. The right framing separates the two kinds of spend. Ingestion that nobody queries, duplicate data, verbose categories, full-rate tables that are only read during incidents, is waste to remove. Ingestion that shortens mean-time-to-detect and mean-time-to-resolve is insurance to keep. Finance owns making that distinction visible rather than approving or denying a number.

The levers are well bounded and most reduce the bill without reducing visibility: limit collection to the categories you query, move incident-only tables to the cheaper Basic plan, retire data to long-term retention rather than paying interactive rates to hold it, and, where volume is large and steady, switch to a commitment tier for a documented discount. The daily cap sits underneath all of this as a budget backstop, not a savings tool: it protects the forecast from a spike, at the cost of going blind once it trips.

Priya is the finance partner supporting the platform team. The observability line has risen for three consecutive months and now sits among the top five items in the subscription. The instinct is not to demand a flat cut; it is to ask what changed and whether the new volume is data the team actually uses. The Usage breakdown answers the first question: a single container-logs table has grown past four hundred gigabytes a month, and most of it is verbose stdout that is only ever read during an incident. That is not insurance, it is noise paying the full Analytics ingestion rate.

Priya reframes the line for the cost review. The container-logs table is a waste-removal opportunity: move it to the Basic plan, which carries a much lower ingestion charge in exchange for limited query features, and the spend drops without losing the data when an incident needs it. The performance counters are a tuning opportunity: polling every fifteen seconds where every minute would do. The application traces are a sampling opportunity. None of these is 'monitor less'; each is 'pay the right rate for what this data is worth.' The finance pack reads: 'The increase is explained, it is one chatty table plus untuned defaults, the fix lowers the run rate without reducing what the on-call can see, and an anomaly alert plus a daily cap will stop the next surprise before it reaches the bill.'

The cost model here is different from most security work: it is a recurring, volume-driven spend that you forecast and steer, not a one-off fix you complete. That makes the finance role ongoing. Each gigabyte of ingestion and each day of retention is a known unit cost, so a trend that rises without an explanation is the signal to investigate, and Azure's own anomaly recommendation, 'Data ingestion anomaly was detected,' is designed to surface exactly that before the month closes.

The asymmetry to watch is between the two ways of getting it wrong. Over-spend is bounded and visible: you can see the gigabytes and price them. Under-spend is hidden and shows up only in a worse incident, when the data an engineer needed to find the cause was never collected and the outage runs longer. So the metric that belongs on the review is not the raw bill but the bill split into data the team queries versus data it does not, tracked over time. Finance owns keeping that split visible so the conversation is 'is this the right data at the right rate?' rather than 'the number is too big, cut it.'

Observability is the system that tells you a service is failing before your customers do, and how fast you can find the cause once it is. Log Analytics is where that data lives, and its bill grows with how much you collect and keep. Left untuned, two things go wrong at once: the cost drifts upward without anyone deciding it should, and the signal gets buried in noise nobody reads.

The leadership question is not 'how do we cut the monitoring bill?' It is 'do we know what we are collecting, is it the data that shortens an outage, and is a runaway source structurally prevented from blowing the budget?' The defensible end state is a workspace where ingestion is deliberate, retention matches usefulness, an anomaly alert flags a sudden jump, and a daily cap stops the worst case, with the team treating the cap as a last resort because tripping it means flying blind.

This is a genuine trade, not a free win. Spend too little and you lengthen every incident because the data you need was never collected. Spend without discipline and you pay for noise. The job is to land in the middle on purpose: full visibility into the state of the estate, at a cost the business chose.

After three months of a rising cloud bill driven by observability, the CFO asked the obvious question at the review: are we paying more to see more, or just paying more? The honest answer at the time was that nobody knew, because the workspace had been left on its defaults and no one had looked at what was actually being collected.

The platform team's response was to stop treating the bill as a single number to squeeze and start treating ingestion as something to govern. They pulled the per-table breakdown, found that one container-logs table accounted for most of the growth, moved it to the cheaper Basic plan because it was only read during incidents, tuned the verbose performance counters, and turned on an anomaly alert plus a daily cap as a backstop. The run rate came down and, just as importantly, the data an engineer needs to resolve an outage was untouched. The next time the CFO asked, the answer had changed from 'the bill went up and we are not sure why' to 'here is exactly what we collect, here is what we removed as noise, here is what we kept because it shortens an outage, and a runaway source can no longer blow the budget without alerting us first.' That shift, from a bill that happened to the company to one the company chose, is the confidence signal this capability delivers.

Observability is the early-warning system for the whole estate, so its health is an operational risk, not just a cost line. The failure that hurts is not a slightly high bill; it is discovering during an outage that the data needed to find the cause was capped, sampled away or never collected, turning a short incident into a long one. Mean-time-to-detect and mean-time-to-resolve are the numbers the business actually feels, and they depend on having the right data at hand.

The cost of getting this wrong runs in both directions, which is what makes it a leadership trade rather than a delegated cut. Too little discipline and the bill drifts upward for noise nobody reads; too aggressive a cut and you lengthen the next outage. The defensible position is a workspace that is tuned on purpose, with an anomaly alert and a daily cap as safety nets, so spend is forecastable and the ability to see what the estate is doing is never sacrificed to save a few gigabytes.