Cloud cost and FinOps

Paying only for what runs is the cloud's great advantage and its most reliable source of unpleasant surprises. A test environment left on over a holiday, logs kept forever, data copied between regions for no reason: each is invisible in the architecture diagram and obvious on the invoice weeks later. Because the people who create resources are not the people who pay for them, cost problems in the cloud are organisational before they are technical.

What the FinOps Framework adds

The FinOps Foundation defines its subject as a cultural and operational practice that brings engineering, finance and business together around the value of technology spend. Its framework is deliberately loose: organisations pick the parts they need and mature at their own pace. The work moves through three recurring phases.

1. Inform. Make spending visible and attributable: tag or label resources, allocate shared costs, and give each team timely figures for what it runs.
2. Optimize. Act on what the figures show, by resizing overprovisioned machines, removing idle resources, choosing cheaper storage tiers and committing to discounts for steady load.
3. Operate. Build the habits in: budgets and alerts, regular reviews between engineers and finance, and cost checks inside the delivery process rather than after it.

Six principles sit behind those phases, and two carry most of the weight. Everyone who uses technology owns its cost, which means engineers see the figures, not only accountants. And the variable cost model is something to exploit rather than fear, since capacity that can shrink should be made to shrink. The framework's domains extend the same idea from understanding usage through quantifying value to running the practice itself.

Levers an engineer actually pulls

Most savings come from a short list. Match instance sizes to measured load rather than to guesses made at launch. Turn off non-production environments outside working hours. Move rarely read data to colder storage classes and set lifecycle rules that do it automatically. Commit to reserved capacity or savings plans only for load you can prove is steady. Watch data transfer, especially traffic leaving the provider or crossing regions, because it rarely appears in early estimates. Cost optimisation is one of the six Well-Architected pillars, and SAA-C03 devotes a full domain to cost-optimised design, so these choices turn up as exam questions as well as budget meetings.

Mature teams stop reporting the total and start reporting unit costs: spend per customer, per order, per thousand requests. A bill that doubles alongside revenue is healthy; a bill that doubles while usage stays flat is a defect. Expressing cost this way is what the framework means by quantifying business value, and it gives engineers a figure they can improve without waiting for finance to notice.

The sustainability pillar points the same way: a machine nobody needs costs money and energy alike. The architecture topic in this silo covers the design side of these trade-offs, while the fundamentals topic and the cost sections of Azure Fundamentals give the entry-level view of consumption pricing.