FinOps

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.”^[1] 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,^[1] and Framework 2026 adds technology-category guidance for AI.^[2]

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.

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.^[6][7][8]
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.^[9]
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.^[10]
• Showback and chargeback: reporting costs to the teams that caused them without moving money; chargeback also posts them to cost centres in the ledger.^[11]
• 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”).^[10]
• 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).^[4]
• 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%).^[12]
• 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%.^[13]
• Forecast and budget: the owners’ expectation of spend, and the organisation’s funding commitment.^[14][15]
• Scope and technology category: “a defined segment of spending across technology categories, aligned to business constructs”,^[16] such as everything that runs the mobile app; and the kind of technology bought (public cloud, SaaS, data centre, data platforms, AI).^[2]

How the framework fits together. Scopes say why spend is managed, technology categories what is bought;^[2] “Domains are the outcomes of a FinOps practice & Capabilities describe how to achieve them.”^[17] Phases form a loop, not a project plan,^[7] and maturity is assessed per capability.^[18]

%%{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

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”.^[6] 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%.

%%{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

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.”^[1] 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.^[5]

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

Naming collisions. FinTechOps operates payment and ledger systems, a different field. Contract negotiation belongs to 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.^[19] 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.^[20]

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^[3] (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.^[21]
• 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.^[22][21]
• June 2024: FOCUS 1.0 is tagged, a common schema for billing data from different providers.^[23]
• 2025: the framework introduces FinOps Scopes and technology categories beyond public cloud.^[2]
• 19 February 2026: the mission changes from managing the value “of cloud” to the value “of technology”.^[24]
• 19 March 2026: Framework 2026 adds Executive Strategy Alignment and renames six capabilities, two of them to drop “Cloud”.^[2]
• June 2026: FOCUS 1.4, the latest as of October 2026, adds billing-period and invoice-detail datasets.^[23][4]

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.^[25] Treat claims about typical savings with caution.

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

%%{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

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

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.^[6]

A charter (this Atlas’s proposal). The Foundation publishes no charter for adopting organisations; its Technical Charter governs the Foundation project itself.^[26] The fill-in charter in 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.

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.^[19] 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;^[5] the sample is self-selected, but the pattern is clear: small central teams set standards, and execution is distributed.

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

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.

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; Day 2 follows the maturity model. Adoption repeats after every reorganisation, acquisition or new technology category.^[27]

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.^[7]

%%{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

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.

Policies. Governance, Policy & Risk includes commitment guardrails and escalation paths agreed with finance.^[28] 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.

%%{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

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.^[29] Usage data arrives continuously, invoices typically 3 to 12 days after month end:^[11] 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.^[4] Four cost columns matter most:

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.^[4]

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.^[4] 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). Two checks follow, run by query Q5 in the reference implementation 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.^[4]
• 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^[30][31][32] (versions are dated under Tooling landscape). Columns differ between versions (ServiceProviderName and HostProviderName succeeded ProviderName, for example), so query the version you actually receive.

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.^[10] 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.^[33]
• 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.^[32] Turn exports on first: history you did not export may be gone for good.

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.^[8] As of October 2026, all three large providers sell both kinds, for terms of 1 or 3 years:

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.^{[39][35][36][37][38]} Unused commitment cannot be saved for the peak, so these instruments pay best when sized to the hourly floor of eligible usage (Lab 2). Google’s Flexible Savings Plans are the exception: they “evaluate usage over a monthly entitlement window”,^[38] 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.^[8]
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):

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.^[8] As of October 2026 the warning ranges from none by default on Google Cloud (120 seconds if configured) to two minutes on AWS,^[40][41] and Azure’s default Deallocate eviction policy keeps billing for the disks of evicted VMs.^[42] Designing workloads for interruption is CloudOps work.

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.^[43] 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.^[44] 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).^[45] Cluster mechanics are in KubernetesOps; the allocation rules come from this page.

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.^[9]

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.

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. 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^[52]) 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.

%%{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

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

%%{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

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

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): 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);^[30] Cost Explorer’s hourly view covers only the last 14 days and is charged per usage record (as of October 2026).^[53]
3. Subtract planned change that rightsizing, migration or decommissioning will remove, or a resource-based commitment can go idle;^[8] but do not wait for optimisation to “finish”: the Foundation warns that waiting “will almost always lead to paying more”.^[8]
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).
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.^[50]
9. Contingency: steer eligible workloads onto an under-used commitment or let it expire; read exchange and return rules before purchase.

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).
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.^[8]

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,^[4] and each commitment’s payment option 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).^[14] 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.

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.^[15] 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”.^[15]

Separate what binds you from what guides you. Normative: the FOCUS specification, with MUST/SHOULD requirements for data generators (for you, a target schema),^[4] and the OpenCost specification for Kubernetes cost allocation.^[45] Guidance: the FinOps Framework, “flexible and non-prescriptive”,^[17] and the providers’ well-architected cost guidance.^[54][55][56] 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.^[19][2]

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.

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

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.

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

Machine learning. ML-based anomaly detection is now typical,^[59] 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,^[57] 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.^[5] 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.

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.

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.

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.

# 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>.^[60]

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”.^[61] 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.^[48] 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;^[48] 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.^[62] The separate enforced_for option blocks non-compliant tagging operations, and AWS advises changing it only if you are experienced with tag policies.^[61] Rolling these guardrails out across accounts is 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.

{
  "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).

These policies adapt Cloud Custodian’s tag-compliance example^[49] 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).

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

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).^[63] Every column used is defined in FOCUS 1.2, the version listed for AWS, Microsoft and Google Cloud in October 2026,^[58] 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.^[64]

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

-- 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.

The Foundation’s ESR guide uses the Cost Explorer API in the same way;^[13] the options match the AWS CLI reference.^[65]

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).^[53]

#!/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"

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),^[11] 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.

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).^[63] 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:

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:

"""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):

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.^[18] © 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.

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); 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).

"""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):

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,^[18] yet ESR falls from 21.4% to 6.0%. © At 56 per hour the organisation pays more than on-demand (ESR −9.4%).

%%{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]

An important subtlety. The Foundation’s ESR guide gives a primary definition (savings ÷ on-demand-equivalent spend) and a shortcut (utilisation × coverage × discount).^[13] 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.

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.^[49]

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 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,^[66] 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.

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),^[9] 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,^[16] 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). 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”.^[8] 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 a few things well. The Foundation’s community sample goals for allocation, commitment coverage and forecast variance are conversation starters, not targets to copy.^[18]

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;^[8] 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;^[57][11] say so on dashboards.

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

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.^[11] Recharging between legal entities and record retention differ by jurisdiction; this page offers no legal, tax or accounting advice.

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.^[5] The figures are self-reported; the lesson is proportion: optimisation work needs a payback threshold,^[43] 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”.^[36] AWS zonal Reserved Instances are the well-known exception: bought for one Availability Zone, they also reserve capacity there, while regional ones do not.^[35] Otherwise guaranteed capacity is a separate decision, with its own capacity-reservation columns in FOCUS.^[4]

Sustainability is a Framework capability with an allied persona.^[17][19] Cost and carbon usually move together but can diverge: multi-year reservations for unoptimised resources can lock in unnecessary carbon impact.^[8] Carbon accounting is in GreenOps.

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^[59]) and variances are explained. Add a periodic FinOps Assessment (a Framework capability)^[17] and an annual internal-audit sample of chargeback entries against source data; the quarterly governance audit covers access and approvals.

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,^[33] add shared-cost rules → required tags validated at deployment.^[48]
• 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.^[8]
• Forecast misses every month → trend-only forecast; launches missing → split the variance → driver-based forecasts and a launch calendar → owners sign off monthly.^[14]
• Anomaly alerts ignored → thresholds too low; a central inbox → alerts per action taken → per-owner thresholds; expected spikes documented → routing by allocation metadata.^[59]
• Spot savings vanish, or incidents follow → stateful work on spot; Deallocate keeps billing disks^[42] → 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^[4] → 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^[4] → Q5b per commitment over its term → nothing to fix if Q5a and Q5b pass → label the payment option on dashboards.

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),^[57] 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;^[59] 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,^[59] and review it blamelessly at the monthly FinOps review.

%%{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

Three more are taught where they arise: chargeback before the rules are trusted (decision framework), coverage as the commitment KPI (commitment playbook), and totals without unit cost (metrics). 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.

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.^[27] Exit condition: if spend becomes largely contractual, fold FinOps into finance and platform teams, keeping the data platform and the monthly review.

%%{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

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.

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). If accounting policy requires postings, fit becomes a gate rather than a weight.

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

%%{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

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

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);^[54] fix the largest untagged resources; set budget alerts for every team.

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

One-page FinOps charter (this Atlas’s proposal; see Charter and principles)

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

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)

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

Other comparisons sit where they are used (showback versus chargeback, team models, neighbours, ITFM); this one compares the two optimisation levers.

Established (taught above): FOCUS-normalised data,^[58] tranches sized to the floor, Kubernetes idle cost made explicit,^[45] scopes as the unit of tailoring.^[16]

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”.^[2][67]
• Shift-left costing. Pre-deployment costing was among the tool capabilities practitioners most wanted in 2026, and measuring its effect is unsolved;^[5] Infracost puts estimates into pull requests,^[51] and tag-policy validation now checks ownership tags in the same pipelines.^[48]
• Beyond cloud: 28% of 2026 respondents are beginning to include, or plan to include, labour costs.^[5]
• Commitment and invoice data in FOCUS 1.3 and 1.4,^[4][8] while the major clouds’ exports were listed at 1.2 in October 2026.^[58]

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

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;^[1][6][7] 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, FinOps for AI, GreenOps, SaaS with ITAM) and optionally certify: FinOps Certified Practitioner, then Professional; FOCUS Analyst for data roles.^[68][58]

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.

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.

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

"""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%}")

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.

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.

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.

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.

• 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.