Cloud Cost Optimisation: Where Avoidable Azure Spend Hides

To reduce Azure costs, or cloud costs on any platform, start with five places: non-production environments running around the clock, steady workloads on on-demand pricing, untiered storage, oversized instances, and resources nobody has tagged to an owner. Most cloud estates we review carry 20 to 30 per cent avoidable spend, and it sits in those places every time.

The figure holds across industries and cloud vendors because the causes are structural: cloud makes spending easy and attributing spend hard, and the gap between the two compounds monthly.

Shutting down non-production environments out of hours

Non-production is the classic. Development and test environments are sized like production and run around the clock, for teams that work business hours in one or two time zones. Scheduling non-production to switch off nights and weekends removes roughly two thirds of its compute hours. The usual objection, "someone might need it at 2am", is answered with a self-service start button.

The larger version of this problem is the abandoned environment: spun up for a project and left running after the project ended. Estates without expiry policies accumulate these, and each one costs money while doing nothing.

Azure Reservations and savings plans for steady workloads

Reservations and savings plans exist because vendors will discount heavily, often 40 to 60 per cent, in exchange for commitment. Estates that run steady baseline workloads at on-demand prices are giving that discount away. Usually nobody owns the decision, because commitment feels like risk. A quarterly review of steady-state usage against commitment coverage takes about an hour and pays back many times over.

Storage tiering and lifecycle policies

Storage keeps growing, because deleting requires a decision and keeping requires nothing. The result is hot-tier storage full of cold data: logs from 2022, backups of decommissioned systems, snapshots taken before changes nobody remembers. Lifecycle policies that move data through cool and archive tiers are standard and often unconfigured. On large estates, storage tiering alone has paid for the entire cost review.

Right-sizing virtual machines and disks

Instances get sized generously at migration time, because nobody wants the go-live incident, and are then never revisited. Utilisation data makes right-sizing a mechanical exercise: sustained single-digit CPU on a large instance is a resize candidate. The same applies to premium disk tiers, redundant IP addresses, and load balancers in front of things that no longer exist.

Cost allocation tagging and monthly cost reviews

Underneath all of these is attribution. When resources are not tagged to workloads and owners, the invoice is one number that belongs to everyone, and no line of it is anyone's problem. Tagging enforced by policy at the platform level, for example as part of a landing zone built as code, turns a bill into a set of accountable numbers. Cost work belongs with engineering for the same reason: every lever above is an architectural or platform decision.

The monthly review that keeps an estate lean reports dollars per workload against last month, with a named owner per line. Estates reviewed as a single total drift back to 20 to 30 per cent avoidable spend within a couple of years.

Cost management is part of the operations work in our Azure and cloud engineering practice, alongside the monitoring and platform work it depends on.

Frequently asked questions

Where should we start to reduce Azure costs?

Start with non-production schedules and reservation coverage, since neither needs changes to the applications themselves. Storage tiering and right-sizing follow.

Are Azure Reservations worth the commitment?

For workloads that run steadily, yes: the discount is often 40 to 60 per cent. Review coverage each quarter so commitments keep pace with real usage.

Why does cloud spend creep back after a cost review?

Without enforced tagging and a monthly review by workload with named owners, nothing stops new waste accumulating.

Who should own cloud cost optimisation?

Engineering, with finance receiving the per-workload view. Each of the main levers is an architectural or platform decision.

Harry Le is a cloud engineer at Coder Trove.