Switch low-value tables to the Basic logs plan

Log ingestion is one of the few Azure costs that grows on its own. Add a service, turn up a diagnostic setting, scale out a cluster, and the workspace bill rises without anyone deciding it should. The Basic plan lets you keep the verbose tables you need for incident response and audit without paying the analytics ingestion rate for data that never drives a query, so the saving is recurring and it compounds as volume grows.

Frame this as funding visibility, not cutting it. The reason to move noisy tables to Basic is so the budget covers analytics-grade retention and alerting on the signals that actually shorten your mean time to detect and resolve. Flying blind is the expensive outcome here: a longer incident, a missed SLA, an audit you cannot answer. The plan split is how you afford to see clearly where it counts while not overpaying to store data you only read after the fact.

The arithmetic is favourable and bounded. The saving is the gap between the Analytics and Basic ingestion rates on the eligible tables, which Advisor has already identified by volume. The cost is engineering time plus a modest per-gigabyte query charge on the rare occasions you search a Basic table during an incident. Nothing is deleted, retention is unchanged, and the move is reversible, so the downside if you are wrong about a table is simply switching it back.

Priya is the finance partner watching the Log Analytics line climb quarter on quarter while the rest of the observability budget stays flat. The instinct is not to demand the team log less, which trades blind spots for pennies; it is to ask whether the growth is buying anything. Advisor has already done the hard part by naming the eligible tables ingesting enough volume to justify the Basic plan, so the question becomes narrow: which of those tables does anyone actually analyse, and which are we paying the premium rate to store and never read?

Priya asks the team to map each high-volume table to what depends on it. The container log stream and the verbose application traces feed no alert and appear in no dashboard; they are read only during an incident, which is exactly the Basic plan's job. The security and performance tables drive real-time detection and stay on Analytics untouched. The finance pack reads: 'The recurring saving is the rate gap on three verbose tables Advisor flagged, nothing is deleted, retention is unchanged, and the only new cost is a small per-query charge on the rare occasions we search those tables during an incident. This frees budget to extend analytics retention on the signals we actually alert on, so we see problems faster, not slower.'

This is one of the cleaner cost levers in Azure because the saving is recurring and nothing is given up. The premium you pay on a verbose table left on Analytics repeats every month and scales with volume, so the longer it goes unaddressed the more it costs, while the fix preserves every byte and the full retention period. Advisor has already quantified the opportunity by flagging the eligible tables ingesting enough volume to matter.

The cost the move introduces is small and predictable: engineering time to make the switch, and a per-gigabyte charge only on the data scanned when someone actually queries a Basic table, which for genuinely search-only data is rare. The finance role is to make sure the saving is redirected into visibility, extending analytics retention or alert coverage on the signals that shorten incidents, rather than simply banked, so the optimisation funds faster detection instead of quietly weakening it.

Observability spend has a way of climbing with no decision behind it, and most of the growth is verbose log data that sits unread until an incident or an audit forces someone to go looking. Paying the top rate to ingest that data does not make you safer or faster; it just makes the bill larger and quietly competes for the budget that funds real-time detection.

The leadership question is not 'how do we spend less on logging?' It is 'are we paying premium rates for data we never analyse, and is that crowding out the visibility we need to find problems fast?' The defensible end state is that high-value signals stay on the analytics plan where alerting and interactive analysis live, and the verbose, search-only data sits on the discounted plan, with that split reviewed rather than left to drift.

This is a cost-efficiency decision with a visibility upside, not a corner being cut. Done well, it lowers a recurring bill and frees budget for the monitoring that shortens incidents. Done badly, it is left undone, and the workspace keeps charging analytics rates for data nobody reads while detection elsewhere goes underfunded.

After two quarters of a quietly doubling observability bill, the CFO asked the obvious question at the review: what are we getting for it? The honest answer was uncomfortable, because most of the growth was verbose log data that had never been queried outside an incident, sitting on the premium plan because nobody had decided it should not.

The team's response was to stop treating the log bill as a fixed cost of doing business and start treating the table-plan split as a deliberate choice. They ranked every table by ingestion volume, confirmed which ones drove alerts and dashboards, and moved the verbose, search-only tables that Advisor had flagged to the Basic plan, keeping every byte and the full retention period. The recurring saving was redirected into longer analytics retention and tighter alerting on the signals that actually shorten incidents. The next time the CFO asked what the spend bought, the answer had changed from 'storage we rarely read' to 'real-time visibility on what matters, with the noisy data kept cheaply and still searchable.' That shift, from a bill that grows by accident to a split that is reviewed on purpose, is the confidence signal this capability delivers.

Observability bills climb by accretion: every new service and every turned-up diagnostic setting adds volume, and almost none of it is a deliberate spending decision. The risk of ignoring it is twofold: a recurring overcharge for data nobody reads, and the temptation, when the bill is finally noticed, to cut logging across the board and create blind spots that lengthen the next incident.

Acting on the table-plan split avoids both. It removes the overcharge on the verbose data while keeping it fully searchable, and it protects, even extends, the analytics-grade visibility on the signals that actually shorten incidents. The cost of getting it right is engineering time and a reversible change; the cost of leaving it is a bill that grows on its own and visibility that gets cut for the wrong reason.