What Computing Costs

This is usually when “savings” enters the conversation. Somebody proposes making room for the launch by retiring the old environment early, borrowing some batch workers, or shrinking a service that looks underused, and calls the result savings. Sometimes it is. Often the change is worth making but does something else: it moves an expense from one team’s report to another’s, or it avoids a purchase next quarter without reducing this month’s bill. Finance will want to know which, because an avoided purchase never shows up as a lower invoice.

Your capacity team should be the one walking around every day with a good model of cost and consumption. What’s being consumed? What does it cost, and how much does that vary? What’s changing, and what’s tomorrow’s problem? Before you promise anyone savings, go and talk to the person who has to answer for the bill. You will often find that you both did the math right, you both like the change, and you are still talking about two different things.

How to read this chapter

This chapter builds the cost model the rest of the book uses: what a computing bill is made of, what it leaves out, and how to hold several views of the same money at once.

1. Knowing what you consume before you change it — the constructed portfolio, and why current consumption comes before any purchase or saving.
2. Several dimensions of the same dollar — cost behavior, obligation, metering, attribution, cash consequence, and modeled labor.
3. A bill we can follow — the $448,000 thirty-day ledger, what kind of number it is, and the same bill by team, location, charge behavior, and funding.
4. Follow a change across the boundary — borrowed workers move attribution; new workers are a real increment.
5. The invoice leaves things out — modeled labor, the migration’s overlap, and exposures no bill shows.
6. A quiet system is a question — why an idle-looking resource needs an explanation before it becomes a saving.
7. The same bill, five ways — the five views side by side, and what each is for.
8. One problem, two dashboards — a hypothetical cost cut that returns as a capacity incident, and why it is one failure.
9. Ten times the bill — what scale changes and what it does not.
10. Enough information to have the next conversation — the cost record for the chapter’s two changes, and what standard billing data can supply.

The lesson to carry: a bill is a model with boundaries, a compressed view of the systems that drive consumption, and knowing what you consume, and what you have promised to pay for it, is the precondition for changing it.

Knowing what you consume before you change it

To work through this, the chapter uses the constructed portfolio from the introduction: the customer-facing web service, a pool of batch workers, data platforms, a shared platform for many small applications, an AI assistant that drafts replies for the support team, and a migration with its old and new environments running side by side. Together they cost $448,000 over thirty days. At a constant daily rate, that is $448,000 ÷ 30 × 365 = approximately $5.45 million a year, enough to make the choices consequential. The ledger covers the business in the Americas; the organization’s European operation, which Volume II, Chapter 21 takes up, keeps its own budget and its own agreement with Provider B. The organization and its numbers are invented so that you can check every calculation.

By the end of the chapter I want to be able to take any line on this bill and say what work it supports, what we have already promised to pay, what the invoice leaves out, and whether a proposed change would remove the expense or only move it. That still won’t tell us whether the service can handle the work, because a price says little about how a system consumes capacity; that is the next chapter’s subject.

Several dimensions of the same dollar

When I ask about cost behavior, I am asking how a cost responds to demand and how it changes over time. Finance and engineering usually answer from different sides. Finance sees the agreement and the period: a committed rate, a monthly minimum, an annual step. Engineering sees the workload: another request might add a small charge or fit inside a service whose cost stays level until it needs another instance, and data might be charged once when stored and again when read. A useful answer needs both, because a cost can be fixed this month and avoidable next year, which is why the engineer who understands the application and the finance partner who understands the agreement need to look at the same change together.

Past growth can leave costs behind after demand falls. Imagine a database expanded for a busy season: fewer incoming requests do not remove the data already stored, cancel the agreement used to buy the machines, or establish that a smaller configuration can meet recovery requirements. The cost model needs the steps required to shrink it, not just the latest demand measurement.

An obligation is what we have promised to pay, including promises that outlast the reason we made them. A monthly subscription can end at the next renewal if we cancel it under its terms; simply stopping use may leave it running. A multi-year commitment made in exchange for a discount can bind us long after the workload that justified it has moved on. One enterprise agreement may exchange a discount for a minimum spending commitment; another may offer a discount only after a usage threshold is reached, without creating the same payment obligation. The contract determines which one we have.¹ Some obligations come with ownership: a private data center has to refresh its hardware periodically to stay reliable, whether or not demand grows. The capacity team’s job is to know all of them and to answer one question for each: if the workload disappears, which part of the payment can disappear with it, and when?

Azure’s savings plan for compute makes this concrete. The customer commits to a fixed hourly spend for one or three years in exchange for lower prices on eligible compute. Each hour, eligible usage draws down that hour’s commitment, usage beyond it is billed at pay-as-you-go rates, and any part of the commitment left unused expires; the purchase cannot be cancelled or refunded.² So I would evaluate a proposed workload reduction against the hourly commitment and the rest of the eligible usage in its scope. Releasing one team’s resources may let the benefit flow to another workload or may leave part of every hour unused. Either way, the payment stays where it was.

Metering is how consumption gets counted: requests, worker-hours, GB-months, model tokens. A count needs a rate and a pricing rule before it becomes a cost, and a connection to the work the business wanted done before it says anything about value; an application can produce plenty of billable activity without accomplishing anything useful. Some meters need translating before anyone can reason about them. A raw token count does not say which model produced it or at what reasoning effort, and those choices change what the same count costs and accomplishes. Chapters 7 and 8 work through that translation, territory the FinOps community calls token economics.

A cash consequence is the payment a change alters, and when. Cost is what a period consumes; cash is what leaves the bank, and the two run on different schedules. The savings plan above costs the same in total whether it is paid up front or monthly, but the first month’s cash is very different. Owned equipment is paid for when it is bought and reaches the cost view a period at a time as it depreciates. A provider credit can lower one invoice without changing anything that runs. Before I tell Finance that a change saves money, I want to know which payment changes, by how much, and from what date.

Modeled labor is the people’s time a change consumes or releases, valued at a rate the planning model sets rather than read from an invoice. It rarely corresponds to a change in payroll. Asking an existing team to absorb new operating work can leave cash spending exactly where it was while delaying something else that matters, which is why the time belongs in the comparison even though it never appears on the bill.

A migration proposal tests all six at once, because usage charges, existing commitments, operating work, shared costs, and temporary overlap can all be folded into one attractive comparison. Rather than spend the meeting debating whether a line is technically fixed or variable, I would follow the proposal through time: which expenses disappear, which remain, which move to somebody else, and which we are about to create.

Open full-size diagram ↗

A bill we can follow

The organization behind the bill is deliberately generic: a company that sells products and services over the internet, in an industry we never have to name. Customers reach it through its website, where most of the public demand arrives. Behind the site sit several critical databases holding customer, order, and product records for several million customers, and around that core is a setup typical of a business run in the cloud: compute pools sized to demand, managed services where the premium pays for itself in avoided operations work, long-lived internal platforms, the support assistant, and a modernization project moving a legacy system out.

Here it is as a thirty-day operating-cost view, reduced to the parts the rest of the book follows. The amounts are chosen to be plausible, not drawn from market prices or any organization’s actual spending.

The 64 web workers run the application behind the website: they prepare pages and handle sign-in, catalog, cart, and checkout requests. Session information lives outside the individual workers, so losing one does not erase a customer’s session, although the databases and other shared services have failure conditions of their own. The workers carry a constructed all-in resource charge of $40 per worker-day, one blended effective rate for the example: 64 × $40 × 30 = $76,800. The eight compatible batch workers run deferrable jobs — report generation, reprocessing, work that can wait a day without a customer noticing — at the same charge: 8 × $40 × 30 = $9,600.

The data platforms line deserves a quick sketch, because $120,000 hides several kinds of expense. Object storage for images, documents, and exports is a small part of it. Most of the modeled cost sits in the systems serving data to applications: a relational database holding orders and customer records, a Cassandra-style wide-column cluster for high-write event and session data, a document store for catalog content, and the caches and queues in front of them. Each has its own capacity behavior, maintenance rhythm, and price curve, which is why Chapter 12 gives data a chapter of its own. The other rows are stated amounts; later chapters build up the ones that need detail from the units those workloads bill.

It is worth being exact about what kind of number each line is. Purchased services appear at effective charges: negotiated discounts, reserved rates, and savings plans are already applied, and the commitments behind them are assumed to be fully used. The private data center’s lines are an allocated thirty-day share of what it costs to run, including equipment that was paid for when it was bought; they are not invoices. Staff costs are excluded. This is a view of the cost the period consumed, not of the cash that left or the invoices that arrived, and it is deliberately incomplete.

I am using thirty days so that the calculations are easy to reproduce, and for analysis a fixed day count is often a better place to start than a calendar month. If every charge accrued daily at $448,000 ÷ 30 ≈ $14,933, a twenty-eight-day February would come to about $418,100 and a thirty-one-day March to about $462,900: a $44,800 difference, nearly 11 percent of February, with no change in any workload. A fixed-day run rate removes that movement, so the variation you do see is more likely to mean something. An operating report still has to agree with the period Finance is closing, including partial periods, credits, currency conversion, and adjustments, so the run rate belongs alongside the report rather than in place of it.

The effective-rate basis matters twice. Engineers often can’t see the negotiated rate sheets, so a team checking its own list-price estimate against this table can mistake the discount for a disagreement. And a migration or a large reduction in consumption puts the discount itself in play: where it depends on a commitment or a usage threshold, ask first whether those conditions still hold after consumption falls. A reduction that looks like a saving at a line’s effective rate can raise the total if it takes the enterprise below a threshold and the remaining usage loses its discount.

A small number of teams dominate cost

The largest lines — the data platforms behind the website, the transaction-facing workers that serve it, and the AI assistant that drafts support replies — belong to two or three teams running the features customers actually touch. Together they account for $296,800 ÷ $448,000, or about 66 percent of the bill. The $60,000 shared-platform line works differently: one internal platform, run by a central team, where any employee can deploy a small application to support accounting, planning, or another department’s workflow. No single application costs much, and the thousand internal customers behind the line cannot all reasonably take part in each cost decision. When later chapters refer to the long tail, this is what they mean. That is the distribution we have constructed here; in a real portfolio, measure the concentration before deciding which consumers need individual attention.

Attributed to the teams that own the work, the same bill splits differently. The AI assistant’s model access stays with the assistant’s team, while its retrieval and its evaluation-and-platform charges go to the teams that run those services, and the shared network and observation line divides into a network team and an observation team:

The three largest teams — data platforms, the AI support assistant, and the web service — account for ($120,000 + $80,000 + $76,800) ÷ $448,000, or about 62 percent of the bill, and the smallest of the ten named teams is attributed $8,000. The $60,000 remaining line belongs to no single team: it is the long tail, spread across roughly a thousand internal application owners, any one of whom could stop deploying tomorrow without a visible dent in the total.

Open full-size diagram ↗

The AI line is worth a second look. Its $100,000 is $80,000 of model access and $20,000 of supporting infrastructure. The model access is $68,000 of subscriptions and API commitments for the frontier models the assistant uses, which it reaches through Provider B, plus $12,000 of metered token charges for calls those commitments do not cover. The supporting infrastructure is $12,000 for the retrieval service and search index and $8,000 for evaluation runs and the platform the assistant runs on. Model access is most of the cost, and most of that is committed before the first support ticket of the month arrives.

Now look past the amounts to the work. The migration needs a credible way to stop paying for the old environment. The data platforms need someone who understands their maintenance and recovery requirements, while the AI support assistant needs a clearer account of what it is accomplishing. The long tail needs an owner who can improve the shared platform without calling every application user into a meeting. A single instruction to reduce utilization or cut each line by the same percentage would avoid all these questions, which is precisely why I wouldn’t trust it. Even ranking by expense takes care: a small shared component may be holding up several much larger services, and a conspicuous database bill may reflect an obligation that is expensive for a good reason.

Where it runs

Grouped by where it runs, the bill shows the hybrid footprint the introduction described: two cloud providers, Provider A and Provider B, and the private data center the organization operates itself. ($142,800 + $208,000) ÷ $448,000 is about 78 percent of the bill on the two providers, roughly four-fifths, and the rest at home.

Most of the split follows the work. The transaction path and both migration environments run on Provider A, which is also retiring the virtual-machine types the legacy system runs on. The serving layers behind the data platforms and the AI assistant run on Provider B. The relational store holding customer and order records stays in the data center, where its recovery arrangements are long-standing, alongside the shared internal platform. The network line is heaviest where the traffic is: database and AI traffic on Provider B, application traffic on Provider A, internal platform traffic at home.

This is the commercial view. Each provider is a separate agreement, with its own discounts, commitments, rate card, support terms, and announcements, and the data center adds its refresh cycle. The same change can look different under each. Moving consumption from Provider A to Provider B does not reduce what we have already promised Provider A, because where an agreement carries a minimum, that floor belongs to the agreement, not the workload.

Location also creates costs no other view shows. The web workers on Provider A read from serving layers on Provider B, and traffic between providers is metered and priced as well as felt in latency.

How the charges behave

Grouped by how each charge behaves, the bill splits into a committed or fixed floor and a usage-sensitive amount. The floor includes subscriptions, commitments, minimum payments, and private infrastructure costs we assume remain for the period; the usage-sensitive amount can vary with consumption. Both can involve metered usage. Seasonality is a property of demand, shown alongside the split rather than as a third category.

Read the total row first: $281,500 ÷ $448,000 is roughly 63 percent held fixed for this period, and $166,500 ÷ $448,000 roughly 37 percent modeled as usage-sensitive. That is a starting estimate of what can move, subject to the actual agreements and the technical steps needed to reduce consumption. “Fixed” also means fixed for this period, not forever: the legacy system’s $24,000 ends when it retires, a subscription at its renewal, a commitment at the end of its term. In the assistant’s row, support volume rises and falls with customer activity, but the $68,000 of subscriptions and commitments and the $20,000 of supporting infrastructure do not, so the $12,000 of metered tokens is the part that moves. Half the web workers’ cost sits under a committed-use agreement and half is assumed to vary with worker-days. The shared platform runs entirely in the data center, but $18,000 of it still moves with use: the facility’s power and cooling are billed on metered consumption, and some of its software is licensed per core or per request. Those proportions belong to the example, not to cloud computing in general. The seasonality column matters for a different reason: a budget built on an average month will be wrong in the busy weeks and wrong again in the quiet ones, in opposite directions.

The floor is where the obligations described earlier appear. What we can renegotiate, and with whom, depends on which agreement each charge sits under, and a commitment that looks like fat in this view may be the discount that makes every other line possible.

Open full-size diagram ↗

Who funds it

One more grouping answers a question none of the others can: whose money is this? One bill arrives, but it is funded from several budgets, and the funders are not always who the technical organization assumes.

The support organization funds the whole AI assistant because the assistant drafts its replies; the retrieval and platform teams that run pieces of it appear in the attribution view, not the funding view. The modernization program funds both migration environments, and program money has a horizon: when the program ends, the new system needs a home in an operating budget, a conversation that has not happened yet. The batch workers are funded by the operations and finance reporting function: $9,600 over thirty days, inside a $448,000 bill.

It is easy for a technical organization to believe it has a budget — one number somebody granted to engineering — and in a limited sense it does. But the business funds its priorities through different budgets, and the technology carries them. That matters for the change we follow next. Moving the batch workers to the web service leaves the enterprise total unchanged while moving $9,600 in both the work view and the attribution view. Whether the funding moves from the reporting function to the website product line is a separate agreement between their budget owners; reassigning workers does not authorize it.

Follow a change across the boundary

The business wants to roll out new functionality on the web service, and one possible bridge is to move the eight batch workers into it temporarily. Over a thirty-day transfer, that adds $9,600 to the service’s attributed resource cost and removes $9,600 from the batch allocation. The web service now shows $76,800 + $9,600 = $86,400, while the enterprise still shows $448,000.

Open full-size diagram ↗

What the transfer doesn’t say is what happens to the batch jobs; the work doesn’t disappear when its workers do. With all eight workers gone for the whole interval, none are left in this pool even for less frequent runs, so the jobs need an agreed window, another qualified place to run, or an agreed deferral. The transfer neither buys a worker nor reduces the total resource charge, but before anyone calls it free, somebody has to talk to the person whose work will wait. Perhaps the delay is harmless within an agreed window; perhaps the backlog will need extra capacity to catch up. Until we know, the consequence is unpriced, and leaving it unpriced is different from declaring it zero. The $9,600 describes where the workers went, not what the organization gave up to send them.

Now suppose sixteen additional workers become available. At the same constructed charge they add 16 × $40 = $640 per day, or $19,200 over thirty days, and if nothing else changes and no commercial arrangement offsets the increment, the modeled total becomes $467,200. That is an estimate to take into the commercial discussion, not a prediction of the invoice. Even the $40 charge is an assumption, because workers bought on demand usually cost more than workers covered by a commitment, and the agreement, effective date, and payment terms still decide what is paid and when.

New services don’t have to be zero-sum, and it is worth knowing which kind of change this is before spending a meeting hunting for an offset. When the additional work is worth doing, estimate the increase and say so. A quick look at how existing costs could adapt is still worthwhile: sometimes it finds a frequency that can drop or a pool that can shrink, and sometimes it confirms the estimate. What the review must not do is let an increase and a reallocation pass for the same decision.

Approving the expenditure won’t shorten the supply lead time. You can have agreement on the economics and still have a launch arriving before the workers are ready; Chapter 4 follows the gap that opens. This is why I resist separating purchasing strategy from consumption so completely that nobody follows the decision across both. Different specialists can own different parts of the work, but they need to evaluate the same change: what we buy affects the economics of later usage, and what engineers change affects the usefulness of what we already bought.

The invoice leaves things out

People are the most obvious expense missing from a resource-only comparison, and adding a headcount line rarely settles the question. An architecture can create patching, upgrades, on-call work, and a need for specialist knowledge. Finance and engineering need to be able to discuss that work without pretending either that a new hire is inevitable or that an existing employee’s time is free.

Take a separate, hypothetical proposal that reduces resource charges by $5,000 a month and adds recurring work estimated at half of one person’s available time. If the planning model values a full year of that person’s capacity at $240,000, the allocation is 0.5 × $240,000 ÷ 12 = $10,000 per month. We have found $5,000 less in resource charges and $10,000 more in modeled labor consumption.

I would not turn that into a claim that cash spending must rise by $5,000. I would ask whether the team has room for the work and what it would otherwise be doing. If there is available time and the change is valuable, the proposal may be perfectly sensible. If the same people are already postponing critical maintenance, the staffing assumption deserves considerably more attention than it received in the savings slide.

Migration adds another complication. In this constructed history, the legacy system was built about thirteen years ago on virtual-machine types that Provider A is retiring. The provider has made it clear, politely and repeatedly, that those SKUs are on the way out, which turns the migration from a preference into a deadline with someone else’s signature on it. The replacement is a container-based system, a two-year-old project still moving customers across. The $24,000 old environment and the $18,000 new one overlap because customers have to move and results have to be verified before the old one can stop. The overlap is larger than those two lines, though. The move includes a change of database, so the new store must be provisioned and populated while the old one still serves customers, and that duplication sits inside the $120,000 data-platform line. Chapter 13 examines double bubbles like this one and their payback. For now, all of it belongs in the current view, however much we would prefer to show only the architecture we intend to have when the migration is finished.

The invoice is also silent about the consequence of a backup that cannot be restored in time, or the value of keeping a launch option available. These are important omissions, but filling them with a convenient expected-loss number does not improve the analysis. We can measure an expense and describe an exposure while acknowledging that the business judgment remains with someone who understands the obligation and has authority to accept it.

A quiet system is a question

If you want an impressive savings total quickly, add a waste column to the inventory and populate it from an average utilization threshold. You will have a number before you have learned much about the systems, which is the problem. That quiet resource could be abandoned, waiting for a scheduled operation, preserving a recovery option, or sitting oversized because nobody has yet done the work to establish a safer configuration.

Not understanding a resource is a reason to investigate it; it is a poor basis for either deleting it tomorrow or protecting it indefinitely. I would start with the person who can explain what the resource supports and when it will next be needed, then work with the relevant specialist to establish what could change safely. The recommendation should say what the change releases, whether releasing it changes any payment, and whose work would be affected, so that the resulting number means more than “the average looked low.”

Sometimes this takes five minutes. If a disposable test environment has finished its job, its owner confirms that nothing else depends on it, and the relevant records and obligations are dealt with, retire it through the normal change process. We don’t need a symposium on uncertainty for every forgotten experiment. The reason to distinguish easy cases from difficult ones is to leave enough time for the difficult ones, like the Cassandra cluster in the Introduction: 1 to 2 percent CPU, and a business depending on it around the clock.

The same bill, five ways

Open full-size diagram ↗

The five views group the bill; the six dimensions from the start of the chapter describe each expense inside it, and cash timing and labor are the two that none of the five tables shows. A proposal can be perfectly clear in one view and misleading in another, which is why a capacity and cost management team holds all five at once and knows which conversation each table is for.

Five tables do not make five problems. Economists have a useful precedent here. Franco Modigliani and Merton Miller showed in 1958 that, under idealized conditions, the way a firm divides claims on its business between debt and equity does not change the value of the business underneath.⁴ Real taxes and frictions make financing matter in practice, and I use the result only as an analogy, not as a claim that cost and capacity behave like debt and equity. The habit of mind is what carries over. When the financing changes, the useful question is what changed in the operating business: its customers, products, and cash flows. When the bill is regrouped, the useful question is what changed in the consumption that produced it. Don’t mistake different projections for different realities.

One problem, two dashboards

The same mistake can be made by a whole organization. Take a hypothetical cloud service whose infrastructure spending rises from $100 million to $130 million in a year. Leadership calls it a cost problem and asks the FinOps team to bring spending back to $110 million. The team buys commitments, removes idle resources, raises utilization, and moves workloads to cheaper SKUs, and it succeeds. Six months later, an availability incident occurs during a demand spike, because the headroom that would have absorbed it is gone. The capacity team now asks for 25 percent more resources.

The organization sees two failures, one in cost control and one in capacity planning. I would call it one failure: nobody understood the system that was driving consumption. Suppose 10 of the 30 points of increase were waste, and 20 were legitimate customer growth and resilience requirements. Then $110 million was never a rational target, because the intervention optimized an output without understanding its cause. The economist Charles Goodhart described the general hazard in 1975: “any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” The anthropologist Marilyn Strathern later gave it the form people remember: “When a measure becomes a target, it ceases to be a good measure.”⁵ Spending was a reasonable measure of the system until leadership made it the target. The reverse happens too, when capacity requests are granted without anyone asking whether an inefficient architectural pattern is producing the growth.

A cut and a reduction can look alike from across the room, because both take things away. Rick Rubin’s test from the Introduction tells them apart: how many pieces can you remove before the work ceases to be the work? Forcing the bill back to $110 million removed pieces past that point, and the incident was the service ceasing to be the service it had promised. Finding the 10 points of waste and keeping the 20 points of growth and resilience would have been a reduction.

A cost problem and a capacity problem can be the same problem arriving through two different dashboards. You can manage cost well and still make the system fragile. You can manage capacity well and still make the system economically absurd. What you cannot do is manage the system well without understanding both, and without knowing what capability the spending is supposed to buy.

Ten times the bill

Before the portfolio goes to the rest of the book, look at the same bill ten times larger. Multiply every line in every view by ten and the thirty-day total becomes $4,480,000; at the same daily rate, $4,480,000 ÷ 30 × 365 is roughly $54.5 million a year. The five views keep their shape at either size. What changes is who shows up.

At that size I would expect contract negotiations and account relationships to get sustained attention, although spend alone does not guarantee a particular discount or account team. Renewals, renegotiations, and provider announcements become someone’s actual job rather than a line in somebody’s quarter. The long tail that cost $60,000 per thirty days now costs $600,000, about $7.3 million a year, which merits a named owner for the shared platform. And the discount question sharpens. If a proposal gives up a discount worth five percent of the run rate, the cost is about 0.05 × $54.5 million = $2.7 million a year, and no line-item review will show it, because the discount belongs to the agreement rather than to any line. The obligations stay the same kind and grow in consequence. Volume II, Chapter 23 takes the portfolio through the larger bill; Volume II, Chapters 18, 20, and 24 take up reserves, commitments between organizations, and the markets forming around compute.

Enough information to have the next conversation

An unknown owner needs investigation. A shared allocation needs an agreed method, and if we change that method, we need to reconcile the movement so that reallocating an expense doesn’t earn us credit for eliminating it. These are ordinary bits of housekeeping until a large reported saving depends on them; then they become the difference between useful evidence and a number that everyone has begun repeating.

Standard billing data can supply much of the record’s raw material. The FinOps Foundation’s FOCUS specification gives cost-and-usage records a common form across providers, carrying list, contracted, billed, and effective cost side by side, so the gap between an engineer’s list-price estimate and an effective-rate ledger can be shown rather than argued. Version 1.4, ratified in June 2026, adds an invoice-detail dataset and expands the contract-commitment dataset, bringing payment terms and commitment details closer to the same records.⁶ Provider exports can lag the specification, so check which version yours implement. Comparable data still needs people who can explain a disputed shared cost, say why a commitment was made, or decide whether an expense serves a worthwhile purpose.

Cost, then, is more than a bill to be optimized. It reflects agreements and operating obligations: commitments, subscriptions, minimums, and the refresh cycles needed to keep a platform useful. It is a political situation, because attribution and funding decide who is answerable; a technical one, because only the people who run the systems can say what would actually change; and an organizational one, because the business funds its priorities through different budgets, however uniform the bill looks from inside the technology organization. Holding five views of the same money is how we keep all of that in front of us, because an omitted view can hide the condition that changes the decision.

For our portfolio, we can now explain the web service’s cost and calculate the charge for additional workers. The proposed demand has changed, though, and before we recommend buying anything we need to know what the existing service can deliver, including when some of its workers are unavailable. That requires a conversation about what we have promised the customer, which is where a price calculation starts to become a capacity decision.

Notes and sources

1. Google Cloud, “Structure of Standard data export”, checked October 3, 2026. The documented credit types distinguish resource-based and spend-based committed use discounts, discounts earned after a contractual spending threshold is reached, and sustained use discounts that require no commitment. These examples show why a discount alone does not establish a minimum payment; the particular contract governs the obligation.↩︎

2. Microsoft Learn, “What are savings plans?” and “How a savings plan discount is applied”, both checked October 3, 2026. A fixed hourly commitment for one or three years; eligible usage draws down each hour’s commitment, usage beyond it is billed at pay-as-you-go rates, and unused commitment expires; purchases cannot be cancelled or refunded; up-front and monthly payment carry the same total cost. This is vendor documentation of the offer, not of any particular contract; the portfolio comparison is the author’s analysis.↩︎

3. Charles T. Horngren, Srikant M. Datar, and Madhav V. Rajan, Cost Accounting: A Managerial Emphasis, 15th ed. (Pearson, 2015), chapter 5, “Activity-Based Costing and Activity-Based Management”: broad averaging, or peanut-butter costing, spreads resource costs uniformly across products or services that use those resources non-uniformly, overcosting some and undercosting others. The application to shared cloud costs is the author’s.↩︎

4. Franco Modigliani and Merton H. Miller, “The Cost of Capital, Corporation Finance and the Theory of Investment”, American Economic Review 48, no. 3 (June 1958): 261–297. Proposition I holds the market value of a firm independent of its capital structure under the paper’s assumptions, before taxes. The application to cost and capacity is the author’s analogy.↩︎

5. Charles A. E. Goodhart, “Problems of Monetary Management: The U.K. Experience,” in Papers in Monetary Economics, vol. 1 (Sydney: Reserve Bank of Australia, 1975; published 1976), 5, as quoted in Carolyn J. Moses, Financial Innovations and Monetary Policy: A Preliminary Survey, Research Discussion Paper 8301 (Reserve Bank of Australia, May 1983), checked October 4, 2026; Marilyn Strathern, “‘Improving Ratings’: Audit in the British University System,” European Review 5, no. 3 (1997): 305–321, at 308. Strathern notes that Hoskin had given the idea the name Goodhart’s law.↩︎

6. FinOps Foundation, FOCUS Specification 1.4, ratified June 4, 2026; Shawn Alpay and Matt Cowsert, “Introducing FOCUS 1.4: Invoice Reconciliation, Commitment Details, and Specification Maturity”, FinOps Foundation, June 10, 2026; both checked October 3, 2026. The Cost and Usage dataset carries List Cost, Contracted Cost, Billed Cost, and Effective Cost; version 1.4 adds Invoice Detail and Billing Period datasets and expands the Contract Commitment dataset, introduced in 1.3, from 13 to 30 columns. When checked, the FOCUS home page listed the AWS, Microsoft Azure, and Google Cloud exports at version 1.2. The allocation and decision practices described here are the author’s recommendations, not claims that the specification resolves business ownership.↩︎