Cost Management & Azure Optimisation

Where does Azure waste actually accumulate?

In predictable places, and rarely the ones people look at first. Compute is the obvious category: virtual machines sized for a workload that was projected rather than measured, and machines stopped from inside the operating system rather than deallocated, which continues to bill because the resource is still reserved.

The less visible categories are usually the fastest growing. Log and telemetry ingestion is the most common surprise, because monitoring and security tooling bills on data volume, so a verbose diagnostic setting enabled during troubleshooting and never reverted can quietly become a significant line.

Storage tiering is another: data written to a hot tier and never moved to cool or archive, alongside backup retention policies nobody has revisited. Data transfer charges catch out architectures that move traffic between regions more than the design assumed. And over-provisioned platform tiers persist because nobody owns the question of whether they are still needed.

Reserved instances, savings plans or autoscale: which applies when?

They solve different problems and are frequently combined. A reservation is a one or three year commitment to a specific resource type in a specific region, and it delivers the deepest discount available. It suits workloads that are stable and predictable: the domain controllers, the database server, the always-on production tier.

A savings plan is a commitment to spend a fixed hourly amount on compute, applied automatically across eligible services and regions. It discounts less deeply but tolerates change, which makes it the right instrument where the workload is durable but the specific resources are not.

Autoscale is a different category entirely: rather than discounting what you consume, it reduces what you consume by adding and removing capacity in response to demand. It applies to variable workloads with a genuine peak and trough, and it is the only one of the three that also improves resilience.

The usual mature pattern is layered (reservations for the stable core, a savings plan covering the predictable band above it, and autoscale or scheduled shutdown handling the variable remainder) with the commitment deliberately set below your measured minimum consumption, so you are never paying for a commitment you cannot use.

What is licence right-sizing, and where does shelfware come from?

Shelfware accumulates in four ways, all mundane. Licences assigned to leavers and never reclaimed, because offboarding removed the account's access but nobody released the subscription. Licences bought for a headcount forecast that did not materialise, then renewed annually because renewal is easier than reassessment.

Everyone placed on a premium tier when only a subset need its capabilities. And duplicated function, where a bundled entitlement you already own overlaps a separately purchased third-party tool: a separate mobile device management product alongside Intune is the classic pairing.

Right-sizing means matching entitlement to actual need and actual use, which requires usage data rather than assumptions. Two cautions are worth stating plainly. First, downgrading a tier can silently remove security capability, so the analysis has to consider what a licence is protecting as well as what it enables.

Second, agreements have terms, and mid-term seat reductions are often not permitted, so the practical window for change is at renewal, which means the analysis needs to be done before the renewal, not after it.

What's the difference between cost cutting and cost control?

Cost cutting is an event; cost control is a property of how the estate is run. Cutting produces a satisfying one-off reduction (resources deleted, tiers downgraded, licences reclaimed) and it works, once.

What follows is the rebound, because the conditions that produced the waste are unchanged: the same provisioning behaviour, the same absence of ownership, the same lack of any signal when spend moves. Most organisations that run a cost exercise without changing anything structural find themselves close to the original figure inside a year.

Cost control means the estate produces a signal before the invoice does. Budgets and anomaly alerts at a level granular enough to identify a cause rather than just a total. Tagging enforced at creation so every resource has an owner. A default expectation that non-production shuts down outside working hours unless someone opts out.

Commitments reviewed against actual utilisation on a cycle rather than at renewal panic. The distinction matters commercially because cutting is measured in what you saved this quarter, while control is measured in the gap between what you now spend and what you would have spent: less visible, considerably larger over time.

How do you attribute cloud spend to teams and projects?

Through the structure you create the resources in, and through tags, in that order, because structure is enforced and tags are not. Subscriptions, resource groups and management groups form a hierarchy that maps onto business units, environments and projects, and spend attributed by that hierarchy is reliable because a resource cannot exist outside it.

Tags add the dimensions structure cannot express (cost centre, owner, application, environment) but they are not inherited by default and are frequently omitted at creation. The fix is policy that requires or applies tags at creation, so compliance is a condition of provisioning rather than a monthly chase.

Attribution then supports two different disciplines. Showback reports each team what their consumption costs without moving money, which is usually enough: visibility alone changes behaviour, because engineers who can see the running cost of a decision make different decisions.

Chargeback actually recovers the cost into departmental budgets, which drives sharper accountability but requires the attribution to be defensible. Both stumble on shared costs (networking, monitoring, security tooling) and the workable approach is to agree an allocation method openly and stick to it.

What does FinOps discipline look like for a mid-sized estate?

It looks considerably lighter than the enterprise literature suggests, because most of that literature assumes a dedicated team you do not have. The core idea transfers regardless of scale: cloud spend is a variable operating cost driven by engineering decisions, so it needs the people making those decisions to see the consequences.

In a mid-sized organisation that generally means someone owning the number, a monthly review that finance and IT attend together, and cost being a routine consideration at design time rather than a periodic audit.

Why do cloud bills grow when nothing has obviously changed?

Because several cost drivers grow on their own without any deployment. Storage is cumulative (data written and never lifecycled, snapshots retained indefinitely, backup chains lengthening under a retention policy nobody revisits) so a storage line climbs steadily whether or not anyone touches the environment. Log and telemetry ingestion behaves the same way, and scales with the number of systems being monitored. Consumption services bill on activity, so a busier month costs more without any configuration change.

Then there are changes made outside your environment. Microsoft periodically adjusts pricing and, for UK organisations, list prices are influenced by currency alignment, so a bill can rise with no change in consumption at all. Licensing terms and product packaging change too, sometimes moving a capability from a bundle into a separately charged item. Without attribution and trend reporting, an increase presents as one aggregate number and the conversation becomes a hunt rather than an answer.