Skip to content

Azure FinOps · cloud financial management · GCC · EU · US

Your Azure bill is a number nobody owns.

Every quarter it grows, somebody runs an optimisation sprint, and two quarters later it is back where it started. That is not a cost problem — it is an ownership problem. Nobody can say what a customer, a product or a transaction costs to run, so nobody can be accountable for it moving.

Azure · Cost Management · Azure Virtual Desktop · EA / MCA / CSP · FinOps Foundation framework

Scope

What we put in place

FinOps is three capabilities, in order. Attribution first, because you cannot govern what you cannot attribute. Optimisation last, because it is the part that unwinds if the first two are missing.

Cost attribution that survives an audit

A tagging taxonomy applied through Azure Policy so it is enforced at deployment and not chased afterwards, with untagged spend visible as its own line. Showback by team, product and customer — and chargeback where finance is ready for it. This is the foundation; everything below is guesswork without it.

Unit economics, not just totals

Cost per tenant, per transaction, per active user, per inference. A total tells you the bill went up. A unit cost tells you whether that was growth or waste, which is the only version of the number a product owner can act on.

Azure Virtual Desktop cost control

AVD is where cloud spend leaks most quietly: session hosts running out of hours, autoscale schedules that never matched the working day, host pools sized for a peak that happens twice a year. Right-sizing, start/stop automation and per-user cost reporting that names the pools worth consolidating.

Commitment strategy

Reservations, savings plans and Azure Hybrid Benefit modelled against your actual usage curve, not a vendor worksheet. Committing to the wrong shape locks in spend you cannot exit, so the coverage target is set deliberately and the uncommitted remainder is left deliberately.

Waste elimination with a shut-off date

Orphaned disks and public IPs, idle app service plans, over-provisioned SKUs, dev environments nobody switched off, forgotten snapshots. Each finding gets an owner and a date, because a list of findings nobody is accountable for is the reason the last sprint did not hold.

Guardrails and anomaly alerting

Budgets with actions attached, anomaly detection routed to the team that caused the spike instead of a central inbox, and policy that blocks the expensive mistakes at deployment. The aim is that the next surprise is caught in days, by the people who can fix it.

Marketplace and procurement spend

Azure Marketplace purchases, third-party SaaS billed through the subscription, and whether that spend is drawing down your commitment. Routinely the least visible line on the bill and the one procurement is most surprised by.

Delivery

How the engagement runs

Six weeks to a governed position. The gate is deliberate: we do not touch commitment purchasing until attribution is trustworthy, because a reservation bought against bad data is a mistake with a one to three year term.

Baseline then Attribute then Attribution gate then Model then Enforce then Operate01Baseline12 months of billing02AttributeTag taxonomy + policy03Attribution gateUntagged spend under threshold04ModelUnit costs + commitment05EnforceBudgets, alerts, owners06OperateMonthly cadence
The gate is the point of the diagram. Optimising before attribution is trustworthy produces savings nobody can defend and nobody can repeat.

Detail

What we will tell you that a cost-optimisation pitch will not

Four things that decide whether this holds after we leave.

FinOps is an operating cadence, not a project

A one-off sprint recovers spend and then the curve resumes, because the behaviour that produced it is unchanged. What makes it stick is a monthly meeting where named people answer for their own unit costs. If nobody will own that meeting, the engagement will not pay for itself and we would rather say so at the start.

Retrofitting tags is the expensive part

Tagging a greenfield estate is configuration. Tagging an estate with four years of untracked resources is archaeology — tracing owners for things nobody remembers deploying. It is usually the largest line in the engagement and the one most proposals quietly leave out.

A saving nobody banks is not a saving

Reduced cloud spend that is immediately absorbed by new workloads is not a saving; it is headroom. Both are legitimate outcomes, but they are different conversations with finance and the difference should be agreed before the work starts, not claimed afterwards.

Commitments are a bet on your own roadmap

A three-year reservation assumes an architecture that still exists in three years. If a migration, a re-platform or an AI workload is coming, the coverage target should reflect that. We would rather leave money on the table than lock you into a shape you are about to leave.

Questions

Answered straight

  • FinOps is the practice of making cloud spend accountable: attributing every cost to a team, product or customer, expressing it as a unit cost that somebody owns, and running a monthly cadence where those owners answer for it. On Azure it is built from Cost Management, Azure Policy for tag enforcement, budgets and anomaly alerts. It is a governance practice rather than a discount exercise — the discounts are a consequence of it, not the point.

Next

Send us twelve months of Azure billing.

We will come back with where the spend actually sits, how much of it cannot be attributed to anyone, and the three changes worth making first. You get that assessment in writing whether or not you engage us afterwards.