Move high-transaction storage to premium tier

This is one of the rare security-and-cost reviews where the recommended action is expected to reduce the bill, not protect against a future loss. Advisor only raises it on accounts whose cost is dominated by transactions, and on those accounts premium block blob storage prices the transactions low enough that the saving on operations typically exceeds the extra you pay per gigabyte. The headline for finance is straightforward: this is a candidate saving on the current run rate, not a spend request.

The saving is account-specific, so the right response is to model it rather than assume it. Pull the account's monthly transaction count and stored capacity, price the same workload at standard rates and at premium block blob rates, and compare the totals. The win is real where transactions dominate; it shrinks or reverses if the account is actually capacity-heavy and was flagged on a transient spike. There is a one-off migration cost too, because you cannot convert an account in place: you stand up a new premium account and copy the data across, which is mostly engineering time plus a small amount of egress-free, intra-region copy.

Treat each flagged account as a small business case: monthly saving on the run rate, one-off migration effort, and a payback period. Where transactions clearly dominate, the payback is short and the saving recurs every month thereafter, which is exactly the kind of low-risk, self-funding optimisation that belongs near the top of the list.

Priya is the finance partner for the platform group. The Advisor cost tab shows the high transactions/TB recommendation against the ingestion account, and the instinct is not to wave it through or dismiss it, but to size it. She asks the team for two numbers from the account's own telemetry: monthly transaction count and average stored terabytes. The account runs tens of millions of transactions an hour against roughly three terabytes, so on the standard general-purpose v2 bill the transaction charges, not the capacity, are doing almost all the damage.

From there it is a like-for-like price comparison. Priced at premium block blob rates the same volume of operations costs a fraction of what it does at standard rates, while the storage line rises modestly because three terabytes now sits on the higher per-gigabyte tier. The net is a meaningful monthly reduction on this account's run rate. Against that, Priya books a one-off migration cost: engineering time to stand up the new account and copy the data, with the intra-region copy itself incurring no egress charge. The finance pack reads as a one-line business case: 'Modelled monthly saving on the ingestion account, one-off migration of a few engineer-days, payback inside the first month or two, recurring saving thereafter, no security or availability trade-off to weigh.'

The economics here are unusually clean for a cost optimisation. The saving is on the current run rate, so it is money already being spent that you can stop spending, and because the triggering ratio is structural the saving recurs every month rather than being a one-off. Against that sits a single, bounded, one-off migration cost: engineering time to stand up the new account and copy the data, with the intra-region copy incurring no egress charge. There is no recurring downside and no risk trade-off, which is rare.

The discipline finance brings is to put a number and a payback on each flagged account rather than acting on the flag count. Model the standard-versus-premium bill from the account's own Transactions and UsedCapacity metrics, subtract to get the monthly saving, divide the one-off migration cost by that saving to get the payback, and rank candidates by annualised saving. Accounts where transactions clearly dominate pay back fast and should move first; borderline accounts flagged on a spike can be parked or watched. The metric that belongs on the cost review is annualised saving captured from tier moves, not the raw count of Advisor flags.

Azure prices storage two ways: by how much you keep and by how hard you use it. Most accounts are on the model that favours the first. A handful are heavy on the second, running enormous numbers of operations against a small amount of data, and for those the cheaper model is the premium tier, where transactions cost far less. Advisor flags these accounts automatically.

The leadership question is not a risk question; it is a value question: are the busiest storage accounts on the pricing model that costs the least to run? Acting on this recommendation can lower the monthly run rate on those accounts while also making them faster, which is an unusual combination of cheaper and better.

The decision is bounded and low-risk. Each candidate is a small, self-contained migration with a modelled saving and a payback period, so the call is simply whether the saving clears the bar to justify the one-off engineering effort. There is no security trade-off to weigh, only return on a small amount of work.

At a cost review the CFO asked why the storage line on one product kept climbing while the data it held barely grew. The honest answer was that the bill was being driven by usage, not size: the ingestion account ran an enormous number of small operations, and on the standard tier each one carried a charge. Nobody had been wrong; the account had simply outgrown the pricing model it was created on.

The team's response was not to throttle the workload or argue about it, but to act on the Advisor recommendation they had been sitting on. They modelled the same workload on premium block blob storage, where transactions cost a fraction as much, confirmed the monthly saving cleared the cost of a one-off migration within weeks, and moved the data. The storage line came down and latency improved at the same time. The next time the CFO asked, the answer had changed from 'usage is just expensive' to 'the busy accounts are now on the pricing model that costs the least to run, and we check new ones against the same Advisor signal.' That shift, from absorbing a usage-driven bill to matching each account to its cheapest tier, is the value this recommendation delivers.

Most cost-versus-risk decisions involve a trade: spend to reduce a risk, or accept a risk to save money. This one does not. Acting on the recommendation lowers the run rate on the busiest accounts and makes them faster, with no security or availability cost to weigh. The only question is whether the modelled saving on a given account clears the bar to justify a small, one-off migration, which it usually does where transactions dominate.

The cost of leaving it is a recurring overspend that compounds quietly, plus a workload running slower than it needs to. Because there is no risk attached, it is easy to keep deferring, so the leadership job is simply to ask for the modelled annualised saving across the flagged accounts and approve the ones that clear the threshold. It is the rare review item where the right answer is almost always yes, and the only work is confirming the number.