---
title: "FinOps"
slug: finops
category: cost
term_status: established
evidence_status: verified
summary: "FinOps is the operating model for variable technology spend: engineering, finance, product, procurement and leadership share timely cost data and clear decision rights, so that cloud, SaaS, data-platform and AI spend buys measurable business value."
audience: [Beginners, Engineers, Finance and procurement, Architects, Leaders]
last_verified: 2026-10-16
key_takeaways:
  - "FinOps is a decision system, not a savings project: it settles who decides about spend, on which data, and how often."
  - "Cost = usage × rate. Engineers own usage; a central team coordinates rates and commitments; finance owns budgets."
  - "Allocation comes first: until most spend has an owner, forecasts, unit costs and chargeback are guesses."
  - "Use effective (amortised) cost for accrual-based decisions and showback, billed cost for invoices and cash budgets."
  - "Judge commitments by effective savings rate, not coverage, and a bill by its unit cost, not its size."
related: [finops-for-ai, greenops, cloudops, procurementops, portfolioops, bizops, platformops, kubernetesops]
---

## What FinOps is

### In 30 seconds

**FinOps is the practice of treating variable technology spend as a shared, continuous business decision.** Engineers,
finance, product owners, procurement and leaders work from the same timely cost and usage data, each group owns the decisions in
its own remit, and they meet on a fixed cadence to trade off cost, speed and quality.

The FinOps Foundation, which maintains the most widely used framework, defines FinOps as "an operational framework and cultural
practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial
accountability through collaboration between engineering, finance, and business teams."[^fin-def] The name joins "Finance" and
"DevOps". The practice began with public cloud bills and now also covers SaaS, licences, data centres and data cloud
platforms,[^fin-def] and Framework 2026 adds technology-category guidance for AI.[^fin-2026]

Three loops make up the whole discipline:

1. **See it.** Every unit of spend has an owner and a purpose, and the data arrives fast enough to act on.
2. **Improve it.** People use less (usage optimisation) and pay less per unit (rate optimisation) where the value justifies the effort.
3. **Run it.** Decisions are made, acted on and measured on a fixed cadence that includes funding growth, not just cutting.

**Who this page is for:** beginners, engineers, finance and procurement, architects and leaders; a route for each is in the
[learning path](#learning-path).

### At a glance

| Item | Summary |
|---|---|
| Goal | More business value per unit of technology spend; spend that is explainable, forecastable and owned |
| Users | FinOps practitioners; engineering and platform teams; finance and procurement; product owners; executives |
| In scope | Allocation, shared costs, reporting, anomalies, forecasting and budgeting, unit economics, usage and rate optimisation, showback and chargeback, governance, FOCUS data, tooling |
| Handed elsewhere | AI economics, carbon, contracts, the control plane and portfolio choices go to the [neighbours](#how-finops-relates-to-other-ops) |
| Prerequisites | How your organisation budgets and closes its books; basic cloud billing; spreadsheets or SQL |
| Key outputs | Tagging standard; showback (chargeback only if policy requires); forecasts and budgets; a commitment portfolio; anomaly runbooks; a scorecard |
| Term status | **Established:** a Linux Foundation project, a CC BY 4.0 framework, an open billing-data specification (FOCUS), certifications and an annual survey[^fin-about][^focus-spec][^sof-2026] |
| Evidence | Framework facts from the FinOps Foundation (guidance, not law); provider facts from AWS, Microsoft and Google, dated October 2026; anything marked *illustrative* is invented for teaching |

### Mental model and glossary

**Three equations and three questions.**

1. **Cost = usage × rate.** Usage levers (size, schedule, architecture, deletion) belong mostly to engineers; rate levers
   (commitments, negotiated discounts, spot capacity, licensing models) mostly to a central team working with procurement, finance
   and leadership.[^fin-principles][^fin-phases][^cap-rate]
2. **Value = outcome ÷ cost.** A cost means nothing without the result it bought; unit economics, such as cost per order or per
   1,000 API calls, turns spend into something a product owner can manage.[^cap-unit]
3. **Accountability = data × decision rights × cadence.** People can be accountable only for spend they can see, are allowed to
   change, and are regularly asked about; remove any one and accountability collapses.

For any unit of spend, ask: **Who owns it? What did it buy? Should it continue at this rate?** Most FinOps practices answer one of
the three at scale.

**Glossary.**

- **Allocation:** assigning each cost to the people or units responsible, directly or as a share of a common cost.[^cap-alloc]
- **Showback and chargeback:** reporting costs to the teams that caused them without moving money; chargeback also posts them to
  cost centres in the ledger.[^cap-chargeback]
- **Shared cost:** spend that benefits several owners (support, shared networking, platform clusters), split by fixed ratio,
  proportion of direct spend or a proxy metric, or deliberately held centrally ("informed ignore").[^cap-alloc]
- **Billed and effective cost:** cost as invoiced in a billing period (the cash view), and amortised cost after discounts, with
  purchases spread over the usage they cover (the accrual view).[^focus-spec]
- **List cost, or on-demand equivalent (ODE):** the cost at public, undiscounted rates; the baseline for savings.
- **Coverage and utilisation:** the share of eligible usage paid at the commitment rate, and the share of a purchased commitment
  actually used ($9.80 of a $10/hour commitment is 98%).[^aws-sp-reports]
- **Effective savings rate (ESR):** savings net of any cost to achieve them ÷ on-demand-equivalent spend; $5,000 saved on $10,000
  of ODE spend is 50%.[^esr]
- **Forecast and budget:** the owners' expectation of spend, and the organisation's funding commitment.[^cap-forecast][^cap-budget]
- **Scope and technology category:** "a defined segment of spending across technology categories, aligned to business
  constructs",[^fin-scopes] such as everything that runs the mobile app; and the kind of technology bought (public cloud, SaaS,
  data centre, data platforms, AI).[^fin-2026]

**How the framework fits together.** Scopes say *why* spend is managed, technology categories *what* is bought;[^fin-2026]
"Domains are the outcomes of a FinOps practice & Capabilities describe how to achieve them."[^fin-fw] Phases form a loop, not a
project plan,[^fin-phases] and maturity is assessed per capability.[^fin-maturity]

::: figure How the parts of the FinOps Framework relate
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 30}}}%%
flowchart TB
  Q["Business question from leadership"] --> S["Scope: the why, such as a product. It spans technology categories, the what: public cloud, SaaS, AI"]
  P["Six principles"] -->|guide| PE["Personas: practitioner, engineering, finance, product, procurement, leadership"]
  S -->|"selects and tunes"| C["Capabilities: the how, such as allocation, forecasting, rate optimisation"]
  PE -->|perform| C
  C -->|"achieve outcomes in"| D["Four domains: understand usage and cost, quantify value, optimise, manage the practice"]
  C -.->|"applied per capability"| LM["Phases: an Inform, Optimize, Operate loop. Maturity: Crawl, Walk, Run"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class C,D core
  class P,PE,LM neutral
  class Q,S decision
```
Text equivalent: A business question from leadership leads to a scope (the why, such as a product), which spans technology
categories (the what) and selects and tunes the capabilities. The six principles guide the personas, who perform the capabilities.
Capabilities achieve outcomes in four domains: understand usage and cost, quantify business value, optimise usage and cost, and
manage the practice. The Inform, Optimize, Operate phases (a loop) and Crawl, Walk, Run maturity apply per capability.
:::

### The problem FinOps solves

**Spending decisions moved into code.** In a data centre, spend passes through procurement before money is committed: a business
case, capital approval, a purchase; slow, but controlled *before* it happens. With consumption-based technology, any engineer or
pipeline with API access can commit spend at any minute, and the bill arrives after month end, summarised by service and account
rather than by product or team. Finance can see the cost but cannot change it; engineering can change it but sees it weeks too late.

FinOps closes the gap between **the people who decide** (mostly engineers, through architecture and configuration) and **the
people accountable for money** (budget owners and finance): "Everyone takes ownership for their technology usage", and "FinOps data
should be accessible, timely, and accurate".[^fin-principles] Without that, spend has no owner, runaway jobs run for weeks, budgets
cannot follow demand, discounts go unbought or idle, and nobody can tell good growth from bad: a bill up 30% is fine if orders
rose 60%.

::: figure Before and after: who decides, who sees the cost, and how fast they meet
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 170, "nodeSpacing": 30, "rankSpacing": 40}}}%%
flowchart LR
  subgraph after["With FinOps"]
    direction TB
    A1["Engineer deploys with owner tags and a cost estimate"] --> A2["Daily cost and usage data, normalised"]
    A2 --> A3["Allocated to owner, product and scope"]
    A3 --> A4["Owner sees unit cost, budget burn and anomalies"]
    A4 --> A5{{"Cadenced review: optimise, accept or fund?"}}
    A5 -->|"specific, fast feedback"| A1
  end
  subgraph before["Without FinOps"]
    direction TB
    B1["Engineer deploys resources"] --> B2["Provider bills monthly by account and service"]
    B2 --> B3["Finance sees invoice 3 to 12 days after month end"]
    B3 --> B4{{"Who owns this cost?"}}
    B4 -->|unknown| B5["Cost-cutting mandate"]
    B5 -.->|"blunt, late feedback"| B1
  end
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class B4,B5 risk
  class A1,A2,A3,A4 core
  class A5 decision
```
Text equivalent: Without FinOps (top): an engineer deploys; the provider bills monthly by account and service; finance sees the
invoice 3 to 12 days after month end; nobody knows who owns the cost, so a cost-cutting mandate follows (blunt, late feedback).
With FinOps (bottom): the engineer deploys with owner tags and an estimate; daily normalised data are allocated to owner, product
and scope; the owner sees unit cost, budget burn and anomalies; a cadenced review decides to optimise, accept or fund (specific,
fast feedback).
:::

**The value, stated honestly.** FinOps promises no fixed percentage of savings. Its claim is narrower: **decisions about spend
improve when the people making them see accurate, timely data and are accountable for the outcome.** Often that means spending more
on the right things: "If it seems that FinOps is about saving money, think again."[^fin-def] In the 2026 survey,
mature practitioners report diminishing returns from classic optimisation ("We have hit the 'big rocks' of waste") and focus on
influencing technology selection; across all respondents, scope expansion, governance, alignment and forecasting together now
outweigh optimisation alone.[^sof-2026]

### What FinOps is not

FinOps borrows words from finance and from DevOps, so it gets confused with both.

| Common belief | Reality |
|---|---|
| "FinOps is a cost-cutting programme." | It is value management: cutting is one outcome; funding a profitable service faster is another. |
| "FinOps is a tool we buy." | Tools implement parts of capabilities; decision rights, cadence and accountability are organisational. |
| "The FinOps team does FinOps." | "It is not only the FinOps team who perform FinOps activities";[^fin-personas] engineers do most usage optimisation. |
| "FinOps means financial operations." | That is payables, receivables and close; the Foundation calls "Cloud Financial Operations" an incorrect expansion.[^fin-def] |
| "Chargeback is the mature form of showback." | Neither is more mature: showback is always required, and chargeback depends on accounting policy.[^cap-chargeback] |
| "Tagging everything solves allocation." | Support, taxes and some shared charges cannot be tagged; allocation also needs a shared-cost strategy.[^cap-alloc] |

**Naming collisions.** [FinTechOps](../fintechops/) operates payment and ledger systems, a different field. Contract negotiation
belongs to [ProcurementOps](../procurementops/), with FinOps supplying demand data. IT Financial Management (ITFM, often run with the
Technology Business Management method) models the whole IT cost base; the Foundation lists ITFM/TBM practitioners as an allied
persona under its *Intersecting Disciplines* capability.[^fin-personas] As an **editorial distinction**, this page treats FinOps as the near-real-time decision loop on
variable consumption, and ITFM as the slower, enterprise-wide cost model it feeds. IT asset management (ITAM/SAM) shares licence
and SaaS data with FinOps.[^cap-licensing]

## Where FinOps comes from and where it sits

### Origins and evolution

FinOps grew out of a practical problem in the 2010s: cloud bills became large, variable and hard to explain. Milestones traceable
to primary sources:

- **February 2019:** the FinOps Foundation is founded, growing out of the cloud-cost vendor Cloudability's customer advisory board,
  which provided initial underwriting[^fin-about] (a vendor origin worth knowing when reading early material).
- **29 June 2020:** the Linux Foundation announces its intent to host the Foundation, then about 1,500 individual members, and
  mentions the FinOps Certified Practitioner exam.[^lf-2020]
- **2023:** *Cloud FinOps*, second edition (J.R. Storment and Mike Fuller, O'Reilly Media), a widely used practitioner book;
  Storment was the Foundation's executive director in 2020.[^book][^lf-2020]
- **June 2024:** FOCUS 1.0 is tagged, a common schema for billing data from different providers.[^focus-releases]
- **2025:** the framework introduces **FinOps Scopes** and technology categories beyond public cloud.[^fin-2026]
- **19 February 2026:** the mission changes from managing the value "of cloud" to the value "of technology".[^fin-mission]
- **19 March 2026:** Framework 2026 adds **Executive Strategy Alignment** and renames six capabilities, two of them to drop
  "Cloud".[^fin-2026]
- **June 2026:** FOCUS 1.4, the latest as of October 2026, adds billing-period and invoice-detail datasets.[^focus-releases][^focus-spec]

**The evidence base** is mostly the Foundation's framework, papers and survey, plus provider documentation. Peer-reviewed research
is thin; one example is a 2024 Brazilian Computer Society workshop paper that surveyed 28 cloud professionals about financial
waste.[^washes] Treat claims about typical savings with caution.

### How FinOps relates to other Ops

FinOps holds the generic mechanics (allocation, unit economics, commitments, cadence); the neighbours specialise them.

| Neighbour and its depth | Handoff rule |
|---|---|
| [CloudOps](../cloudops/): control plane and guardrails | CloudOps builds tag and budget guardrails; FinOps defines what they enforce |
| [FinOps for AI](../finops-for-ai/): GPU and token economics | Generic mechanics here; AI economics there |
| [GreenOps](../greenops/): carbon accounting | Rightsizing taught here; carbon trade-offs there |
| [ProcurementOps](../procurementops/): contracts and suppliers | FinOps supplies demand forecasts and usage history |
| [PortfolioOps](../portfolioops/), [BizOps](../bizops/): investment and planning | FinOps supplies unit cost, run rate and forecasts |
| [PlatformOps](../platformops/), [KubernetesOps](../kubernetesops/): shared platforms | Platforms show back to tenants with FinOps shared-cost rules |
| [DevOps](../devops/), [SRE](../sre/): delivery and SLOs | Cost targets never quietly erode SLOs |
| [ITOps](../itops/): ITSM and ITAM | Licence and asset data shared with ITAM |
| [InfraOps](../infraops/), [AutomationOps](../automationops/): IaC and automation | FinOps writes the policy; infrastructure makes it the default |

::: figure FinOps and its neighbours: what flows across each boundary
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 30}}}%%
flowchart TB
  PS["CloudOps, PlatformOps and KubernetesOps: control plane and shared platforms"] <-->|"To FinOps: accounts, tags, budget alerts, tenant usage. From FinOps: tag rules, showback"| FO["FinOps: decision rights, allocation, unit economics, rates, cadence"]
  BS["ProcurementOps, PortfolioOps and BizOps: contracts, investment, planning"] <-->|"To FinOps: rates, priorities, budgets. From FinOps: demand forecasts, unit cost"| FO
  FO <-->|"cost versus reliability trade-offs"| SR["SRE and DevOps: SLOs and delivery"]
  FO -->|"generic mechanics; utilisation and idle data"| SP["FinOps for AI and GreenOps: AI and carbon economics"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class FO core
  class PS,BS,SR,SP neutral
```
Text equivalent: FinOps sits in the middle. The platform side (CloudOps, PlatformOps, KubernetesOps) sends accounts, tags, budget
alerts and tenant usage, and receives tag rules and showback. The business side (ProcurementOps, PortfolioOps, BizOps) sends rates,
priorities and budgets, and receives demand forecasts and unit cost. FinOps and SRE/DevOps exchange cost-versus-reliability
trade-offs; FinOps passes generic mechanics, utilisation and idle data to FinOps for AI and GreenOps.
:::

## Principles, roles and operating model

### Charter and principles

The Foundation publishes six principles; the names are verbatim, and the second column is this page's interpretation.[^fin-principles]

| Principle (FinOps Foundation) | What it forces you to do |
|---|---|
| Teams need to collaborate | One recurring forum and one data set for finance, engineering, product and procurement |
| Business value drives technology decisions | Report unit cost and value, not totals |
| Everyone takes ownership for their technology usage | Every resource has an owner from creation; teams see their own costs |
| FinOps data should be accessible, timely, and accurate | Daily, allocated, reconciled data that owners query themselves |
| FinOps should be enabled centrally | A small central team runs standards, data and rate optimisation |
| Take advantage of the variable cost model of the cloud | Use each category's cost model (variable cloud, fixed data centre, licence) deliberately; prefer just-in-time purchasing |

*Ownership* pushes decisions out to teams while *central enablement* pulls rate decisions in; the Foundation splits the levers:
"Rate, commitment, and discount optimization are best centralized to take advantage of economies of scale", leaving engineers to
optimise their own usage.[^fin-principles]

**A charter (this Atlas's proposal).** The Foundation publishes no charter for adopting organisations; its Technical Charter
governs the Foundation project itself.[^fin-charter] The fill-in charter in [Templates](#templates) is this Atlas's proposal. Its
invariants, which the template leaves implicit: every number traces back to source billing data; cost never silently overrides
reliability or security; shared-cost rules are written down and stable for at least a quarter; whoever can buy a commitment is not
its only reviewer; decisions state the uncertainty of imperfect data.

### Roles, ownership and RACI

The Foundation defines six **core personas** plus **allied personas** such as ITAM, ITFM, Sustainability, ITSM and Security;
personas are stakeholder groups, not job titles, and one person may cover several.[^fin-personas] In the 2026 survey, centralised
enablement was the most common structure (60%), then hub-and-spoke (21%), and 78% of practices reported into the CTO or CIO
organisation;[^sof-2026] the sample is self-selected, but the pattern is clear: small central teams set standards, and execution
is distributed.

| Model | How it works | Watch-outs |
|---|---|---|
| Central enablement | A small team sets standards and runs data and rate optimisation; teams act on usage | Can drift into "cost police" |
| Hub-and-spoke | A central hub plus champions embedded in business units[^cap-ops] | Champions need time and recognition |
| Virtual team or committee | Finance and engineering share the role part-time[^cap-ops] | Nobody's main job; stalls under pressure |
| Inside platform engineering | The platform team owns tooling and defaults[^cap-ops] | Finance and product voices can be weak |

**RACI for recurring decisions (this Atlas's proposal).** R = responsible, A = accountable, C = consulted, I = informed; every row
has exactly one A.

| Decision | FinOps | Engineering | Finance | Product | Leadership |
|---|---|---|---|---|---|
| Tagging and allocation standard | A/R | C | C | I | I |
| Shared-cost distribution rules | R | C | A | C | I |
| Rightsizing or scheduling a service | C | A/R | I | C | – |
| Buying a commitment, up to the policy threshold | R | C | A | I | I |
| Buying a commitment, above the policy threshold | R | C | C | I | A |
| Setting a team's annual budget | C | C | A/R | C | I |
| Triage of a cost anomaly | C | A/R | I | I | – |
| Posting chargeback to the ledger | C | – | A/R | I | – |
| Unit-cost target for a product | C | C | C | A/R | I |
| Choosing FinOps tooling | A/R | C | C | – | I |

**Procurement**, left out to fit small screens, is A/R for negotiating enterprise agreements (FinOps, engineering and finance
consulted), C on commitment purchases and tooling, and I on the tagging standard and shared-cost rules.

**Skills matrix.**

| Skill | Practitioner | Engineer | Finance analyst |
|---|---|---|---|
| Reading billing data (FOCUS, provider exports), SQL | Deep | Working | Working |
| Provider pricing and commitment mechanics | Deep | Working | Basic |
| Architecture and performance trade-offs | Working | Deep | Basic |
| Budgeting, accruals, amortisation, close | Working | Basic | Deep |
| Facilitation and negotiation across teams | Deep | Working | Working |
| Automation and policy-as-code | Working | Deep | – |

### Lifecycle: Day 0, Day 1, Day 2

FinOps has two lifecycles: the **practice** and each **workload** it looks after.

**The practice.** Day 0 (design) and Day 1 (launch) are planned in the [30/60/90-day roadmap](#adoption-roadmap-30-60-and-90-days);
Day 2 follows the [maturity model](#maturity-model). Adoption repeats after every reorganisation, acquisition or new technology
category.[^cap-ops]

**The workload.** *Estimate* → *provision* with ownership metadata → *observe* cost and unit cost → *optimise* usage and rate →
*forecast* and *budget* → *retire*, releasing commitments and licences. The **Inform → Optimize → Operate** phases run over both
lifecycles as a loop that practitioners "cycle through … rapidly", with different people at different cadences.[^fin-phases]

::: figure The Inform, Optimize, Operate loop, with this Atlas's proposed Measure step and cadences
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 190}}}%%
flowchart TB
  I["Inform: ingest, allocate, report, detect anomalies. Cadence: daily anomaly triage"] --> O["Optimize: list and rank usage and rate options. Cadence: weekly team cost review"]
  O --> P["Operate: decide, act, assign owners, update policy. Cadence: monthly showback, close and forecast; quarterly commitments and KPIs"]
  P --> M["Measure the effect on spend and unit cost (Atlas proposal)"]
  M --> I
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class I,O,P core
  class M neutral
```
Text equivalent: Inform (ingest, allocate, report, detect anomalies) leads to Optimize (list and rank usage and rate options),
then Operate (decide, act, assign owners, update policy). These three phases are the Foundation's; the fourth step (measure the
effect on spend and unit cost, then return to Inform) and the cadences are this Atlas's proposal: daily anomaly triage, a weekly
team cost review, monthly showback, close and forecast, and quarterly commitment and KPI reviews.
:::

### Operating model and governance

An operating model answers four questions: **what is reviewed, by whom, how often, and what happens when a threshold is crossed.**
The calendar is this Atlas's proposal for a mid-sized organisation.


| Cadence | Forum and inputs | Decisions and outputs | Owner |
|---|---|---|---|
| Daily | Anomaly alerts on allocated cost | A ticket per anomaly: fix or explain | Owning team |
| Weekly | 15-minute slot in a team meeting: spend, budget burn, unit cost | Accept or reject top optimisation items | Engineering lead |
| Monthly | FinOps review: closed month, forecast vs actual, KPIs, invoices | Showback; re-forecast; variances explained; accruals | FinOps lead with finance |
| Quarterly | Commitment review: baseline, utilisation, coverage, migrations | Buy, exchange or let expire; targets | FinOps (R), finance (A) |
| Quarterly | Executive review: unit-cost trends, top scopes, risks | Funding shifts, priorities, policy approvals | Executive sponsor |
| Annually | Budget and contract cycle: driver-based forecasts, roadmap | Budgets with holdbacks; renewals via procurement | Finance and procurement |

**Policies.** Governance, Policy & Risk includes commitment guardrails and escalation paths agreed with finance.[^cap-gov] Start
with four written policies: tagging and ownership; non-production schedules and lifetime; commitment purchasing (who may buy, how
much, for how long, reviewed by whom); anomaly response.

::: figure Month-end close: handoffs between providers, FinOps, teams and finance
```mermaid
%%{init: {"sequence": {"wrap": true, "width": 80, "actorMargin": 40, "wrapPadding": 4}}}%%
sequenceDiagram
  participant CP as Providers
  participant FI as Finance
  participant FO as FinOps
  participant EN as Engineers
  CP->>FO: Daily cost data
  FO->>EN: Daily cost, alerts
  Note over CP,FO: Month ends, data settles for days
  FO->>FI: Accrual estimate
  CP->>FI: Invoices
  FI->>FO: Invoice totals
  Note over FO,EN: Reconcile, split shared costs
  FO->>EN: Final showback
  FO->>FI: Chargeback file
  FI->>FO: Accrual trued up
  EN->>FO: Variance actions
```
Text equivalent: Providers send daily cost data to FinOps, which sends daily allocated cost and anomaly alerts to engineers. After
month end, while usage data settles for a few days, FinOps sends finance an accrual estimate from allocated effective cost; then
invoices reach finance, which passes the invoice totals to FinOps. FinOps reconciles billed cost to the invoices, applies
shared-cost rules and publishes final showback and unit cost to engineers, plus a chargeback file to finance if policy requires
it; finance trues up the accrual, and engineers return variance explanations and actions.
:::

## Building blocks: data, ownership, rates, usage and value

### 1. Cost and usage data

Providers publish line-item billing data by resource and by hour or day. A single-provider organisation may not need to ingest
anything; a multi-vendor estate needs a real data pipeline.[^cap-ingest] Usage data arrives continuously, invoices typically 3 to 12
days after month end:[^cap-chargeback] daily data is good enough for decisions, but month-end close needs reconciliation to the invoice.

**FOCUS** (the FinOps Open Cost and Usage Specification) "defines a common schema for billing data"; it is maintained under the
Joint Development Foundation, licensed CC BY 4.0, and at version 1.4 as of October 2026.[^focus-spec] Four cost columns matter most:

| FOCUS column | Meaning (paraphrased from the specification) | Use it for |
|---|---|---|
| `BilledCost` | Cost as invoiced in the billing period; must match the issued invoice within a rounding tolerance | Invoice reconciliation; cash forecasts and budgets |
| `EffectiveCost` | Cost after all discounts, including the amortised share of prepaid or committed purchases; a purchase that covers other charges has an effective cost of 0, because its cost appears on those charges | Showback, allocation, unit cost; accrual forecasts |
| `ListCost` | List unit price × pricing quantity | Savings from rate optimisation |
| `ContractedCost` | Negotiated unit price × pricing quantity | Savings from negotiation |

FOCUS also classifies each row with `ChargeCategory` (Usage, Purchase, Tax, Credit or Adjustment), marks used and unused
commitment with `CommitmentDiscountStatus`, and requires custom columns to carry an `x_` prefix.[^focus-spec]

**How billed and effective cost reconcile.** Amortisation moves cost between rows; it does not create or destroy it. FOCUS states
the rule precisely: effective and billed cost summed across a commitment purchase and the charges it covers are equal *within the
charge period of the purchase, when both sides are in the data*, and billing-period totals **may differ** when covering and covered
charges span several billing periods or billing accounts.[^focus-spec] An all-upfront three-year purchase is billed in the month you
buy it but recognised over 36 months, so monthly totals differ throughout the term ([payment options](#3-rates)). Two checks
follow, run by query Q5 in the [reference implementation](#reference-implementation-artefacts-you-can-reuse) and by Lab 1:

- **Monthly:** the sum of `BilledCost` for each `InvoiceId` must match the invoice's payable amount, within a rounding tolerance,
  once the invoice is issued.[^focus-spec]
- **Per commitment, over its term:** what was billed for the purchase equals the effective cost it covered plus its unused remainder.

As of October 2026, AWS, Azure and Google Cloud all offer FOCUS exports[^aws-focus][^az-focus][^gcp-bq] (versions are dated under
[Tooling landscape](#tooling-landscape)). Columns differ between versions (`ServiceProviderName` and `HostProviderName` succeeded
`ProviderName`, for example), so query the version you actually receive.

### 2. Ownership metadata

Allocation uses three kinds of metadata: the **resource hierarchy** (accounts, subscriptions, projects, folders), **tags or
labels** on resources, and **derived metadata** from outside the bill, such as a CMDB, a service catalogue or Kubernetes
namespaces.[^cap-alloc] Hierarchy is the most reliable, because every charge belongs to some account; tags add detail but are
incomplete; derived metadata fills the gaps. Provider mechanics are easy to get wrong:

- On AWS, user-defined tags reach billing data only once **activated** as cost allocation tags; keys can take up to 24 hours to
  appear and another 24 to activate, and a management account can request a **backfill** of up to twelve months.[^aws-tags]
- On Google Cloud, standard billing export to BigQuery adds data retroactively only for the current and previous month, and only
  for multi-region datasets; regional datasets start the day you enable export.[^gcp-bq] **Turn exports on first**: history you did
  not export may be gone for good.

### 3. Rates

Every provider sells the same capacity at several prices. **Commitment discounts** trade flexibility for a lower rate: the
Foundation describes them as "similar to coupons" that cover matching usage, and if nothing matching runs, you still pay; the more
restrictive the commitment, the deeper the discount.[^cap-rate] As of October 2026, all three large providers sell both kinds, for
terms of 1 or 3 years:

| Provider | Spend-based commitments | Resource-based commitments |
|---|---|---|
| AWS | Savings Plans (Compute, EC2 Instance, Database, SageMaker AI): a $/hour commitment[^aws-sp] | Reserved Instances, paid for the entire term regardless of use[^aws-ri] |
| Microsoft Azure | Savings plans for compute and for databases: a fixed $/hour amount[^az-sp] | Reservations, "up to 72%" off pay-as-you-go according to Microsoft[^az-res] |
| Google Cloud | Spend-based committed use discounts (CUDs), including Flexible Savings Plans[^gcp-cud] | Resource-based CUDs[^gcp-cud] |

Three mechanics catch people out.

1. **The evaluation window.** Most commitments are evaluated **hour by hour**: AWS states that "each hour's commitment can only be
   used within that hour" for Savings Plans and bills Reserved Instances for every clock-hour of the term; Azure applies savings
   plans and all reservations except Azure Databricks hourly, and unused hourly commitment expires; Google's standard spend-based
   CUDs discount usage up to an hourly committed amount.[^aws-sp-apply][^aws-ri][^az-sp][^az-res][^gcp-cud] Unused commitment
   cannot be saved for the peak, so these instruments pay best when sized to the **hourly floor** of eligible usage
   ([Lab 2](#lab-2-intermediate-size-a-commitment-with-a-what-if-model)). Google's Flexible Savings Plans are the exception: they
   "evaluate usage over a monthly entitlement window",[^gcp-cud] so size them to the lowest *monthly* eligible total, allowing for
   month-to-month variance. Check the window before sizing any instrument.
2. **Interaction with usage optimisation.** Rightsizing after a resource-based purchase can leave the commitment idle, and adding up
   both kinds of recommendation can double-count savings.[^cap-rate]
3. **Payment options change the cash profile, not the total.** Billed cost (cash) moves away from effective cost (accrual), and
   forecasts and reconciliation must follow the option chosen (as of October 2026):

| Payment option | Offered for | Billed cost (cash) | Effective cost (accrual) |
|---|---|---|---|
| All upfront | AWS Savings Plans[^aws-sp] | Whole term in the purchase month | Spread over the term |
| Partial upfront | AWS Savings Plans[^aws-sp] | A lump sum, then a monthly fee | Spread over the term |
| Upfront or monthly (same total) | Azure savings plans and reservations[^az-sp][^az-res] | Lump sum, or a fee each month | Spread over the term |
| No upfront, or a monthly fee | AWS Savings Plans;[^aws-sp] Google CUDs (monthly fee for the whole term)[^gcp-cud] | A fee each month | Close to billed each month |


**Interruptible capacity** (spot or preemptible VMs) costs much less, but the provider can reclaim it at short notice, so the
Foundation also calls it a usage decision.[^cap-rate] As of October 2026 the warning ranges from none by default on Google Cloud
(120 seconds if configured) to two minutes on AWS,[^gcp-spot][^aws-spot] and Azure's default *Deallocate* eviction policy keeps
billing for the disks of evicted VMs.[^az-spot] Designing workloads for interruption is [CloudOps](../cloudops/) work.

### 4. Usage

Usage optimisation means making sure resources are "properly selected, correctly sized, only run when needed, appropriately
configured, and highly utilized". It is mainly engineering work, with thresholds so nobody spends time on trivial items.[^cap-usage]
The levers, roughly in order of effort: delete what is unused; schedule what is needed part-time; rightsize; change storage tiers
and retention; re-architect, for example to managed services or caching.

In Kubernetes the unit that drives cost is the **request**, not actual usage: the scheduler places pods by their requests, so
over-requested pods reserve capacity nobody else can use.[^k8s-req] The OpenCost specification therefore charges each workload
`max(request, usage)` for allocation-priced resources and calls the unclaimed rest **idle cost** (cluster asset cost minus workload
cost).[^opencost-spec] Cluster mechanics are in [KubernetesOps](../kubernetesops/); the allocation rules come from this page.

### 5. Value

Unit metrics connect spend to outcomes. The Foundation separates **resource-efficiency unit metrics** (cost per GB stored, per
vCPU, per token), which engineers control directly, from **business unit metrics** (cost per tenant, per transaction, cost to
serve), which give organisational context and usually come with higher maturity. "The most actionable view is a trend over time
within a defined FinOps Scope"; comparing unit costs across unrelated products usually misleads.[^cap-unit]

## Architecture and workflow

### Reference architecture

FinOps architecture is mostly a **data architecture with a thin control plane**. Each layer is a responsibility, not a product;
small organisations collapse several into one provider console.

| Layer | Responsibility | Typical implementations (examples, not endorsements) |
|---|---|---|
| Sources | Billing exports, invoices, SaaS bills, Kubernetes allocation, business drivers | Provider FOCUS exports;[^aws-focus][^az-focus][^gcp-bq] OpenCost[^opencost-docs] |
| Ingestion | Land raw data; normalise to FOCUS; keep provider detail in `x_` columns | Warehouse jobs; Microsoft's MIT-licensed FinOps toolkit[^ms-toolkit] |
| Enrichment | Map accounts, tags and namespaces to owners and scopes; apply shared-cost rules | Version-controlled mapping tables; CMDB joins |
| Semantic layer | One definition per KPI | SQL views or a metrics layer |
| Consumers | Showback, anomaly tickets, forecasts, chargeback | BI, ticketing, general-ledger import |
| Control plane | Required tags, schedules, budget actions, pre-deployment estimates | Tag-policy validation in IaC;[^aws-tag-iac] Cloud Custodian;[^custodian] provider budgets;[^aws-budgets] Infracost[^infracost] |

**Trust boundaries.** Reading billing data (which reveals negotiated rates), buying commitments (multi-year obligations) and
automated remediation (a production change system) are three separate permissions; their controls are in
[Quality, security, privacy and compliance](#quality-security-privacy-and-compliance). **Alternatives:** native tools
(cheapest, fine for one provider at Crawl), a third-party platform (multi-cloud normalisation and workflow for a fee and a data
copy; the Foundation keeps a directory[^landscape]) or a warehouse you build and maintain. Keep allocation rules and KPI definitions
in version-controlled code you own, so you can change tools without changing the numbers.

::: figure Reference architecture for a FinOps data and control plane
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 30}}}%%
flowchart TB
  C1["Control plane: provisioning templates with required tags"] -.->|"metadata at creation"| S1["Sources: billing exports and invoices, cloud (FOCUS), SaaS, licences, data platforms"]
  S2["Sources: Kubernetes allocation data"]
  subgraph data["Data plane"]
    D1["Ingest and normalise to FOCUS"]
    D2["Enrich: owners, products, scopes"]
    D3["Shared-cost and amortisation rules"]
    D4["Semantic layer: KPI and unit-cost definitions, joined with business drivers such as orders"]
  end
  U["Consumers: showback, anomaly tickets, forecasts, chargeback"]
  C2["Control plane: policy as code, schedules, budgets, commitment management"]
  S1 --> D1
  S2 --> D1
  D1 --> D2 --> D3 --> D4
  D4 --> U
  D4 -.->|"findings, baseline usage"| C2
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class D1,D2,D3,D4 core
  class S1,S2,U neutral
  class C1,C2 decision
```
Text equivalent: Templates with required tags put ownership metadata into the sources. Billing exports and invoices (cloud FOCUS,
SaaS, licences, data platforms) and Kubernetes allocation data are normalised to FOCUS, enriched with owners, products and scopes,
processed by shared-cost and amortisation rules, and exposed through a semantic layer of KPI and unit-cost definitions joined with
business drivers. Consumers (showback, anomaly tickets, forecasts, chargeback) read it; its findings and baseline usage drive the
control plane: policy as code, schedules, budgets and commitments.
:::

### End-to-end workflow

One new service, from a back-of-envelope estimate of cost per unit of demand (which the Foundation recommends even at
Crawl)[^cap-unit] to steady state, with the two exception paths teams meet most often.

::: figure One service from estimate to steady state, with the two common exception paths
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 170, "nodeSpacing": 30}}}%%
flowchart TB
  T["New service proposed"] --> E["Estimate unit cost and monthly run rate"]
  E --> PR{{"Ownership tags present at provisioning?"}}
  PR -->|yes| RUN["Running: daily cost, unit cost, anomalies"]
  PR -->|no| X1["Exception A: find the owner from account, name or CMDB"]
  X1 --> X2["Assign or hold centrally by rule; fix the template"]
  X2 --> RUN
  RUN --> F{{"Forecast within budget?"}}
  F -->|yes| OPT["Weekly review: usage optimisation"]
  F -->|no| B2{{"Exception B: can the team optimise the overrun?"}}
  B2 -->|yes| OPT
  B2 -->|no| B3["Request holdback or escalate funding"]
  B3 --> OPT
  OPT --> COM["Stable baseline included in commitment plan"]
  COM --> FB["Unit-cost trend feeds the next estimate and budget"]
  FB -.-> E
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class E,RUN,OPT,COM,FB core
  class X1,X2,B3 risk
  class PR,F,B2 decision
```
Text equivalent: A proposed service gets a unit-cost and run-rate estimate. If tags are missing at provisioning, exception A finds
the owner (account, resource name or CMDB), assigns the cost or holds it centrally by rule, and fixes the template. The running
service shows daily cost, unit cost and anomalies. If the forecast exceeds the budget, exception B optimises the overrun or
requests holdback and escalates. The weekly review optimises usage, the stable baseline enters the commitment plan, and the
unit-cost trend feeds the next estimate.
:::

## Practices, frameworks and tools

### Core practices and playbooks

"Verification" proves that a practice worked, not merely that it ran.

| Practice | Goal | Owner | Output | Verification |
|---|---|---|---|---|
| Allocation and tagging hygiene | Every cost has an owner | FinOps (standard), engineering (tags) | Owner-hunting list; template fixes | Allocated % trend; new untagged spend near zero |
| Shared-cost distribution | Fair, stable split of common costs | FinOps with finance | Written rule per cost pool | Teams can recompute their share |
| [Anomaly triage](#worked-incident-the-weekend-logging-spike-illustrative-runbook) | Catch runaway spend in days | Owning team | Ticket with cause and action | Time to acknowledge; repeats fall |
| Idle clean-up and non-production schedules | Stop paying for nothing | Engineering | Mark, notify, then act | No wrongful deletions |
| [Rightsizing](#playbook-rightsizing-a-service-safely) | Match capacity to need | Engineering | Change with rollback | Unit cost down, SLOs unchanged |
| [Commitment portfolio](#playbook-buying-a-commitment) | Lower rate on stable usage | FinOps (R), finance (A) | Buy, exchange or expire | ESR; nothing stranded |
| Spot adoption | Lower rate for interruptible work | Engineering with FinOps | Spot-ready design | No missed SLOs |
| [Forecast and budget](#forecasting-and-budgeting-in-practice) | Predictable spend | Product and engineering; finance | Re-forecast; variance split | Accuracy within the band |
| Showback and chargeback | Teams see, and if required pay for, their use | FinOps; finance | Reports; ledger entries | Reconciles to invoices |
| Unit economics | Judge spend by value | Product with FinOps | Unit-cost trend per scope | Decisions cite unit cost |
| SaaS and licence reclaim | Remove unused seats | Procurement and ITAM[^cap-licensing] | Reclaim list | Seats paid vs used |
| Pre-deployment estimation | Cost known before build | Engineering | Estimate per unit of demand | Estimate vs first-month actual |

### Playbook: buying a commitment

1. **Prerequisites:** weeks or more of allocated usage history, the migration and re-architecture plan, and a written commitment
   policy (who may buy, maximum term and amount).
2. **Find the floor of the evaluation window.** Plot eligible on-demand-equivalent usage at the instrument's granularity (hourly for
   most, monthly for a monthly-window plan; see [Rates](#3-rates)): the floor, not the average, is what a commitment can reliably
   cover. Use months of hourly billing-export history (AWS's FOCUS 1.2 export offers hourly line items);[^aws-focus] Cost Explorer's
   hourly view covers only the last 14 days and is charged per usage record (as of October 2026).[^aws-ce-pricing]
3. **Subtract planned change** that rightsizing, migration or decommissioning will remove, or a resource-based commitment can go
   idle;[^cap-rate] but do not wait for optimisation to "finish": the Foundation warns that waiting "will almost always lead to
   paying more".[^cap-rate]
4. **Layer flexibility:** the deeper, less flexible option for the most certain base; flexible or shorter options, or on-demand,
   for the uncertain layer ([A judgement call](#a-judgement-call-commit-now-or-wait-for-the-re-architecture)).
5. **Model** coverage, utilisation and ESR at several levels, as in Lab 2, and choose the best *expected* ESR, not the highest
   coverage.
6. **Approve** with different preparer and approver; above an agreed threshold, leadership approves.
7. **Buy in tranches**, so expiry dates are spread.
8. **Verify** utilisation daily for the first weeks; AWS Budgets, for example, can alert when savings plan utilisation or coverage
   drops below a threshold.[^aws-budgets]
9. **Contingency:** steer eligible workloads onto an under-used commitment or let it expire; read exchange and return rules before
   purchase.

### Playbook: rightsizing a service safely

1. Pick candidates from utilisation data over a period that includes peaks such as month end, campaigns and batch windows.
2. Agree the guardrail with the service owner first: which SLOs must not move (see [SRE](../sre/)).
3. Change one dimension at a time (instance size, then count, then storage tier) through the normal change process and
   infrastructure as code.
4. Observe for at least one full business cycle; compare unit cost and SLOs before and after.
5. Roll back if any SLO degrades, and record the lesson so the same recommendation is not raised again.
6. If the resource was covered by a resource-based commitment, tell the FinOps team so it can re-plan coverage.[^cap-rate]

### Forecasting and budgeting in practice

Four decisions shape a forecast and the budget built from it.

**1. Which cost to forecast.** The basis of the budget you are judged against: effective cost for the usual accrual budget; billed
cost, with upfront payments in the month they fall due, for a cash appropriation or treasury planning. FOCUS names exactly these
uses,[^focus-spec] and each commitment's [payment option](#3-rates) decides how far the two diverge.

**2. Which method.** The Foundation's maturity description runs from history-based forecasts (Crawl), through rolling trend models
that include commitment discounts (Walk), to a mix of trend- and driver-based models tracked against amortised usage
(Run).[^cap-forecast] A **trend forecast** extrapolates recent spend: cheap, but blind to launches and campaigns. A **driver-based
forecast** models cost from its causes (*driver volume × unit cost + fixed base + planned changes − planned optimisation ±
commitment effects*), so every line has an owner who can explain it.

::: example Illustrative: a driver-based quarterly forecast for the checkout scope
Checkout costs a fixed 2,000 a month plus 3.60 per 1,000 orders in effective cost. Orders are forecast at 1.55 million in October,
2.40 million in November (a sales campaign) and 1.80 million in December. A feature launch adds 600 a month from November and a
database rightsizing removes 300 a month. In December the team buys a 12-month, all-upfront commitment of 3,600 that replaces
400 a month of on-demand compute with an amortised fee of 300 a month.

| Line | October | November | December |
|---|---|---|---|
| Fixed base | 2,000 | 2,000 | 2,000 |
| Orders × 3.60 per 1,000 | 5,580 | 8,640 | 6,480 |
| Launch (+600) and rightsizing (−300) | – | +300 | +300 |
| **Subtotal before the commitment** | **7,580** | **10,940** | **8,780** |
| Accrual view, added to the subtotal: 300 amortised fee replaces 400 on-demand | – | – | −100 |
| **Effective-cost forecast (accrual budget)** | **7,580** | **10,940** | **8,680** |
| Cash view, added to the subtotal instead: 3,600 paid upfront replaces 400 on-demand | – | – | +3,200 |
| **Billed-cost forecast (cash budget)** | **7,580** | **10,940** | **11,980** |

Both forecasts start from the same subtotal (8,780 − 100 = 8,680; 8,780 + 3,200 = 11,980), so do not add the cash line to the
accrual forecast. The quarter is 27,200 on an accrual basis and 30,500 in cash. A trend forecast such as "last quarter plus 3% a
month" would have missed the November campaign.
:::

**3. How to read a variance.** Split a miss before reacting to it, using the price–volume analysis of management accounting:
*volume variance* = (actual − forecast driver volume) × forecast unit cost, usually good news; *rate variance* = (actual − forecast
unit cost) × actual volume, an engineering or pricing question; *scope variance* = items that were not forecast, or forecast items
that did not happen, a planning question. In the illustration, November's actual is 11,900 against 10,940 (+960, +8.8%). Orders of
2.55 million instead of 2.40 give (2,550 − 2,400) thousand × 3.60 = +540; a unit cost of 3.70 per 1,000 orders instead of 3.60 gives
(3.70 − 3.60) × 2,550 thousand = +255; an unplanned load-test environment adds +165. Only the last two need action; the first is
the growth the budget was meant to fund.

**4. Holdback and escalation.** The Budgeting capability gives budget owners a **holdback**, money "not allocated to a specific
purpose" that absorbs changes, overages and forecast errors; an expected overrun is investigated and optimised first, then covered
from holdback, then escalated to a higher budget owner, finance and leadership.[^cap-budget] Size holdback to the forecast error you
actually have (as this Atlas's starting point, a scope that usually misses by about 6% needs roughly 6%; the Foundation expects
dynamic scopes to need more), and reclaim it when unused, because it "could have been used to invest in other areas".[^cap-budget]

### Methods, standards and frameworks

Separate what binds you from what guides you. **Normative:** the FOCUS specification, with MUST/SHOULD requirements for data
generators (for you, a target schema),[^focus-spec] and the OpenCost specification for Kubernetes cost allocation.[^opencost-spec]
**Guidance:** the FinOps Framework, "flexible and non-prescriptive",[^fin-fw] and the providers' well-architected cost
guidance.[^aws-wa][^az-waf][^gcp-waf] **Binding and local:** accounting standards and company policy on capitalisation, amortisation,
accruals and transfer pricing (involve finance and tax; this page gives no accounting advice). **Intersecting:** ITFM/TBM, ITAM/SAM
and ITSM.[^fin-personas][^fin-2026]

### Tooling landscape

Think in **jobs to be done** first, brands second. Commercial platforms are not compared: their features and prices change faster
than this page can re-verify them.

| Category | Representative verified options (as of October 2026) | Strengths | Limits |
|---|---|---|---|
| Provider-native consoles | AWS Cost Explorer, Budgets, Cost Anomaly Detection;[^aws-budgets][^aws-anom] Azure Cost Management;[^az-focus] Google Cloud Billing[^gcp-bq] | No extra cost or data copy | One provider each; limited allocation |
| Exports plus a warehouse | FOCUS exports from AWS, Azure, Google Cloud[^aws-focus][^az-focus][^gcp-bq] | Full control; joins with business data | You build and run it |
| Kubernetes allocation | OpenCost[^opencost-docs] | `max(request, usage)`; visible idle cost | Needs metrics plumbing |
| Policy as code | Cloud Custodian[^custodian] | Multi-cloud YAML; mark-then-act | Can break production |
| Pre-deployment estimation | Infracost (Apache-2.0)[^infracost] | Estimates in pull requests | Depends on assumed usage |
| Starter kits | Microsoft FinOps toolkit (MIT)[^ms-toolkit] | Fast, FOCUS-aligned start | Azure-centred |
| Platforms and services | The Foundation's landscape directory;[^landscape] commitment management as a service[^cap-rate] | Breadth, workflow | Fees, data copy, rule lock-in |

**FOCUS versions by data generator (dated).** This listing changes often; re-check it at least quarterly.

| Data generator | FOCUS version listed on focus.finops.org (2026-10-16)[^focus-home] |
|---|---|
| AWS, Microsoft (Azure), Google Cloud, IBM Cloud, Grafana Cloud, Redis, STACKIT, Nebius | 1.2 |
| Snowflake, Databricks, MongoDB, Vercel | 1.3 |
| Oracle, Alibaba Cloud, Tencent Cloud, Huawei Cloud, OVHcloud, Cloudflare, CoreWeave | 1.0 |

**Selection criteria:** data portability (FOCUS exports to storage you own, or your allocation rules live in someone else's
product); allocation power; latency and invoice reconciliation; access control by scope; workflow integration; automation
guardrails; total cost, including people.

### Automation and AI

**Automate the repetitive and the reversible; keep humans on the irreversible.**

| Automate fully | Automate with a grace period and notification | Keep a human decision |
|---|---|---|
| Ingestion, allocation, KPI calculation | Stopping non-compliant non-production resources (Custodian's `mark-for-op`)[^custodian] | Buying, exchanging or letting commitments expire |
| Anomaly detection and routing | Deleting unattached storage after a snapshot-policy check | Deleting production data |
| Tag defaults in IaC modules | Budget actions that restrict provisioning, such as applying an IAM policy[^aws-budgets] | Changing shared-cost or chargeback rules |
| Weekly owner reports | Rightsizing in non-production | Rightsizing in production |

**Machine learning.** ML-based anomaly detection is now typical,[^cap-anom] but billing-based detection is slow: AWS Cost Anomaly
Detection can take up to 24 hours and needs 10 days of history for a new service,[^aws-anom] so runaway jobs also need usage-level
alerts. **Large language models.** The 2026 survey describes a dual agenda: managing AI spend and applying AI to FinOps
work.[^sof-2026] Natural-language cost queries help, but a wrong join produces a confident wrong answer: keep generated SQL visible,
route answers through the governed semantic layer, and never let a model buy commitments or delete resources. AI economics belong
to [FinOps for AI](../finops-for-ai/).

## FinOps in practice: artefacts, labs and use cases

Artefacts, then three labs and three scenarios. Labs 1 and 2 need only Python 3.8 or later on a laptop; Lab 3 needs a sandbox
cloud account and is **untested** here.

### Reference implementation: artefacts you can reuse

**Assumptions (illustrative organisation).** "Example Co." has about 40 product teams, mostly on one public cloud (AWS here), one
shared Kubernetes platform and a few large SaaS products; a FinOps team of two works with a finance partner towards Walk-level
allocation, monthly showback, a managed commitment portfolio and one unit metric per product. All values are fake.

#### 1. Tagging and ownership standard

A policy document kept in version control. The schema is this Atlas's own and no tool reads it directly; provider tag policies,
IaC defaults and Custodian rules are generated from it or checked against it.

_Example status: YAML syntax-checked; illustrative schema, not tied to a specific tool._

```yaml
# finops/tagging-standard.yaml  (owner: FinOps team; review: quarterly)
version: 3
required_keys:
  team:
    description: Accountable engineering team (must exist in the team catalogue)
    example: checkout
  cost-center:
    description: Finance cost centre that funds the resource (Example Co. cost centres are 4xxx)
    pattern: "^4[0-9]{3}$"   # the AWS tag policy below allows the same range with "4*"
    example: "4410"
  env:
    allowed: [prod, staging, dev, sandbox]
optional_keys:
  product: { description: Customer-facing product or scope name }
  expires-on: { description: "Deletion date for temporary resources (YYYY-MM-DD)" }
enforcement:
  at_provisioning: required_keys must be present in IaC modules and templates
  detection_sla_hours: 24
  untagged_spend_owner: platform-team   # holds untagged cost until an owner is found
shared_cost_pools:
  - name: enterprise-support
    rule: hold-centrally            # "informed ignore" for year one
  - name: kubernetes-platform
    rule: proportional-to-requests  # namespace share of max(request, usage)
  - name: network-egress-shared
    rule: proportional-to-direct-cost
```

On shared Kubernetes clusters, put the same keys on each namespace as labels (`team`, `cost-center`, `env`); the namespace is the
natural allocation unit. OpenCost, for example, copies namespace labels onto each workload's allocation (a pod label with the same
key wins), and its allocation API aggregates by `namespace` or by `label:<name>`.[^opencost-api]

#### 2. Provider tag policy (AWS Organizations example)

AWS Organizations tag policies standardise tag keys and allowed values across accounts, but a plain key definition does not make a
tag mandatory: "Untagged resources or tags that aren't defined in the tag policy aren't evaluated for compliance with the tag
policy".[^aws-tagpol] Since November 2025 a policy can also mark keys as **required** (`report_required_tag_for`), and IaC
deployments can be validated against them before resources exist: by an AWS-managed CloudFormation hook, activated in each
account and Region, in warn or fail mode (fail blocks the deployment); by the Terraform AWS provider from version 6.22.0; and by a
Pulumi policy pack.[^aws-tag-iac] Two gaps remain as of
October 2026. Compliance reports cover only resources that have carried at least one user-defined tag, so never-tagged resources
do not appear as non-compliant;[^aws-tag-iac] query Q2 finds their cost. And creation outside IaC is not validated: there, IAM or
service control policies with `aws:RequestTag/<key>` conditions can deny untagged create requests, action by action.[^aws-require-tags]
The separate `enforced_for` option blocks non-compliant *tagging operations*, and AWS advises changing it only if you are
experienced with tag policies.[^aws-tagpol] Rolling these guardrails out across accounts is [CloudOps](../cloudops/) work. The policy
below standardises all three keys and marks `team` and `cost-center` as required for EC2.

_Example status: JSON syntax-checked; adapted from the AWS documentation examples (tag policy syntax and required-tag reporting); not
applied to a real organisation._

```json
{
  "tags": {
    "team": {
      "tag_key": { "@@assign": "team" },
      "report_required_tag_for": { "@@assign": ["ec2:ALL_SUPPORTED"] }
    },
    "env": {
      "tag_key": { "@@assign": "env" },
      "tag_value": { "@@assign": ["prod", "staging", "dev", "sandbox"] }
    },
    "cost-center": {
      "tag_key": { "@@assign": "cost-center" },
      "tag_value": { "@@assign": ["4*"] },
      "report_required_tag_for": { "@@assign": ["ec2:ALL_SUPPORTED"] }
    }
  }
}
```

Then **activate** the keys as cost allocation tags, or they will not appear in billing data (see [ownership metadata](#2-ownership-metadata)).

#### 3. Policy as code: detect, mark, then act (Cloud Custodian)

These policies adapt Cloud Custodian's tag-compliance example[^custodian] and catch what IaC validation cannot: resources created
by hand. One marks non-production instances (`env` is dev, staging or sandbox, outside Auto Scaling groups) that lack ownership tags
and schedules a stop in three days; one removes the mark once the tags are fixed; one stops what is still non-compliant. All share
the same scope filters and a dedicated mark tag, `c7n_ownership`, so they never touch other policies' marks. Use the same shape for
unattached volumes only after confirming your snapshot and retention policy: deleting a volume deletes its data.

_Example status: YAML syntax-checked; not executed and not validated with `custodian validate` (Cloud Custodian was not installed in this
environment). Run in a sandbox with `--dryrun` first (see Lab 3)._

```yaml
policies:
  - name: ec2-nonprod-ownership-mark
    resource: ec2
    comment: |
      Non-production instances outside Auto Scaling groups that lack ownership
      tags are marked to be stopped in 3 days. Notify owners from this report.
    filters:
      - "tag:aws:autoscaling:groupName": absent
      - {type: value, key: "tag:env", op: in, value: [dev, staging, sandbox]}
      - "tag:c7n_ownership": absent
      - or:
          - "tag:team": absent
          - "tag:cost-center": absent
    actions:
      - type: mark-for-op
        tag: c7n_ownership
        op: stop
        days: 3

  - name: ec2-nonprod-ownership-unmark
    resource: ec2
    comment: Remove this policy's mark once both ownership tags are present.
    filters:
      - "tag:aws:autoscaling:groupName": absent
      - {type: value, key: "tag:env", op: in, value: [dev, staging, sandbox]}
      - "tag:c7n_ownership": not-null
      - "tag:team": not-null
      - "tag:cost-center": not-null
    actions:
      - type: remove-tag
        tags: [c7n_ownership]

  - name: ec2-nonprod-ownership-stop
    resource: ec2
    comment: Stop instances whose grace period has expired and that are still non-compliant.
    filters:
      - "tag:aws:autoscaling:groupName": absent
      - {type: value, key: "tag:env", op: in, value: [dev, staging, sandbox]}
      - type: marked-for-op
        tag: c7n_ownership
        op: stop
      - or:
          - "tag:team": absent
          - "tag:cost-center": absent
    actions:
      - stop
```

#### 4. FOCUS queries for the monthly review

These queries run against a table `focus` of FOCUS cost and usage rows, in SQLite so that Lab 1 can run them; adjust the `Tags`
JSON access for your engine (BigQuery uses `JSON_VALUE`, Trino `json_extract_scalar`).[^sql-json] Every column used is defined in
FOCUS 1.2, the version listed for AWS, Microsoft and Google Cloud in October 2026,[^focus-home] so the queries serve all three
providers' exports. Check what yours fills in: `SubAccountId`, `ResourceId`, `Tags`, `CommitmentDiscountId` and
`CommitmentDiscountStatus` are conditional columns, and `InvoiceId`, added in 1.2, is only recommended.[^focus-v12]

_Example status: verified by execution on 2026-10-16 against the Lab 1 sample data (SQLite 3.31.1); results below._

```sql
-- Q1. Allocation coverage for one month: share of effective cost that carries a team tag, excluding tax and credits.
SELECT
  ROUND(100.0 * SUM(CASE WHEN json_extract(Tags, '$.team') IS NOT NULL THEN EffectiveCost ELSE 0 END)
        / SUM(EffectiveCost), 1) AS pct_tagged,
  ROUND(SUM(EffectiveCost), 2)   AS effective_cost
FROM focus
WHERE ChargePeriodStart >= '2026-09-01' AND ChargePeriodStart < '2026-10-01'
  AND ChargeCategory NOT IN ('Tax', 'Credit');

-- Q2. Owner-hunting list for the month: the most expensive resources without a team tag.
SELECT SubAccountId, ServiceName, ResourceId, ROUND(SUM(EffectiveCost), 2) AS effective_cost
FROM focus
WHERE ChargePeriodStart >= '2026-09-01' AND ChargePeriodStart < '2026-10-01'
  AND json_extract(Tags, '$.team') IS NULL
  AND ChargeCategory = 'Usage' AND ResourceId <> ''
  AND COALESCE(CommitmentDiscountStatus, '') <> 'Unused'
GROUP BY SubAccountId, ServiceName, ResourceId
ORDER BY effective_cost DESC
LIMIT 20;

-- Q3. Unused commitment in the month: the cost of commitments that covered nothing.
SELECT ROUND(SUM(EffectiveCost), 2) AS unused_commitment_cost
FROM focus
WHERE ChargePeriodStart >= '2026-09-01' AND ChargePeriodStart < '2026-10-01'
  AND CommitmentDiscountStatus = 'Unused';

-- Q4. Savings against list price per team in the month (Usage rows only, so purchases are not counted twice).
SELECT json_extract(Tags, '$.team') AS team,
       ROUND(SUM(ListCost), 2)      AS list_cost,
       ROUND(SUM(EffectiveCost), 2) AS effective_cost,
       ROUND(100.0 * (SUM(ListCost) - SUM(EffectiveCost)) / SUM(ListCost), 1) AS pct_saved
FROM focus
WHERE ChargePeriodStart >= '2026-09-01' AND ChargePeriodStart < '2026-10-01'
  AND ChargeCategory = 'Usage' AND json_extract(Tags, '$.team') IS NOT NULL
GROUP BY team
ORDER BY effective_cost DESC;

-- Q5a. Monthly reconciliation: billed cost per invoice, to compare with each invoice's payable amount.
SELECT InvoiceId, ROUND(SUM(BilledCost), 2) AS billed
FROM focus
GROUP BY InvoiceId;

-- Q5b. Commitment reconciliation: billed purchase cost against recognised effective cost (covered plus
-- unused) over the commitment's whole term. One month suffices only for a commitment billed monthly.
SELECT CommitmentDiscountId,
       ROUND(SUM(CASE WHEN ChargeCategory = 'Purchase' THEN BilledCost ELSE 0 END), 2) AS billed_purchase,
       ROUND(SUM(CASE WHEN ChargeCategory = 'Usage' THEN EffectiveCost ELSE 0 END), 2)  AS recognised
FROM focus
WHERE CommitmentDiscountId <> ''
GROUP BY CommitmentDiscountId;
```

On the Lab 1 data these return: Q1 89.0% of 11,800.00; Q2 one resource (`bucket-app-logs`, 600.00); Q3 200.00; Q4 checkout saved
21.8% against list, platform and search 0%; Q5a 11,950.00 for invoice `INV-2026-09`, matching its payable amount; Q5b 2,000.00
billed and 2,000.00 recognised for `cd-001`. With several invoicing parties, also group Q5a by `InvoiceIssuerName`.

#### 5. Provider API pulls for the commitment review (AWS CLI)

The Foundation's ESR guide uses the Cost Explorer API in the same way;[^esr] the options match the AWS CLI reference.[^aws-cli-ce]

_Example status: shell syntax-checked (`bash -n`); not executed (requires AWS credentials with Cost Explorer read permissions; AWS
charges per Cost Explorer API request, $0.01 per request on the primary billing view as of October 2026)._[^aws-ce-pricing]

```bash
#!/usr/bin/env bash
set -euo pipefail
START=2026-09-01
END=2026-10-01   # the end date is exclusive

# Amortised cost for the month, grouped by the activated "team" cost allocation tag
aws ce get-cost-and-usage \
  --time-period "Start=${START},End=${END}" \
  --granularity MONTHLY \
  --metrics AmortizedCost \
  --group-by Type=TAG,Key=team \
  --output json > "cost-by-team-${START}.json"

# Savings Plans utilisation and coverage for the same month
aws ce get-savings-plans-utilization \
  --time-period "Start=${START},End=${END}" \
  --granularity MONTHLY \
  --output json > "sp-utilization-${START}.json"

aws ce get-savings-plans-coverage \
  --time-period "Start=${START},End=${END}" \
  --granularity MONTHLY \
  --output json > "sp-coverage-${START}.json"
```

#### 6. Monthly showback SOP (operating artefact)

1. **Month end + 1, FinOps:** freeze allocation rules for the month and record the rule version.
2. **+ 2, FinOps:** send finance an accrual estimate from allocated effective cost, with a confidence band.
3. **When invoices arrive (often + 3 to + 12),[^cap-chargeback] finance and FinOps:** reconcile billed cost to each invoice (Q5a)
   and investigate differences above tolerance.
4. **+ 10, FinOps:** apply shared-cost rules; publish showback and unit cost.
5. **+ 12, engineering leads:** give every variance above threshold an owner and an action.
6. **+ 15, finance and FinOps:** post chargeback if policy requires it; true up accruals; update the scorecard and forecast.

### Lab 1 (beginner): allocate a month of FOCUS-shaped cost data

**Objective.** Reconcile billed cost to the invoice and the commitment, measure allocation coverage, find unowned spend, and
produce showback and a unit cost. **Prerequisites.** Python 3.8 or later, standard library only, with `json_extract` available in
its `sqlite3` (built into SQLite from 3.38.0, an optional extension before).[^sql-json] **Cost and risk.** None; all local.
**Data.** Thirteen illustrative FOCUS-shaped rows for one month and one invoice, including commitment `cd-001`: its purchase
(billed 2,000, effective 0), the usage it covered (billed 0, effective 1,800) and its unused remainder (effective 200). It is
**billed monthly with no upfront payment**, the only reason the month's billed and effective totals match here.

_Example status: verified by execution on 2026-10-16 (Python 3.8.10, SQLite 3.31.1). Data is illustrative._

Save this as `focus_sample.csv`:

```csv
ChargePeriodStart,ChargeCategory,ServiceName,SubAccountId,ResourceId,Tags,BilledCost,EffectiveCost,ListCost,CommitmentDiscountStatus,CommitmentDiscountId,InvoiceId
2026-09-01,Usage,Virtual Machines,acct-prod,vm-checkout-01,"{""team"":""checkout"",""env"":""prod""}",0,1800,3000,Used,cd-001,INV-2026-09
2026-09-01,Usage,Virtual Machines,acct-prod,vm-search-01,"{""team"":""search"",""env"":""prod""}",1200,1200,1200,,,INV-2026-09
2026-09-01,Usage,Managed Database,acct-prod,db-checkout-01,"{""team"":""checkout"",""env"":""prod""}",2500,2500,2500,,,INV-2026-09
2026-09-01,Usage,Object Storage,acct-prod,bucket-app-logs,{},600,600,600,,,INV-2026-09
2026-09-01,Usage,Virtual Machines,acct-dev,vm-search-dev-01,"{""team"":""search"",""env"":""dev""}",900,900,900,,,INV-2026-09
2026-09-01,Usage,Kubernetes,acct-shared,cluster-a,"{""team"":""platform"",""env"":""prod""}",3000,3000,3000,,,INV-2026-09
2026-09-01,Usage,NAT Gateway,acct-shared,nat-a,"{""team"":""platform"",""env"":""prod""}",700,700,700,,,INV-2026-09
2026-09-01,Usage,Generative AI API,acct-prod,genai-search,"{""team"":""search"",""env"":""prod""}",400,400,400,,,INV-2026-09
2026-09-01,Purchase,Compute Commitment,acct-payer,cd-001,{},2000,0,0,,cd-001,INV-2026-09
2026-09-01,Usage,Compute Commitment,acct-payer,cd-001,{},0,200,0,Unused,cd-001,INV-2026-09
2026-09-01,Usage,Enterprise Support,acct-payer,,{},500,500,500,,,INV-2026-09
2026-09-01,Credit,Promotional Credit,acct-payer,,{},-300,-300,-300,,,INV-2026-09
2026-09-01,Tax,Sales Tax,acct-payer,,{},450,450,450,,,INV-2026-09
```

Save this as `lab1_allocate.py`:

```python
"""Lab 1: allocate one month of FOCUS-shaped cost data (Python 3.8+ standard library only)."""
import csv
import sqlite3
import sys

INVOICES = {"INV-2026-09": 11_950.00}   # payable amount printed on the provider's invoice (illustrative)
ORDERS = {"checkout": 1_250_000}         # business driver for the unit metric (illustrative)

db = sqlite3.connect(":memory:")
db.execute("""CREATE TABLE focus (ChargePeriodStart TEXT, ChargeCategory TEXT, ServiceName TEXT,
  SubAccountId TEXT, ResourceId TEXT, Tags TEXT, BilledCost REAL, EffectiveCost REAL, ListCost REAL,
  CommitmentDiscountStatus TEXT, CommitmentDiscountId TEXT, InvoiceId TEXT)""")
with open(sys.argv[1] if len(sys.argv) > 1 else "focus_sample.csv", newline="") as f:
    db.executemany("INSERT INTO focus VALUES (?,?,?,?,?,?,?,?,?,?,?,?)",
                   [tuple(r.values()) for r in csv.DictReader(f)])

# 1a. Monthly check: billed cost per invoice must equal the invoice's payable amount.
for invoice, billed in db.execute("SELECT InvoiceId, SUM(BilledCost) FROM focus GROUP BY InvoiceId"):
    print(f"Invoice {invoice}: billed {billed:,.2f} | payable {INVOICES[invoice]:,.2f}")
    assert abs(billed - INVOICES[invoice]) < 0.01, f"{invoice}: billed cost does not match the invoice"
# 1b. Commitment check: what was billed for the purchase must equal the effective cost it covered plus its
#     unused part. One month is enough here only because this commitment is billed monthly (no upfront).
for cid, bought, recognised in db.execute("""SELECT CommitmentDiscountId,
        SUM(CASE WHEN ChargeCategory = 'Purchase' THEN BilledCost ELSE 0 END),
        SUM(CASE WHEN ChargeCategory = 'Usage' THEN EffectiveCost ELSE 0 END)
        FROM focus WHERE CommitmentDiscountId <> '' GROUP BY CommitmentDiscountId"""):
    print(f"Commitment {cid}: billed {bought:,.2f} | recognised (covered + unused) {recognised:,.2f}")
    assert abs(bought - recognised) < 0.01, f"{cid}: covering and covered charges do not balance"
effective = db.execute("SELECT SUM(EffectiveCost) FROM focus").fetchone()[0]

# 2. Put every unit of effective cost into exactly one allocation bucket.
BUCKET_SQL = """
  CASE
    WHEN ChargeCategory IN ('Tax', 'Credit')            THEN 'spread: tax and credits'
    WHEN json_extract(Tags, '$.team') IN ('platform')    THEN 'spread: shared platform'
    WHEN json_extract(Tags, '$.team') IS NOT NULL        THEN 'direct'
    WHEN ResourceId IN ('', CommitmentDiscountId)       THEN 'central by policy'
    ELSE 'unallocated: needs an owner'
  END"""
buckets = dict(db.execute(f"SELECT {BUCKET_SQL} AS bucket, ROUND(SUM(EffectiveCost), 2) FROM focus "
                          "GROUP BY bucket ORDER BY bucket").fetchall())
for name, cost in buckets.items():
    print(f"  {name:30s} {cost:10,.2f}")
base = effective - buckets.get("spread: tax and credits", 0)
direct, shared = buckets["direct"], buckets["spread: shared platform"]
print(f"Directly tagged:          {direct / base:6.1%} of {base:,.2f}")
print(f"Allocated after sharing:  {(direct + shared) / base:6.1%}")
print(f"Unallocated (no owner):   {buckets['unallocated: needs an owner'] / base:6.1%}")

# 3. The owner-hunting list: resources with cost but no team tag.
for rid, svc, acct, cost in db.execute(f"""SELECT ResourceId, ServiceName, SubAccountId, EffectiveCost FROM focus
                                        WHERE {BUCKET_SQL} = 'unallocated: needs an owner'
                                        ORDER BY EffectiveCost DESC"""):
    print(f"  untagged: {rid} ({svc}, {acct}) {cost:,.2f}")

# 4. Showback: direct cost per team plus a proportional share of the spread pools.
teams = dict(db.execute(f"""SELECT json_extract(Tags, '$.team'), SUM(EffectiveCost) FROM focus
                            WHERE {BUCKET_SQL} = 'direct' GROUP BY 1 ORDER BY 1""").fetchall())
spread = shared + buckets.get("spread: tax and credits", 0)
for team, cost in teams.items():
    share = spread * cost / direct
    line = f"  {team:9s} direct {cost:9,.2f} + shared {share:8,.2f} = showback {cost + share:9,.2f}"
    if team in ORDERS:
        line += f" | {1000 * (cost + share) / ORDERS[team]:.2f} per 1,000 orders"
    print(line)
print(f"  held centrally (support, unused commitment): {buckets['central by policy']:,.2f}")
```

**Steps.** Save both files in an empty folder, run `python3 lab1_allocate.py focus_sample.csv`, and compare with the expected
output.

**Expected output** (actual output of the run on 2026-10-16):

```text
Invoice INV-2026-09: billed 11,950.00 | payable 11,950.00
Commitment cd-001: billed 2,000.00 | recognised (covered + unused) 2,000.00
  central by policy                  700.00
  direct                           6,800.00
  spread: shared platform          3,700.00
  spread: tax and credits            150.00
  unallocated: needs an owner        600.00
Directly tagged:           57.6% of 11,800.00
Allocated after sharing:   89.0%
Unallocated (no owner):     5.1%
  untagged: bucket-app-logs (Object Storage, acct-prod) 600.00
  checkout  direct  4,300.00 + shared 2,434.56 = showback  6,734.56 | 5.39 per 1,000 orders
  search    direct  2,500.00 + shared 1,415.44 = showback  3,915.44
  held centrally (support, unused commitment): 700.00
```

**Validation.** (a) Both checks pass because every billed row, and the purchase with its covered and unused parts, are in this
month. (b) Product-team tags cover 57.6% of spend; once the tagged but shared platform pool is spread, 89.0% is allocated (Q1's
figure), between the Foundation's Walk (at least 85%) and Run (above 90%) sample goals.[^fin-maturity] (c) Only the log bucket
(5.1%) truly lacks an owner; support and unused commitment are held centrally *by policy*, which is not *unknown*. (d) Checkout
costs 5.39 per 1,000 orders.

**Variant: all upfront.** Change the purchase row's `BilledCost` to 24000 (12 months paid upfront, 2,000 recognised this month) and
the payable amount in `INVOICES` to 33950. The invoice check passes; the commitment check stops with
`AssertionError: cd-001: covering and covered charges do not balance` (billed 24,000.00, recognised 2,000.00). That is correct:
billed (33,950) and effective (11,950) totals differ in every month of the term, so run the commitment check over the whole term.

**Troubleshooting.** `no such function: json_extract`: use a Python build with a newer SQLite. An `AssertionError` on the invoice
check: billed rows are missing or the payable amount is wrong; on the commitment check: a covering or covered row is missing, or
the term spans months not in the file. **Teardown.** Delete the folder.

### Lab 2 (intermediate): size a commitment with a what-if model

**Objective.** See why, for a commitment evaluated hour by hour, the hourly floor rather than the average sets the best level, and
why coverage alone misleads. **Prerequisites.** Python 3.8 or later. **Assumptions.** A spend-based commitment at an assumed 30%
discount whose unused hourly amount is lost (as for AWS Savings Plans, Azure savings plans and standard Google spend-based CUDs,
not Google's monthly-window Flexible Savings Plans; see [Rates](#3-rates)); usage of 100 per hour in weekday business hours and 40
otherwise. All prices are illustrative.

_Example status: verified by execution on 2026-10-16 (Python 3.8.10)._

```python
"""Lab 2: what-if model for a spend-based commitment (Python 3.8+ standard library only).

All prices are illustrative. A spend-based commitment of C per hour (billed at the discounted rate)
covers up to C / (1 - DISCOUNT) of on-demand-equivalent (ODE) usage in that hour; unused commitment
in an hour is lost, and usage above the covered amount is billed at on-demand rates.
"""
DISCOUNT = 0.30          # assumed discount of the commitment rate versus on-demand
HOURS_PER_WEEK = 168

def weekly_profile():
    """ODE spend per hour: 100/h in weekday business hours (09-18), 40/h otherwise."""
    usage = []
    for hour in range(HOURS_PER_WEEK):
        day, hod = divmod(hour, 24)
        usage.append(100.0 if day < 5 and 9 <= hod < 18 else 40.0)
    return usage

def evaluate(commit_per_hour, usage):
    capacity = commit_per_hour / (1 - DISCOUNT)              # ODE that one hour of commitment can cover
    covered = sum(min(u, capacity) for u in usage)
    ode = sum(usage)
    cost = commit_per_hour * len(usage) + (ode - covered)    # commitment fee + uncovered on-demand usage
    used_fee = covered * (1 - DISCOUNT)
    return {
        "coverage": covered / ode,
        "utilization": used_fee / (commit_per_hour * len(usage)) if commit_per_hour else 0.0,
        "cost": cost,
        "esr": (ode - cost) / ode,                               # effective savings rate
    }

usage = weekly_profile()
print(f"Weekly ODE spend {sum(usage):,.0f}; min {min(usage):.0f}/h, max {max(usage):.0f}/h")
print(f"{'commit/h':>8} {'coverage':>9} {'utiliz.':>8} {'weekly cost':>12} {'ESR':>7}")
for c in (0, 14, 28, 35, 42, 56, 70):
    r = evaluate(c, usage)
    print(f"{c:8.0f} {r['coverage']:9.1%} {r['utilization']:8.1%} {r['cost']:12,.0f} {r['esr']:7.1%}")
best = max(range(0, 71), key=lambda c: evaluate(c, usage)["esr"])
print(f"Best whole-number commitment for this profile: {best}/h (ESR {evaluate(best, usage)['esr']:.1%})")
```

**Expected output** (actual output of the run on 2026-10-16):

```text
Weekly ODE spend 9,420; min 40/h, max 100/h
commit/h  coverage  utiliz.  weekly cost     ESR
       0      0.0%     0.0%        9,420    0.0%
      14     35.7%   100.0%        8,412   10.7%
      28     71.3%   100.0%        7,404   21.4%
      35     76.1%    85.4%        8,130   13.7%
      42     80.9%    75.6%        8,856    6.0%
      56     90.4%    63.4%       10,308   -9.4%
      70    100.0%    56.1%       11,760  -24.8%
Best whole-number commitment for this profile: 28/h (ESR 21.4%)
```

**Validation.** (a) The best commitment, 28 per hour, is the floor of 40 per hour × (1 − 0.30); below it, utilisation stays at 100%.
(b) At 42 per hour coverage rises to 80.9%, meeting the "coverage above 80" Run sample goal,[^fin-maturity] yet ESR falls from 21.4%
to 6.0%. (c) At 56 per hour the organisation pays **more** than on-demand (ESR −9.4%).

::: figure Lab 2 as a chart: coverage keeps rising after the floor, while the effective savings rate falls
```mermaid
%%{init: {"xyChart": {"width": 460, "height": 360}, "themeVariables": {"xyChart": {"plotColorPalette": "#16756f, #b4332b"}}}}%%
xychart-beta
  title "Upper line: coverage. Lower line: ESR"
  x-axis "Commitment per hour" 0 --> 70
  y-axis "Per cent" -30 --> 100
  line [0, 17.8, 35.7, 53.5, 71.3, 76.1, 80.9, 85.7, 90.4, 95.2, 100]
  line [0, 5.4, 10.7, 16.1, 21.4, 13.7, 6.0, -1.7, -9.4, -17.1, -24.8]
```
Text equivalent: A line chart from Lab 2's model at commitments of 0 to 70 per hour, in steps of 7. The upper line, coverage, rises
steeply to 71.3% at 28 per hour, then more slowly to 100% at 70. The lower line, effective savings rate, peaks at 21.4% at 28 per
hour, then falls to 6.0% at 42, about −1.7% at 49 and −24.8% at 70. Utilisation, not plotted, is 100% up to 28 per hour and 56.1% at 70.
:::

**An important subtlety.** The Foundation's ESR guide gives a primary definition (savings ÷ on-demand-equivalent spend) and a
shortcut (utilisation × coverage × discount).[^esr] At 100% utilisation they agree (1.000 × 0.713 × 0.30 ≈ 21.4%). At 42 per hour the
shortcut gives 0.756 × 0.809 × 0.30 ≈ 18.3%, but the primary definition, which subtracts the unused commitment, gives 6.0%. Report the
primary definition; use the shortcut only as a check near 100% utilisation.

**Troubleshooting.** Daily rather than hourly usage data hides intra-day dips, so the model would overstate what a commitment can
cover; size from hourly billing-export data. **Teardown.** None.

### Lab 3 (advanced): enforce ownership tags with policy-as-code, safely

**Objective.** Run the mark-then-act policies in **dry-run** mode and see which resources they would touch. **Prerequisites.** A
*sandbox* AWS account (never production) with a role that can read EC2 and create tags; Python 3; about an hour. **Cost and risk.**
One small instance for under an hour costs little but is not free; a run without dry-run can stop instances.

_Example status: **untested** in this environment. Commands are taken from Cloud Custodian's documentation.[^custodian]_

1. Install Custodian in a virtual environment: `python3 -m venv custodian`, `source custodian/bin/activate`, `pip install c7n`.
2. Save the three policies from artefact 3 of the [reference implementation](#reference-implementation-artefacts-you-can-reuse) as
   `custodian.yml` and run `custodian validate custodian.yml`. Expected: no errors.
3. In the sandbox, launch one small instance tagged `env=dev` and **without** `team` or `cost-center` tags.
4. Dry run: `custodian run --dryrun -s out custodian.yml`. **Expected output:** a log line such as
   `policy:ec2-nonprod-ownership-mark resource:ec2 region:<region> count:1 time:<seconds>`, the form Custodian's pull mode
   logs,[^c7n-log] and a directory per policy under `out/` containing `resources.json`; no tag is added and nothing stops.
5. Add `team=lab` and `cost-center=4999` to the instance and dry-run again. Expected: the mark policy now matches nothing.

**Validation.** Explain why the stop policy re-checks the tags before acting: an owner may have fixed them during the grace period.
**Troubleshooting.** No matches: check the region and the exact, case-sensitive tag spelling. Access denied: the role needs EC2
describe permissions. **Teardown.** Terminate the instance, and delete `out/` and the virtual environment.

### Use cases and scenarios

All three scenarios are **illustrative** composites, not case studies.

**A. SaaS company: pricing from unit cost.** A product team cannot tell whether its "Starter" tier makes money. FinOps tags cluster
workloads by service, the platform emits requests per tenant (the denominator the Foundation recommends instrumenting
early),[^cap-unit] and shared database cost is split by queries per tenant, a proxy. **Trade-off:** precision against effort; a
proxy nobody trusts is worse than none. **Success:** pricing decisions cite cost per tenant by tier.

**B. Migrating out of a data centre.** Spend rises during an 18-month migration because old and new estates run in parallel. A
*migration scope* keeps this temporary cost from being mistaken for waste,[^fin-scopes] and the dual running is budgeted explicitly.
Commitments follow the migration in tranches: commit now to usage that already runs consistently in the cloud, and add a tranche
as each wave is rightsized ([commitment playbook](#playbook-buying-a-commitment)). **Trade-off:** three-year commitments sized to the
*pre-optimisation* footprint are the classic mistake, because rightsizing afterwards can leave you paying "for resources that no
longer exist in their original form".[^cap-rate] **Success:** forecast variance within the band, nothing stranded.

**C. A public body with fixed annual funding.** The risk is exceeding a cash appropriation, not missing a discount, so the practice
forecasts **billed** cost, puts budget alerts and holdback first, and follows the jurisdiction's rules for multi-year commitments.
**Trade-off:** strict controls can slow delivery. **Success:** no breach, monthly variance explanations, a documented rationale for
every multi-year commitment.

## Measure, govern and pay

### Metrics and KPIs

Measure a few things well. The Foundation's community sample goals for allocation, commitment coverage and forecast variance are
conversation starters, not targets to copy.[^fin-maturity]

| KPI | Formula and data source | Pitfall | Cadence |
|---|---|---|---|
| Allocation coverage | Allocated ÷ total effective cost (state whether tax and credits count) | Counting tagged resources, not tagged cost | Monthly |
| Unallocated cost | Effective cost with no owner after rules ÷ total | Hiding unknowns in a "shared" pool | Monthly |
| Unit cost | Scope cost ÷ a business or technical driver | Changing the denominator without restating history | Monthly |
| Forecast variance | (Actual − forecast) ÷ forecast per scope, on the budget's cost basis; the Foundation's accuracy rate uses forecast − actual,[^cap-forecast] so fix one sign | Measuring only the total, where errors cancel | Monthly |
| Commitment coverage | Eligible usage at commitment rates ÷ all eligible usage[^aws-sp-reports] | Raising it while ESR falls (Lab 2) | Weekly to monthly |
| Commitment utilisation | Commitment used ÷ purchased; FOCUS `CommitmentDiscountStatus`[^aws-sp-reports] | 100% can mean under-committed | Daily alert |
| ESR | (ODE spend − actual spend − cost to achieve) ÷ ODE spend[^esr] | Omitting fees; the shortcut at low utilisation | Monthly |
| Idle cost (clusters) | (Asset cost − workload cost) ÷ allocation costs[^opencost-spec] | Calling all headroom "waste" | Weekly |
| Anomaly response | Median time to acknowledge; share with a recorded outcome[^cap-anom] | Alert fatigue | Weekly |
| Practice engagement | Share of teams reviewing costs, and of variances explained | Attendance without decisions | Monthly |

**Worked example (illustrative).** Checkout's Lab 1 showback was 6,734.56 for 1,250,000 orders: **5.39 per 1,000 orders**. Next
month it costs 7,400 (+9.9%) for 1,500,000 orders (+20%): **4.93**, 8.4% lower, so the bigger bill is good news. A management fee
of 100 a week would lower Lab 2's 21.4% ESR to 20.3%.

**Leading** indicators (resources tagged at creation, designs with a cost estimate, acknowledgement time, commitment expiries in
the next 90 days) move before the money; **lagging** ones (unit cost, ESR, forecast accuracy, allocation) confirm the outcome.
**Vanity traps:** savings identified rather than realised; recommendation counts; "cost avoided" that counts rate and usage savings
for one resource twice;[^cap-rate] coverage without utilisation. **Data limits:** billing data lags by up to a day, invoices close
days after month end, and amortisation shifts daily numbers when purchases land;[^aws-anom][^cap-chargeback] say so on dashboards.

### Quality, security, privacy and compliance

FinOps handles commercially sensitive data, authorises financial commitments and can run automation that changes production.

| Risk (likelihood / impact) | Signal | Mitigation | Owner |
|---|---|---|---|
| Negotiated rates leak (medium / high; terms are often confidential)[^cap-rate] | Broad access to raw billing tables | Role-based views limited to each team's scopes; effective cost, not contract terms | FinOps with security |
| Personal data in tags (medium / medium) | Tags such as `owner=jane.doe@…` | Team IDs, not personal identifiers; review with [PrivacyOps](../privacyops/) | FinOps |
| Mistaken commitment purchase (low / high) | Purchases outside the review calendar | Preparer ≠ approver; few purchase roles; every purchase logged and alerted | Finance |
| Automation stops something needed (medium / high) | Restore requests after policy runs | Dry run, grace period, non-production first, change review, rollback | Engineering |
| Cost cutting erodes reliability or security (medium / high) | SLO breaches; logging or backups reduced | SLOs and security controls as explicit guardrails | Service owner |
| Wrong chargeback in the ledger (medium / medium) | Disputes, late true-ups | Invoice reconciliation; versioned rules; correction process[^cap-chargeback] | Finance |
| A cost spike is a security incident (low / high) | Compute in unused regions or accounts | Route to [SecOps](../secops/) and [IncidentOps](../incidentops/) processes | Security |

**Auditability.** Version-control allocation rules, KPI definitions and tag standards, record the rule version behind each
showback, and keep evidence of commitment approvals; chargeback may face data-integrity requirements such as SOC
compliance.[^cap-chargeback] Recharging between legal entities and record retention differ by jurisdiction; this page offers no
legal, tax or accounting advice.


### Cost, capacity and sustainability

**The cost of FinOps itself.** In the 2026 survey, organisations managing more than $100M reported averages of 8 to 10
practitioners and 3 to 10 contractors, scaling through federated champions and automation rather than headcount.[^sof-2026] The
figures are self-reported; the lesson is proportion: optimisation work needs a payback threshold,[^cap-usage] and once the big
waste is gone, unit economics and forecasting usually pay more than another clean-up.

**Capacity is not a discount.** Most commitments are billing constructs: Azure says savings plans "don't affect the runtime state of
your resources".[^az-sp] AWS zonal Reserved Instances are the well-known exception: bought for one Availability Zone, they also
reserve capacity there, while regional ones do not.[^aws-ri] Otherwise guaranteed capacity is a separate decision, with its own
capacity-reservation columns in FOCUS.[^focus-spec]

**Sustainability** is a Framework capability with an allied persona.[^fin-fw][^fin-personas] Cost and carbon usually move together
but can diverge: multi-year reservations for unoptimised resources can lock in unnecessary carbon impact.[^cap-rate] Carbon
accounting is in [GreenOps](../greenops/).

### Assurance of the operating model

Check that the *practice* works, not only that the cloud is cheap: Q5a and Q5b pass at every close, reports record their rule
version, reviews are held, anomalies close with a recorded outcome (a Run-level behaviour[^cap-anom]) and variances are explained.
Add a periodic FinOps Assessment (a Framework capability)[^fin-fw] and an annual internal-audit sample of chargeback entries
against source data; the quarterly [governance audit](#checklists) covers access and approvals.

## When things go wrong

### Common failures and troubleshooting

Each entry reads *symptom* → likely cause → diagnosis → fix → prevention.

- **Allocation stuck below target** → shared accounts, untaggable services or keys never activated → Q2 by account and service;
  check activation → map accounts to owners, activate and backfill keys,[^aws-tags] add shared-cost rules → required tags validated
  at deployment.[^aws-tag-iac]
- **Teams dispute their showback** → rules changed mid-period, or hidden shared pools → compare the report's rule version with the
  published rules → show the rows; re-issue if wrong → stable rules, shared lines shown separately.
- **Commitment utilisation falling** → migration or rightsizing after purchase → utilisation per commitment → steer workloads onto
  it, exchange if allowed, do not renew → roadmaps in purchase decisions; tranches.[^cap-rate]
- **Forecast misses every month** → trend-only forecast; launches missing → [split the variance](#forecasting-and-budgeting-in-practice)
  → driver-based forecasts and a launch calendar → owners sign off monthly.[^cap-forecast]
- **Anomaly alerts ignored** → thresholds too low; a central inbox → alerts per action taken → per-owner thresholds; expected
  spikes documented → routing by allocation metadata.[^cap-anom]
- **Spot savings vanish, or incidents follow** → stateful work on spot; *Deallocate* keeps billing disks[^az-spot] → interruption
  logs; stopped-VM storage → move stateful work back; *Delete* policy → a spot-readiness checklist.
- **Costs rise after an "optimisation"** → smaller instances scaled out; retrieval fees → unit cost and SLOs before and after →
  roll back → judge by unit cost over a full business cycle.
- **Billed cost does not match the invoice** → taxes, credits, marketplace, currency, late usage → Q5a per invoice[^focus-spec] →
  fix the mapping; treat currency separately → reconcile automatically at every close.
- **A month's billed and effective totals differ** → usually correct: an upfront purchase, or covering and covered charges in
  different periods[^focus-spec] → Q5b per commitment over its term → nothing to fix if Q5a and Q5b pass → label the payment
  option on dashboards.

### Worked incident: the weekend logging spike (illustrative runbook)

**Situation (illustrative).** A Friday release sets debug-level logging in a busy service, and log costs climb. Billing-based
detection is slow (AWS documents that its anomaly service can take up to 24 hours),[^aws-anom] so the first cost alert arrives on
Saturday afternoon; a usage alert fired on Friday evening, into a channel nobody watches at weekends.

1. **Acknowledge** within the agreed time (for example four business hours, one hour for severity 1); name the owner from the
   allocation metadata in a ticket.
2. **Scope:** service, account, region, start time and trend against the previous four weeks.
3. **Expected or not?** Detection compares spend with the past, so planned launches raise alerts too;[^cap-anom] check the launch
   calendar and change log. This spike matches a Friday deployment: not expected.
4. **Contain** through normal change: the owner reverts the log level. Do **not** delete log data before checking retention and
   legal-hold requirements.
5. **Verify and quantify:** volume back at baseline, confirmed by the next day's cost; record the excess (actual − baseline).
6. **Prevent:** ask why the change passed review and why the usage alert reached nobody; add a pipeline check on production log
   level, an ingestion cap or sampling, usage alerts routed to on-call, a per-service budget alert.
7. **Close:** record the outcome, as the Foundation's Run-level practice does for every anomaly,[^cap-anom] and review it
   blamelessly at the monthly FinOps review.

::: figure Cost anomaly response: from alert to prevention
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20}}}%%
flowchart TB
  A["Alert: cost or usage above threshold"] --> B["Acknowledge; name the owner from allocation metadata"]
  B --> C["Scope: service, account, region, start time, trend"]
  C --> D{{"Expected? Launch, migration, load test"}}
  D -->|yes| E["Document, adjust the forecast, record the outcome, close"]
  D -->|no| F{{"Possible security incident?"}}
  F -->|yes| G["Hand over to the security incident process"]
  F -->|no| H["Contain through normal change; verify usage is back to baseline"]
  H --> J["Quantify excess cost; root cause and prevention actions"]
  J --> L["Record outcome; tune thresholds"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class B,C,E,H,J,L core
  class A,G risk
  class D,F decision
```
Text equivalent: An alert is acknowledged, its owner named from allocation metadata and its scope (service, account, region, start
time, trend) established. An expected spike (launch, migration, load test) is documented, the forecast adjusted and the case
closed. A possible security incident goes to the security process. Anything else is contained through normal change, verified at
baseline, quantified with root cause and prevention, and closed by recording the outcome and tuning thresholds.

:::

### Anti-patterns and myths

| Anti-pattern | Why it looks attractive | Why it fails | Do this instead |
|---|---|---|---|
| A savings target as the strategy | Easy to announce and measure | Cuts value along with waste; ends when the target is hit | Unit-cost goals per scope, plus a savings *threshold* for effort |
| The central team as cost police | Fast results at first | Engineers disengage; FinOps becomes a bottleneck | Central enablement, team ownership[^fin-principles] |
| Perfect tagging before any reporting | Seems rigorous | Months pass with no decisions | Report by account now; refine iteratively |
| Tool first | Feels like progress | Tools encode rules nobody agreed | Agree allocation rules and cadence, then choose tools |
| One-off clean-up sprints | Visible wins | Waste returns; the principles favour continuous adjustment[^fin-principles] | Policies and defaults that prevent waste |
| "Run" in every capability | Looks like excellence | The Foundation says this should never be the goal by itself[^fin-maturity] | Mature what pays back |

Three more are taught where they arise: chargeback before the rules are trusted ([decision framework](#decision-framework)),
coverage as the commitment KPI ([commitment playbook](#playbook-buying-a-commitment)), and totals without unit cost
([metrics](#metrics-and-kpis)). **Myths.** *"Commitments always save money"*: Lab 2 shows a negative ESR from over-commitment.
*"The cheapest architecture is the best one"*: a faster, pricier service can win on unit economics.

## Deciding and adopting

### When to use FinOps and when not to

**Adopt a formal practice when** most of these hold: variable spend is material to margins or budget; many teams create spend;
bills cannot be traced to products; budget surprises recur; commitment decisions are made or avoided; or SaaS, data and AI spend
grows outside any process.

**Do not build one yet, or keep it very light, when** spend is small relative to a practice's cost (a named owner, provider budgets
and a monthly look will do); one team owns and sees the whole bill; most spend is fixed-price contracts, better handled by
procurement and ITAM; or no sponsor will give teams data and authority, in which case a FinOps team becomes a report nobody reads.

**Hidden responsibilities:** data pipelines and allocation rules, dispute arbitration, aligning commitments with roadmaps, and
re-education after every reorganisation or acquisition.[^cap-ops] **Exit condition:** if spend becomes largely contractual, fold
FinOps into finance and platform teams, keeping the data platform and the monthly review.

### Decision framework

::: figure Choosing the size and shape of a FinOps practice, including "not yet"
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20}}}%%
flowchart TB
  Q1{{"Is variable technology spend material for us?"}}
  Q1 -->|no| N1["Not yet: named owner, provider budgets, monthly look; revisit yearly"]
  Q1 -->|yes| Q2{{"Do many teams create spend?"}}
  Q2 -->|yes| Q3{{"Several providers or technology categories?"}}
  Q2 -->|no| N2["Light model: part-time practitioner inside the owning team"]
  Q3 -->|no| N3["Central enablement with native tools and exports"]
  Q3 -->|yes| N4["Central enablement or hub-and-spoke with a FOCUS data platform"]
  N3 --> Q4{{"Does accounting require cost-centre postings?"}}
  N4 --> Q4
  Q4 -->|no| S1["Showback only"]
  Q4 -->|yes| S2["Showback first; chargeback once rules are stable"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class N1,N2 neutral
  class N3,N4,S1,S2 core
```
Text equivalent: Not material: do not build a practice yet (named owner, provider budgets, monthly look, revisit yearly).
Material but few teams creating spend: a part-time practitioner inside the owning team. Many teams: central enablement or
hub-and-spoke with a FOCUS data platform for several providers or categories, or central enablement with native tools for one.
If accounting requires cost-centre postings, showback first and chargeback once rules are stable; otherwise showback only.
:::

**Weighted comparison: showback only, or showback plus chargeback?** Weights and 1–5 scores are **illustrative assumptions** for an
organisation whose budgets sit with business units; change them to suit yours.

| Criterion | Weight | Showback only | Showback + chargeback |
|---|---|---|---|
| Accountability felt by budget owners | 0.30 | 3 | 5 |
| Effort to run (data, reconciliation, disputes) | 0.25 | 5 | 2 |
| Accuracy required before go-live | 0.20 | 4 | 2 |
| Fit with accounting policy (budgets held by business units) | 0.15 | 2 | 5 |
| Risk of gaming or disputes | 0.10 | 4 | 2 |
| **Weighted score** | 1.00 | **3.65** | **3.35** |

Showback = 0.30×3 + 0.25×5 + 0.20×4 + 0.15×2 + 0.10×4 = 3.65; chargeback = 0.30×5 + 0.25×2 + 0.20×2 + 0.15×5 + 0.10×2 = 3.35.
Showback wins **for now**; the effort and accuracy scores improve as allocation matures, hence "showback first, chargeback later"
(a policy choice, not a maturity step: see [What FinOps is not](#what-finops-is-not)). If accounting policy *requires* postings, fit
becomes a gate rather than a weight.

### Maturity model

The Foundation's Crawl, Walk and Run apply to **each capability separately**, and Run everywhere is not the goal.[^fin-maturity]
The five levels below are **this Atlas's model** for summarising many capability ratings for leadership, not an official scale.

| Level | Observable behaviours | Exit criteria | Next step |
|---|---|---|---|
| 0. Unmanaged | Bills paid, not reviewed; commitments ad hoc | An owner for technology spend exists | Name a sponsor; turn on exports |
| 1. Visible (Crawl) | Monthly account-level showback; anomaly alerts; quick wins | ≥ 70% allocated (Foundation Crawl sample); report published 3 months running | Tagging standard; team reviews |
| 2. Accountable (Walk) | Teams review their costs; shared-cost rules written; central commitment schedule | ≥ 85% allocated; forecast variance < 10% for top scopes (Walk samples) | Unit metrics; ESR; policy as code |
| 3. Optimised and predictable | Unit cost trended; ESR managed; driver-based forecasts; automation with grace periods | Unit metric per major product; ESR target met two quarters running | Shift-left estimates; more scopes |
| 4. Value-driven (Run where it pays) | Cost in design and investment decisions; several technology categories | Design reviews include unit-cost estimates; > 90% allocable where it matters | Decide what *not* to mature |

::: figure Maturity progression: what has to become true to move up a level
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 30}}}%%
flowchart TB
  L0["0 Unmanaged"] -->|"sponsor named, exports on"| L1["1 Visible"]
  L1 -->|"tagging standard, team reviews, 85% allocated"| L2["2 Accountable"]
  L2 -->|"unit metrics, ESR, driver-based forecasts"| L3["3 Optimised and predictable"]
  L3 -->|"cost in design and investment"| L4["4 Value-driven"]
  L2 -.->|"goals already met"| H["Hold: mature only what pays back"]
  L3 -.-> H
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class L1,L2,L3,L4 core
  class L0 neutral
  class H decision
```
Text equivalent: Level 0 (Unmanaged) reaches 1 (Visible) with a named sponsor and exports on; 2 (Accountable) with a tagging
standard, team reviews and about 85% allocated; 3 (Optimised and predictable) with unit metrics, a managed effective savings rate
and driver-based forecasts; 4 (Value-driven) when cost enters design and investment decisions. From levels 2 and 3 a dotted path
leads to "hold": stop maturing capabilities that already meet their goals.
:::

### Adoption roadmap: 30, 60 and 90 days

The plan assumes a sponsor, one or two practitioners, a finance partner and billing read access; adjust the pace to your size.

| Window | Key actions | Metrics and milestones |
|---|---|---|
| Days 1–30: see it | Turn on and keep billing exports (FOCUS where offered); map accounts to owners; draft the tagging standard and activate keys; route anomaly alerts to owners; list commitments and expiries | Baseline: spend, allocated %, top 10 services, utilisation; first account-level showback |
| Days 31–60: own it | 15-minute weekly cost slot for the top 10 spending teams; shared-cost rules v1; non-production schedules; idle clean-up with grace periods; first forecasts for top scopes | Allocated % up; first realised savings; acknowledgement time |
| Days 61–90: run it | First monthly review with finance; commitment policy and a first tranche sized to its window's floor; a unit metric per major product; KPI scorecard v1 | ESR baseline and target; forecast variance; scorecard reviewed by leadership |

**Quick wins:** delete unattached storage after a confirmed grace period; schedule non-production environments (about 75% potential
savings for environments used 40 of 168 hours a week);[^aws-wa]
 fix the largest untagged resources; set budget alerts
for every team.

## Toolkit

### Checklists

**Quick start**

- [ ] Executive sponsor named; first scope agreed; billing exports enabled and retained (FOCUS where available)
- [ ] Accounts, subscriptions and projects mapped to owners
- [ ] Tagging standard drafted; keys activated in billing; required keys validated at deployment
- [ ] Anomaly alerts routed to named owners; first showback published

**Commitment purchase preflight**

- [ ] Eligible usage reviewed at the instrument's evaluation window (hourly for most); planned changes subtracted
- [ ] Coverage, utilisation and ESR modelled for several levels; term, flexibility and tranche chosen
- [ ] Preparer and approver are different people; utilisation alert configured before purchase

**New workload launch readiness**

- [ ] Cost per unit of demand estimated; budget and forecast entry created
- [ ] Ownership tags enforced in templates; non-production schedules set; spot or commitment eligibility assessed

**Governance audit (quarterly)**

- [ ] Billing-data readers and commitment buyers still the right lists; purchases match approvals
- [ ] Policy-as-code changes reviewed and tested; dry-run logs retained
- [ ] Tagging standard and shared-cost rules reviewed; no personal data in tags or resource names

**Continuous improvement (twice a year)**

- [ ] Which capabilities paid back, and which to hold? Are unit-metric denominators still right?
- [ ] Next scope (SaaS, data platforms, AI) assessed; feedback on reports acted on

### Templates

**One-page FinOps charter** (this Atlas's proposal; see [Charter and principles](#charter-and-principles))

```text
FINOPS CHARTER — <organisation>                          Version <n>, approved <date> by <sponsor>
Mission:        <one sentence on value from technology spend>
Scope(s):       <e.g. public cloud, company-wide; SaaS (from Q3)>
Decision rights: usage → engineering teams | rates and commitments → FinOps (R), Finance (A)
                 budgets → Finance | contracts → Procurement | trade-offs above <amount> → <exec forum>
Cadence:        daily anomalies | weekly team review | monthly FinOps review | quarterly commitments and KPIs
Year-one goals: allocation ≥ <x>% | unit metric per major product | forecast variance ≤ <y>% | ESR target <z>%
Non-goals:      approving deployments; policing teams; savings at the expense of SLOs or security
Policies:       tagging standard v<n>; commitment policy v<n>; anomaly response v<n>; non-production lifetime v<n>
Review date:    <date>
```

**Commitment decision record**

```text
COMMITMENT DECISION RECORD  CDR-<id>                    Date: <YYYY-MM-DD>
Context:        <services, regions, current on-demand-equivalent spend per hour (floor / median / peak)>
Planned change: <migrations, rightsizing, decommissions during the term>
Options:        A) <instrument, term, $/h>  B) <...>  C) do nothing
Model results:  coverage | utilisation | ESR | worst-case ESR if usage falls <n>%
Decision:       <option, amount, term, tranche>     Rationale: <why>
Risks:          <stranding risk, flexibility, exchange terms read on <date>>
Prepared by:    <name/role>     Approved by: <name/role, different from preparer>
Review:         utilisation alert at <x>%; revisit on <date>
```

**Monthly team cost review (agenda, 15 minutes)**

```text
1. Spend vs forecast vs budget (2 min)        — variance > threshold? owner and explanation
2. Unit cost trend (3 min)                    — up or down, and why
3. Anomalies since last review (3 min)        — closed? lessons?
4. Top 3 recommendations (5 min)              — accept / reject (with reason) / defer
5. Actions and owners (2 min)
```

**KPI scorecard**

| KPI | Target | This month | Last month | Trend | Owner |
|---|---|---|---|---|---|
| Allocation coverage | ≥ 85% | | | | FinOps |
| Unallocated cost | ≤ 5% | | | | FinOps |
| Forecast variance (top scopes) | ≤ 10% | | | | Product owners |
| ESR (compute) | <agreed> | | | | FinOps |
| Commitment utilisation | ≥ <agreed> | | | | FinOps |
| Unit cost: <product> | trend ↓ or flat | | | | Product |
| Anomalies acknowledged in time | ≥ 90% | | | | Engineering |

### Deep comparisons

Other comparisons sit where they are used ([showback versus chargeback](#decision-framework), [team models](#roles-ownership-and-raci),
[neighbours](#how-finops-relates-to-other-ops), [ITFM](#what-finops-is-not)); this one compares the two optimisation levers.

| Aspect | Usage optimisation | Rate optimisation |
|---|---|---|
| Lever | Use fewer or smaller resources, or run them less | Pay less per unit: commitments, negotiation, spot |
| Primary owner | Engineering[^cap-usage] | Central FinOps team with finance and procurement[^cap-rate][^fin-phases] |
| Reversibility | Usually reversible | Commitments are multi-year obligations |
| Main risk | Performance or reliability regression | Stranded commitments; double-counted savings |
| Cadence | Continuous | A regular purchasing cadence,[^cap-rate] in tranches ([commitment playbook](#playbook-buying-a-commitment)) |

### FAQ

::: answer Where should FinOps report: finance or technology?
Either can work; in the 2026 survey, 78% of practices reported into the CTO or CIO organisation.[^sof-2026] Technology gives earlier
influence on architecture, and a strong dotted line to finance keeps forecasting honest. Avoid a place where only one side listens.
:::

::: answer How precise must allocation be, and do we need a data platform?
Precise enough for the decision: the Foundation's Crawl sample goal is at least 70% allocated, with "informed ignore" of some shared
costs,[^fin-maturity][^cap-alloc] while chargeback needs more. A single-provider organisation may not need to ingest data at
all;[^cap-ingest] a data platform pays off when you add providers, SaaS or chargeback.
:::

::: answer Our spend went up after we started FinOps. Did we fail?
Not necessarily. Check unit cost: rising spend with falling unit cost is efficient growth, and "sometimes a business will decide to
tighten the belt; sometimes it'll decide to invest more."[^fin-def]
:::

::: answer How do we credit engineers for costs they avoided by designing well?
It is an open problem; practitioners in the 2026 survey ask "how do we give developers credit for shift-left activities?"[^sof-2026]
Record the estimate against the chosen design, celebrate design reviews that changed course, and track unit-cost trends rather than
one-off "savings".
:::

::: answer How does FinOps interact with SRE error budgets?
Both are budgets with consequences, one for money and one for unreliability. Treat SLOs as constraints on cost optimisation: a
rightsizing that consumes error budget is not a saving, and the trade-off belongs to the service owner (see [SRE](../sre/)).
:::

## Going further

### Advanced topics and emerging direction

**Established** (taught above): FOCUS-normalised data,[^focus-home] tranches sized to the floor, Kubernetes idle cost made
explicit,[^opencost-spec] scopes as the unit of tailoring.[^fin-scopes]

**Emerging** (real, definitions still settling):

- **Executive strategy alignment,** new in Framework 2026: FinOps in multi-year investment and product prioritisation, with a
  "FinOps Enabled Executive".[^fin-2026][^cap-exec]
- **Shift-left costing.** Pre-deployment costing was among the tool capabilities practitioners most wanted in 2026, and measuring
  its effect is unsolved;[^sof-2026] Infracost puts estimates into pull requests,[^infracost] and tag-policy validation now checks
  ownership tags in the same pipelines.[^aws-tag-iac]
- **Beyond cloud:** 28% of 2026 respondents are beginning to include, or plan to include, labour costs.[^sof-2026]
- **Commitment and invoice data in FOCUS** 1.3 and 1.4,[^focus-spec][^cap-rate] while the major clouds' exports were listed at 1.2
  in October 2026.[^focus-home]

**Speculative or marketing:** autonomous agents that buy commitments or re-architect without human approval; "guaranteed savings"
percentages detached from your usage profile.

### Learning path

**Prerequisites:** basic cloud concepts, spreadsheet or SQL skills, and a rough idea of how your budgets and month-end close work.

- **1 day:** the Foundation's definition, principles and phases;[^fin-def][^fin-principles][^fin-phases] the glossary; Lab 1.
- **1 week:** export a month of your own billing data (FOCUS if possible); compute allocation coverage and the top 20 untagged
  resources; draft a tagging standard; run Lab 2 on your own hourly usage.
- **30 days:** showback and a weekly review for two teams; shared-cost rules; a driver-based forecast for one scope; a commitment
  decision record, even if you do not buy.
- **Then specialise** ([KubernetesOps](../kubernetesops/), [FinOps for AI](../finops-for-ai/), [GreenOps](../greenops/), SaaS
  with ITAM) and optionally certify: FinOps Certified Practitioner, then Professional; FOCUS Analyst for data roles.[^training][^focus-home]

**Paths by role.** *Beginners:* In 30 seconds, the glossary, Lab 1, the FAQ. *Engineers and practitioners:* the building blocks,
the reference implementation, Labs 2 and 3, the runbook. *Finance:* forecasting, query Q5, the month-end SOP. *Leaders and
architects:* the operating model, metrics, the decision framework, the maturity model, the judgement call.

## Wrap-up

### Executive recap and cheat sheet

| Area | Remember |
|---|---|
| Definition | An operating model for variable technology spend: shared data, decision rights, a fixed cadence |
| Equations | Cost = usage × rate; value = outcome ÷ cost |
| Decision rights | Engineers: usage. FinOps: rates, standards, data. Finance: budgets. Procurement: contracts. Leaders: trade-offs |
| Metrics | Allocation coverage; unit cost per scope; forecast variance; ESR, with coverage and utilisation as diagnostics |
| Data rule | Effective cost for showback and accrual budgets; billed cost for invoices and cash; reconcile per invoice and per commitment |
| Commitments | Size to the floor of the evaluation window (an hour for most); tranches; preparer ≠ approver; judge by ESR |
| Watch-outs | Savings targets as strategy; chargeback before trust; coverage as a target; automation without grace periods |
| Next action | Pick one scope, publish showback within 30 days, add a 15-minute cost slot to the top teams' weekly meetings |

### A judgement call: commit now or wait for the re-architecture?

**Illustrative situation.** A fleet of virtual machines never falls below 60 per hour of on-demand-equivalent (ODE) cost. A
re-architecture planned for month 10 moves half of it to a serverless container service billed per vCPU-second, not on VMs of the
same family: the VM floor drops to 30 per hour and containers add 25. A resource-based VM commitment would not cover the
containers; a flexible spend-based commitment that includes the container service would. Finance wants the "biggest discount
available".

**Assumptions (all illustrative).** Three-year resource-based commitments give 45% off, one-year flexible commitments 25%; 730
hours a month for 36 months. The migration lands on time in month 10 (probability 0.5), slips to month 21 (0.3) or is cancelled
(0.2). Commitments are evaluated hourly. Year 1's flexible layer is bought before the outcome is known, so it is sized to that
year's lowest eligible usage in *any* scenario; renewals are sized to the coming year's lowest eligible usage once the outcome is
known. **Units:** sizes are the ODE usage covered per hour, not the fee: 60 per hour at 45% off costs a fee of 33 per hour. (Lab 2
sizes the fee instead: 28 per hour of fee covers 40 per hour of usage.)

**Options.** **A**, the attractive choice: a three-year resource-based commitment for today's floor of 60 per hour, the deepest
discount and 100% coverage today. **B**, the cautious choice: one-year flexible commitments only, 55 per hour in year 1 (the lowest
eligible usage if the migration lands in month 10), renewed by the rule above. **C**, layered: a three-year resource-based
commitment for the VM floor that survives every scenario (30 per hour), plus a one-year flexible layer of 25 per hour in year 1,
renewed by the same rule.

| Option | Savings: on time | Savings: delayed | Savings: cancelled | Expected value | Worst case |
|---|---|---|---|---|---|
| A. 3-year resource-based, 60/h | 118.3k | 359.2k | 709.6k | 308.8k | 118.3k |
| B. 1-year flexible, renewed | 361.4k | 361.4k | 383.2k | 365.7k | 361.4k |
| C. Layered: 30/h resource-based + flexible | 519.0k | 519.0k | 540.9k | 523.4k | 519.0k |

*Savings are against paying on-demand for the same usage over 36 months.* Rerun the model with your own discounts and
probabilities.

::: answer Show the model behind the table (Python, 36 lines)
_Example status: verified by execution on 2026-10-16 (Python 3.8.10); every input is illustrative._

```python
"""Judgement call: commit now or wait? A small what-if model (Python 3.8+; every input is illustrative)."""
HOURS = 730                                    # hours per month; the horizon is 36 months
DEEP, FLEX = 0.45, 0.25                        # discounts: 3-year resource-based, 1-year flexible
SCENARIOS = {"on time": (0.5, 10), "delayed": (0.3, 21), "cancelled": (0.2, None)}  # probability, migration month

def usage(month, migration):
    """On-demand-equivalent spend per hour as (VM, containers): half the VMs move in the migration month."""
    return (30, 25) if migration and month >= migration else (60, 0)

def flex_size(months, migrations, deep):
    """Size the flexible layer to the lowest eligible usage left over in these months, for every possible migration."""
    return min(vm - min(vm, deep) + ctr for m in months for mig in migrations for vm, ctr in [usage(m, mig)])

def savings(deep, flexible, migration):
    total = 0.0
    for year in range(3):
        months = range(12 * year + 1, 12 * year + 13)
        # Year 1 is bought before the outcome is known; each renewal is sized once it is known.
        possible = [mig for _, mig in SCENARIOS.values()] if year == 0 else [migration]
        flex = flex_size(months, possible, deep) if flexible else 0
        for m in months:
            vm, ctr = usage(m, migration)
            left = vm - min(vm, deep) + ctr                   # eligible usage the deep commitment does not cover
            cost = deep * (1 - DEEP) + flex * (1 - FLEX) + left - min(left, flex)
            total += HOURS * (vm + ctr - cost)                # saving against paying on-demand
    return total

OPTIONS = {"A. 3-year resource-based, 60/h": (60, False), "B. 1-year flexible, renewed": (0, True),
           "C. Layered: 30/h + flexible": (30, True)}
for name, (deep, flexible) in OPTIONS.items():
    s = [savings(deep, flexible, mig) for _, mig in SCENARIOS.values()]
    ev = sum(p * v for (p, _), v in zip(SCENARIOS.values(), s))
    print(f"{name:31s}" + "".join(f"{v / 1e3:7.1f}k" for v in s) + f"  EV {ev / 1e3:.1f}k  worst {min(s) / 1e3:.1f}k")
a_on, a_cancel = savings(60, False, 10), savings(60, False, None)
c_on, c_cancel = savings(30, True, 10), savings(30, True, None)
print(f"A beats C (on time vs cancelled only) if P(cancelled) > {(c_on - a_on) / (a_cancel - a_on - (c_cancel - c_on)):.0%}")
```

Output of that run:

```text
A. 3-year resource-based, 60/h   118.3k  359.2k  709.6k  EV 308.8k  worst 118.3k
B. 1-year flexible, renewed      361.4k  361.4k  383.2k  EV 365.7k  worst 361.4k
C. Layered: 30/h + flexible      519.0k  519.0k  540.9k  EV 523.4k  worst 519.0k
A beats C (on time vs cancelled only) if P(cancelled) > 70%
```
:::

**Why the attractive choice can be wrong.** A has the highest headline discount and wins if nothing changes, but it concentrates
risk on the one event the business has already planned: if the migration lands on time, half the commitment covers nothing for 27
months, and from month 10 the organisation pays more per hour than on-demand. B is robust but leaves the deep discount unused on
capacity that is certain. C applies Lab 2's principle one level up: **commit deeply only to what survives every plausible future,
and keep the uncertain layer flexible.**

**Where the conclusion flips.** Comparing only "on time" and "cancelled", A beats C only if cancellation is more than about 70%
likely, and then the real problem is the roadmap, not the commitment. If the containers ran on VMs of the same family, a
resource-based commitment could keep covering them and A would lose less. Discounts, probabilities and the post-migration floor
are estimates: record them in a commitment decision record and revisit them each quarter.

### Learning objectives and mastery check

After working through this page you should be able to:

1. **Explain** FinOps, its principles and its boundaries with procurement, ITFM, CloudOps and GreenOps.
2. **Calculate** allocation coverage, unit cost, coverage, utilisation and effective savings rate from billing data, and build and
   decompose a driver-based forecast.
3. **Design** an allocation model with tagging and shared-cost rules, and a cadence with clear decision rights.
4. **Operate** a monthly review, an anomaly runbook and a commitment purchase with appropriate controls.
5. **Evaluate** when a formal FinOps practice, chargeback or a given commitment is not worth it.

::: answer Q1. A team's showback rose 15% this month while its orders rose 30%. Good or bad?
Good, judged by unit cost: it changes by a factor of 1.15 ÷ 1.30 ≈ 0.885, a fall of about 11.5%. Before celebrating, check that the
order count and the cost scope match, and that no costs were moved out of the team's allocation.
:::

::: answer Q2. Which cost should showback use? And this month billed cost exceeds effective cost by 22,000: is the data broken?
Effective cost, which carries the amortised share of the commitments that covered each team's usage.[^focus-spec] The 22,000 gap
is probably correct: an upfront purchase is billed in full this month but recognised over its term, and FOCUS allows period totals
to differ then.[^focus-spec] Check instead that billed cost matches each invoice (Q5a) and each commitment balances over its term (Q5b).

:::

::: answer Q3. Thirty per cent of spend sits in a shared Kubernetes cluster with no allocation. What do you do in the next 30 days?
Put owner labels on namespaces; deploy an allocation tool or use the provider's split-cost feature; allocate workload cost as
`max(request, usage)`; show idle cost separately; agree with tenants, in writing, whether idle is spread or held by the platform; publish a
first showback with the rule version. Do not charge back until tenants accept the rules.[^opencost-spec][^cap-chargeback]
:::

::: answer Q4. The CFO wants chargeback next quarter, and allocation is at 70%. What do you advise?
Run showback for at least a quarter first: raise allocation towards the Walk level of roughly 85%,[^fin-maturity] publish shared-cost
rules, reconcile to invoices and agree a correction process after close. Charging back 30% unexplained cost generates disputes, not
accountability. If accounting requires postings now, post at a coarse level, for example by account, while detail improves.
:::

::: answer Q5. Checkout came in 960 over its forecast: orders ran about 6% above plan, and an unplanned load-test environment ran. What do you ask each owner to do?
Split the variance first ([forecasting](#forecasting-and-budgeting-in-practice)). The volume part (+540) is growth the budget was meant
to fund: cover it from holdback or re-forecast. The rate part (+255) goes to engineering: why did cost per 1,000 orders rise? The scope
part (+165) goes to whoever ran the load test, and load tests join the launch calendar. A blanket "cut 960" would punish success.
:::

::: answer Q6. Your organisation is on 3-year commitments with 98% utilisation and 55% coverage. Is that good?
Not necessarily. High utilisation with low coverage often means you are **under**-committed: 45% of eligible usage still pays
on-demand rates. Check the floor of the uncovered usage, in the instrument's evaluation window, and planned changes; there may be room
for another tranche, possibly a flexible one.
:::

### Conclusion

Once a configuration change is a spending decision, budgets and invoices cannot steer spend on their own. The answer is
organisational: give the people who change the cost the data to see it, the authority to change it and a regular forum where they
are asked about it.

The mathematics is simple; trust and stability are hard: rules that people accept and that stay put, commitments sized to how they
are evaluated, forecasts on the budget's cost basis, and metrics that reward value rather than activity. Be humble about savings
claims, including your own.

If you remember one thing, make it this: **put the cost in front of the person who can change it, quickly enough to matter, and judge
the result by unit cost, not by the size of the bill.**

## Sources and further reading

Foundation framework pages (CC BY 4.0) are quoted briefly and paraphrased with attribution. All sources were opened on 2026-10-16;
the claim-level evidence ledger is `research/finops-ledger.md` in the Atlas repository.

[^fin-def]: [What is FinOps?](https://www.finops.org/introduction/what-is-finops/) — FinOps Foundation Technical Advisory Council, updated March 2026. Checked 2026-10-16.
[^fin-fw]: [FinOps Framework overview](https://www.finops.org/framework/) — FinOps Foundation, 2026 framework. Checked 2026-10-16.
[^fin-principles]: [FinOps Principles](https://www.finops.org/framework/principles/) — FinOps Foundation, undated page. Checked 2026-10-16.
[^fin-personas]: [FinOps Personas](https://www.finops.org/framework/personas/) — FinOps Foundation, undated page. Checked 2026-10-16.
[^fin-phases]: [FinOps Phases](https://www.finops.org/framework/phases/) — FinOps Foundation, undated page. Checked 2026-10-16.
[^fin-maturity]: [FinOps Maturity Model](https://www.finops.org/framework/maturity-model/) — FinOps Foundation, undated page. Checked 2026-10-16.
[^fin-scopes]: [FinOps Scopes](https://www.finops.org/framework/scopes/) — FinOps Foundation, undated page. Checked 2026-10-16.
[^fin-2026]: [FinOps Framework 2026: Executive Strategy, Technology Categories, and Converging Disciplines](https://www.finops.org/insights/2026-finops-framework/) — Vasilio Markanastasakis, FinOps Foundation, 2026-03-19. Checked 2026-10-16.
[^fin-mission]: [A One Word Change: How the FinOps Community Made Our Mission Evolution Inevitable](https://www.finops.org/insights/mission-update/) — J.R. Storment, FinOps Foundation, 2026-02-19. Checked 2026-10-16.
[^fin-about]: [About the FinOps Foundation (Mission & Structure)](https://www.finops.org/about/) — FinOps Foundation, undated page. Checked 2026-10-16.
[^fin-charter]: [Technical Charter for FinOps Project a Series of LF Projects, LLC](https://github.com/finopsfoundation/tac/blob/master/charter.md) — FinOps Foundation Technical Advisory Council repository, adopted 2020-08-05; linked from the footer of finops.org pages. Checked 2026-10-16.
[^lf-2020]: [The Linux Foundation Brings Together IT and Finance Teams to Advance Cloud Financial Management and Education](https://www.linuxfoundation.org/press/press-release/the-linux-foundation-brings-together-it-and-finance-teams-to-advance-cloud-financial-management-and-education) — The Linux Foundation, 2020-06-29. Checked 2026-10-16.
[^book]: [Cloud FinOps: Collaborative, Real-Time Cloud Value Decision Making, 2nd edition (catalogue record)](https://www.bookshare.org/browse/book/6424518) — J.R. Storment and Mike Fuller, O'Reilly Media, 2023; record on Bookshare (the publisher's page could not be fetched automatically). Checked 2026-10-16.
[^sof-2026]: [State of FinOps 2026 Report](https://data.finops.org/) — FinOps Foundation, 2026 (1,192 respondents; self-selected practitioner survey). Checked 2026-10-16.
[^washes]: [Gestão de Custos em Computação em Nuvem](https://sol.sbc.org.br/index.php/washes/article/view/29449) — de Souza et al., WASHES 2024, Sociedade Brasileira de Computação, 2024-07-21, DOI 10.5753/washes.2024.3160 (abstract read). Checked 2026-10-16.
[^cap-alloc]: [Allocation (capability)](https://www.finops.org/framework/capabilities/allocation/) — FinOps Foundation. Checked 2026-10-16.
[^cap-unit]: [Unit Economics (capability)](https://www.finops.org/framework/capabilities/unit-economics/) — FinOps Foundation. Checked 2026-10-16.
[^cap-anom]: [Anomaly Management (capability)](https://www.finops.org/framework/capabilities/anomaly-management/) — FinOps Foundation. Checked 2026-10-16.
[^cap-rate]: [Rate Optimization (capability)](https://www.finops.org/framework/capabilities/rate-optimization/) — FinOps Foundation. Checked 2026-10-16.
[^cap-usage]: [Usage Optimization (capability)](https://www.finops.org/framework/capabilities/usage-optimization/) — FinOps Foundation. Checked 2026-10-16.
[^cap-forecast]: [Forecasting (capability)](https://www.finops.org/framework/capabilities/forecasting/) — FinOps Foundation. Checked 2026-10-16.
[^cap-budget]: [Budgeting (capability)](https://www.finops.org/framework/capabilities/budgeting/) — FinOps Foundation. Checked 2026-10-16.
[^cap-chargeback]: [Invoicing & Chargeback (capability)](https://www.finops.org/framework/capabilities/invoicing-chargeback/) — FinOps Foundation. Checked 2026-10-16.
[^cap-gov]: [Governance, Policy & Risk (capability)](https://www.finops.org/framework/capabilities/governance-policy-risk/) — FinOps Foundation. Checked 2026-10-16.
[^cap-ops]: [FinOps Practice Operations (capability)](https://www.finops.org/framework/capabilities/finops-practice-operations/) — FinOps Foundation. Checked 2026-10-16.
[^cap-ingest]: [Data Ingestion (capability)](https://www.finops.org/framework/capabilities/data-ingestion/) — FinOps Foundation. Checked 2026-10-16.
[^cap-licensing]: [Licensing & SaaS (capability)](https://www.finops.org/framework/capabilities/licensing-saas/) — FinOps Foundation. Checked 2026-10-16.
[^cap-exec]: [Executive Strategy Alignment (capability)](https://www.finops.org/framework/capabilities/executive-strategy-alignment/) — FinOps Foundation, added in Framework 2026. Checked 2026-10-16.
[^esr]: [How to Calculate Effective Savings Rate (ESR)](https://www.finops.org/wg/how-to-calculate-effective-savings-rate-esr/) — FinOps Foundation working group, last updated 2026-03-17. Checked 2026-10-16.
[^focus-spec]: [FOCUS Specification v1.4](https://focus.finops.org/focus-specification/) and [specification source, tag v1.4](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/tree/v1.4/specification) (column definitions) — FOCUS, Joint Development Foundation Projects, 2026. Checked 2026-10-16.
[^focus-releases]: [FOCUS_Spec releases](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/releases) — FOCUS project on GitHub (v1.0 tagged 2024-06-14; v1.3 2025-12-08; v1.4 2026-06-04; dataset folders compared between tags). Checked 2026-10-16.
[^focus-v12]: [FOCUS specification source, tag v1.2: column definitions](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/tree/v1.2/specification/columns) — FOCUS project on GitHub (feature level and "Introduced (version)" of each column). Checked 2026-10-16.
[^focus-home]: [FOCUS home page: data generators and versions](https://focus.finops.org/) — FinOps Foundation, as of 2026-10-16. Checked 2026-10-16.
[^aws-sp]: [What are Savings Plans?](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html) and [Savings Plans types](https://docs.aws.amazon.com/savingsplans/latest/userguide/plan-types.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-sp-apply]: [How Savings Plans apply to your usage](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-ri]: [How billing works with Reserved Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts-reserved-instances-application.html) and [Regional and zonal Reserved Instances (scope)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html) — Amazon EC2 User Guide, Amazon Web Services. Checked 2026-10-16.
[^aws-sp-reports]: [Using the Savings Plans coverage report](https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-usingCR.html) and [Using the Savings Plans utilization report](https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-usingPR.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-spot]: [Spot Instance interruption notices](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-tags]: [Activating user-defined cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html), [Organizing and tracking costs using AWS cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) and [Backfill cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-allocation-backfill.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-tagpol]: [Tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) and [Example tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_example-tag-policies.html) — AWS Organizations documentation. Checked 2026-10-16.
[^aws-tag-iac]: [Enforce "Required tag key" with IaC](https://docs.aws.amazon.com/organizations/latest/userguide/enforce-required-tag-keys-iac.html) and [Report tagging compliance](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-report-tagging-compliance.html) — AWS Organizations documentation; [Validate and enforce required tags in CloudFormation, Terraform and Pulumi with Tag Policies](https://aws.amazon.com/about-aws/whats-new/2025/11/validate-enforce-required-tags-cloudformation-terraform-pulumi/) — AWS What's New, 2025-11-20. Checked 2026-10-16.
[^aws-require-tags]: [Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps) — Arun Chandapillai and Shak Kathir, AWS Cloud Operations Blog, 2021-10-28 (written before required tag keys existed; cited only for the request-tag deny pattern); [Controlling access to AWS resources using tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) — AWS IAM User Guide. Checked 2026-10-16.
[^aws-focus]: [FOCUS 1.2 with AWS columns (Data Exports table dictionary)](https://docs.aws.amazon.com/cur/latest/userguide/table-dictionary-focus-1-2-aws.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-anom]: [Detecting unusual spend with AWS Cost Anomaly Detection](https://docs.aws.amazon.com/cost-management/latest/userguide/manage-ad.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-budgets]: [Managing your costs with AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) — Amazon Web Services documentation. Checked 2026-10-16.
[^aws-wa]: [Cost Optimization Pillar: design principles](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/design-principles.html) — AWS Well-Architected Framework. Checked 2026-10-16.
[^aws-cli-ce]: AWS CLI command reference: [get-cost-and-usage](https://docs.aws.amazon.com/cli/latest/reference/ce/get-cost-and-usage.html), [get-savings-plans-utilization](https://docs.aws.amazon.com/cli/latest/reference/ce/get-savings-plans-utilization.html), [get-savings-plans-coverage](https://docs.aws.amazon.com/cli/latest/reference/ce/get-savings-plans-coverage.html) — Amazon Web Services. Checked 2026-10-16.
[^az-sp]: [What are savings plans?](https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/savings-plan-overview) — Microsoft Learn. Checked 2026-10-16.
[^az-res]: [What are Azure Reservations?](https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/save-compute-costs-reservations) — Microsoft Learn. Checked 2026-10-16.
[^az-spot]: [About Azure Spot Virtual Machines](https://learn.microsoft.com/en-us/azure/virtual-machines/spot-vms) — Microsoft Learn. Checked 2026-10-16.
[^az-focus]: [Tutorial: Create and manage Cost Management exports (Cost and usage details, FOCUS)](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports) and [FOCUS cost and usage details file schema](https://learn.microsoft.com/en-us/azure/cost-management-billing/dataset-schema/cost-usage-details-focus) — Microsoft Learn. Checked 2026-10-16.
[^az-waf]: [Cost Optimization design principles](https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/principles) — Azure Well-Architected Framework, Microsoft Learn. Checked 2026-10-16.
[^gcp-cud]: [Committed use discounts](https://cloud.google.com/docs/cuds) — Google Cloud documentation, last updated 2026-10-13. Checked 2026-10-16.
[^gcp-spot]: [Spot VMs](https://cloud.google.com/compute/docs/instances/spot) — Google Cloud documentation, last updated 2026-10-13. Checked 2026-10-16.
[^gcp-bq]: [Export Cloud Billing data to BigQuery](https://cloud.google.com/billing/docs/how-to/export-data-bigquery) — Google Cloud documentation, last updated 2026-10-13. Checked 2026-10-16.
[^gcp-waf]: [Well-Architected Framework: Cost optimization pillar](https://cloud.google.com/architecture/framework/cost-optimization) — Google Cloud, last updated 2026-10-13. Checked 2026-10-16.
[^k8s-req]: [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) — Kubernetes documentation. Checked 2026-10-16.
[^opencost-docs]: [OpenCost documentation overview](https://opencost.io/docs/) — OpenCost project. Checked 2026-10-16.
[^opencost-spec]: [OpenCost Specification](https://opencost.io/docs/specification) — OpenCost project. Checked 2026-10-16.
[^opencost-api]: [OpenCost API](https://www.opencost.io/docs/integrations/api) (allocation `aggregate` values) — OpenCost project; [pkg/costmodel/allocation_helpers.go, `applyLabels`](https://github.com/opencost/opencost/blob/develop/pkg/costmodel/allocation_helpers.go) — OpenCost source, develop branch (namespace labels applied to allocations; pod labels overwrite them). Checked 2026-10-16.
[^custodian]: Cloud Custodian documentation: [quick start](https://cloudcustodian.io/docs/quickstart/index.html), [EBS garbage collection example](https://cloudcustodian.io/docs/aws/examples/ebsgarbagecollect.html), [tag compliance example](https://cloudcustodian.io/docs/aws/examples/tagcompliance.html) — Cloud Custodian project. Checked 2026-10-16.
[^c7n-log]: [c7n/policy.py, `PullMode.run`](https://github.com/cloud-custodian/cloud-custodian/blob/main/c7n/policy.py) — Cloud Custodian source, main branch. Checked 2026-10-16.
[^infracost]: [infracost/infracost repository](https://github.com/infracost/infracost) — Infracost, Apache-2.0 (repository metadata only; features not tested). Checked 2026-10-16.
[^ms-toolkit]: [microsoft/finops-toolkit repository](https://github.com/microsoft/finops-toolkit) — Microsoft, MIT licence; release v14 dated 2026-04-29 (repository metadata); [FinOps hubs overview](https://learn.microsoft.com/en-us/cloud-computing/finops/toolkit/hubs/finops-hubs-overview) — Microsoft Learn, dated 2026-04-01 (lists "Full alignment with the FinOps Open Cost and Usage Specification (FOCUS)" among the benefits). Checked 2026-10-16.
[^landscape]: [FinOps Landscape](https://www.finops.org/landscape/) — FinOps Foundation directory of tools and service providers (listing content not reviewed). Checked 2026-10-16.
[^sql-json]: [SQLite JSON functions](https://www.sqlite.org/json1.html) — SQLite project; [BigQuery JSON functions](https://cloud.google.com/bigquery/docs/reference/standard-sql/json_functions) — Google Cloud; [Trino JSON functions](https://trino.io/docs/current/functions/json.html) — Trino project. Checked 2026-10-16.
[^aws-ce-pricing]: [AWS Cost Explorer pricing](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/pricing/) — Amazon Web Services, as of 2026-10-16. Checked 2026-10-16.
[^training]: [FinOps Training & Certification](https://www.finops.org/training-certification/) — FinOps Foundation. Checked 2026-10-16.


### Changelog

- 2026-10-16: first draft; labs 1 and 2 executed.
- 2026-10-16 (r1, fact-check): reconciliation in FOCUS 1.4 terms; commitments sized by evaluation window; forecasting added.
- 2026-10-16 (r2, first score): figures redrawn for phones; forecast, use case B and judgement-call units fixed; six-column RACI.
- 2026-10-16 (r3, second score): regrouped into 14 parts; AWS required tag keys (since 2025-11-20) and their gaps; FOCUS 1.2
  conditional columns; cut from 18,099 to 14,965 words.
- 2026-10-16 (r4, third score): Tooling-landscape row repaired; zonal Reserved Instances noted as reserving capacity; OpenCost
  label aggregation, FinOps hubs FOCUS alignment and rate-lever roles cited precisely; Figure 5 redrawn so labels clear the
  lifelines; repetition trimmed (14,965 to about 14,870 words).
- 2026-10-16 (r4 follow-up, orchestrator): 2026 survey findings attributed to mature practitioners vs all respondents as the report
  does; ITFM described as an allied persona of the Intersecting Disciplines capability.