What Scale Brings

A lot of writing about cloud capacity assumes a bill of $10,000 or $100,000 a month. Multiply either by a hundred, the range this chapter works in, and even the most basic decision about which data center a workload goes in can drive the economics of the provider’s decisions. The book has used a deliberately modest portfolio, small enough to inspect in a spreadsheet, though a real $5.45 million operation is not simple to administer: criticality, technical variety, jurisdictions, and the number of owners matter alongside the bill. The arithmetic below is the constructed portfolio multiplied by ten.

How to read this chapter

This chapter keeps Volume I, Chapter 1’s promise: the same portfolio at ten times the bill, and what changes with it.

1. The portfolio at ten times the bill — $4.48 million over thirty days, about $54.5 million a year, and what straight multiplication hides.
2. What the number buys, and what it costs — commitments that stack, how much demand is stable enough to promise, and when sizing is a bet.
3. One owner’s decision, another owner’s agreement — a model change that leaves a shortfall in someone else’s budget, and migrations that never arrive.
4. The obligations grow their own management — an obligation register built from the ledger and checked against its committed floor.
5. Where the provider’s planning begins — what a large request asks of a provider, and why the larger ask needs the longer commitment.
6. Where I would start — what each view needs at this size, and the first steps I would take.

The lesson to carry: at scale, one agreement can pool decisions made by owners who do not share a budget, so keep a register that shows whose decisions can move each one.

The portfolio at ten times the bill

The funding view scales the same way. The support organization’s $1,000,000 includes $800,000 of model access, mostly subscriptions and API commitments, and the long tail on the shared platform, $600,000, is still about 13.4 percent of the bill. Volume I, Chapter 1 argued that the tail merits a named owner, and Chapter 15 shows how that owner works through cohorts rather than individual applications.

Straight multiplication is the one kind of growth that changes only the amounts. The larger ledger still has eight lines, three locations, five funders, and the same agreements. I would not expect a real $54.5 million portfolio to look like that; I would expect it to have grown mostly by addition, through more products, teams, accounts, regions, and agreements. Several burdens grow with that count rather than with the bill: commitments with their own terms and expiry dates, owners whose plans have to reach the capacity team, and places where one team’s consumption counts toward another team’s agreement.

Multiplication also leaves the failure geometry alone. If the 640 workers kept Chapter 18’s four failure groups, each would hold 160 workers, two and a half times the smaller portfolio’s whole pool, and the largest group would still set the deduction: a quarter of the pool, $768,000 ÷ 4 = $192,000 of every thirty days, paid for so that three groups can carry the load when one fails. With eight groups of 80 the deduction falls to an eighth, so the same promise needs a smaller pool, provided the groups really fail independently, which Chapter 19 warns that different addresses do not establish, and someone has priced the placement, data paths, and operation of twice as many groups. At this size I would choose the number of groups deliberately rather than inherit it.

What the number buys, and what it costs

At this scale the agreements stack. The largest may be a consumption commitment across a whole account, such as the Microsoft Azure Consumption Commitment in Chapter 20: eligible services and Marketplace offers draw down a total over the term, and an unmet milestone or final balance is charged as a shortfall.¹ The reservations and savings plans of Chapter 20 sit beneath a commitment like that and capacity reservations beside it, so one charge can count toward several promises at once. The FinOps Foundation’s FOCUS billing specification records exactly that: a charge can carry the identifiers of more than one contract commitment, measured in money or in units such as compute hours.² Each promise is exposed to a different kind of variation: a savings plan to the shape of each hour, as Chapter 20 showed; a consumption commitment to the running total at its milestones and end date; and a capacity reservation to the location and size it holds.

The proportion survives multiplication because multiplying a line by ten multiplies its swings by ten as well. Growth by addition can help, up to a limit set by correlation. By Chapter 15’s variance formula, a hundred similar workloads that vary independently vary a tenth as much, relative to their total, as one does; if each pair is correlated at 0.25, the total’s relative variation never falls below half of one workload’s, however many we add. Our largest lines answer to the same customers, promotions, and holidays, so I would expect them to move together, and a commitment sized as though they diversified would exceed what their combined demand can reliably reach. Providers rely on the same arithmetic at far larger scale: Microsoft counts data centers that “aggregate diverse customer, geographic, and application demand patterns” among its economies of scale.³ An enterprise whose demand mostly follows one business cycle cannot buy that diversification by growing.

Sizing is sometimes a bet. A team says it needs a certain amount, and you know enough about what it is doing, and about what the business needs, to size differently. That can mean sizing down to a ramp, as in Volume I, Chapter 2. Sometimes it means talking to the business independently about what the engineering team is doing, because the team may not understand how much capacity it really needs, and then multiplying the team’s number by a factor so that the provider gets the right signal. It isn’t something you want to do a lot.

One owner’s decision, another owner’s agreement

In the constructed portfolio, Provider B carries $2,080,000 of the thirty-day bill, about 46 percent, and the AI assistant accounts for $1,000,000 of that, about 48 percent of Provider B. That concentration is the source of our negotiating position with Provider B, and of the hardest commitment decision in the ledger.

For a consumption commitment, the larger risk is usually a decision rather than noise. Volume I, Chapter 1’s location view puts the whole assistant line in Provider B’s column, so in this ledger the assistant reaches its frontier models through Provider B. Suppose Provider B offers a better rate in exchange for a minimum annual spend. At ten times the bill, Provider B’s consumption is $2,080,000 ÷ 30 × 365 ≈ $25.3 million a year, and the assistant’s model access is $800,000 ÷ 30 × 365 ≈ $9.7 million of it. Without the model access, about $25.3 million − $9.7 million = $15.6 million remains. Every dollar of minimum above that figure depends on the support organization continuing to buy its models through Provider B. Its evaluations, run the way Volume I, Chapter 8 recommends, might find a better model that Provider B does not offer, or the model’s developer might offer better terms directly. Switching would then look right from the support budget, and the enterprise could pay for the model elsewhere while still owing Provider B for spending that no longer exists.

I would not answer this by forbidding the support organization to change models. I would size the minimum with the movable lines identified, prefer a milestone schedule the organization could still meet if its largest movable line left, and check which purchases count toward the commitment; in Microsoft’s version, eligible Marketplace offers do.⁴ Then I would put the agreement’s owner in the room whenever a model change of that size is evaluated. Chapter 20’s break-even arithmetic applies to whatever minimum results.

What I have actually seen, more than once, is a migration that doesn’t happen. We gave a provider a signal that a migration would happen by a date; the date passed without it, and a year later the migration still hadn’t happened. If you can give that signal without a contractual commitment, do. If you do have to commit, you end up with spare capacity that you then have to do something with. This happens quite a bit with private cloud run alongside public cloud, where hardware bought at scale is the commitment: it sits there and has to be used. If internal customers don’t move onto it, whoever built it is responsible for filling it, and a capacity team that has built out a large part of a data center becomes a sales team, going from project to project to advocate for consumption. That’s a tough job, because capacity professionals are not salespeople.

Splitting the decision to use capacity from the agreement to pay for it is one of the biggest problems in this work. Without the right management in place, the capacity team ends up holding the bag for an engineering team’s decisions about SKUs or locations. My recommendation is for the capacity team to stand alongside Finance and alongside Engineering and build a bridge of data between them, connecting engineering decisions to their financial outcomes as closely as it can; otherwise missed migrations and failed commitments can blow everything up. The people who pay for capacity should be the people who use it. Find a way to make that true.

The FinOps Foundation’s Rate Optimization capability describes the early-maturity form of this problem exactly: commitment purchases by “multiple teams who own their own budgets” acting “without coordination.”⁵ Capacity planning adds what billing data cannot answer: which workloads could leave an agreement, what each instrument holds as supply rather than as price, and whose decision would move the balance.

The obligations grow their own management

Here is how I would begin the register for our ledger. Every entry comes from Volume I, Chapter 1’s views at ten times the bill, and the last two columns hold what an invoice will not tell us.

The amounts overlap, since one charge can sit under several promises, so the test of completeness is that every charge in the charge view’s committed or fixed floor, $2,815,000 per thirty days at this size, traces to an entry. A gap means an obligation nobody has listed or a fixed cost nobody can explain. Each entry also needs three owners by name: the commercial owner who can renegotiate it, the technical owner who knows what consumption it depends on, and the funder whose budget absorbs a shortfall. For the larger agreements I would add the teams whose decisions can move the balance; that list is how the Provider B problem becomes visible before the true-up instead of at it.

The third column is where the register earns its keep, and Chapter 20’s table of what each arrangement owes and holds gives it a vocabulary. If the data platforms’ commitments work like Azure’s reservations for SQL Database, they buy a discounted price. Microsoft’s documentation says such a reservation does not pre-allocate or guarantee specific infrastructure and does not renew automatically, so the databases return to pay-as-you-go prices at the end of the term.⁶ Recovery capacity has to be secured some other way. Volume I, Chapter 7 draws the same line for model access, between arrangements that reserve throughput and spending commitments that do not.

Providers increasingly supply the commercial columns. Azure shows a consumption commitment’s dates, balance, and drawdown in the portal and through its APIs, along with the expiry warnings Chapter 20 described.⁷ Billing administrators are rarely the people choosing the next model or migration date, though, so the ownership and supply columns still come from us. Finance needs each entry’s payment form too: a reservation may be paid up front or monthly,⁸ a refresh usually arrives as a capital purchase, and a missed milestone as a shortfall charge, none of which a thirty-day run rate shows.

The migration belongs in the register as well. Volume I, Chapter 1’s old and new environments, $24,000 + $18,000 = $42,000 per thirty days, become $420,000, and three additional periods at that combined rate cost $1.26 million. That is the overlap bill for the two environments, not necessarily the avoidable cost of the delay: if the new system would run anyway, keeping the old one for three more periods adds $240,000 × 3 = $720,000 before other transition costs. Volume I, Chapter 13 explains how to tell the two apart, and the review needs both. The register also needs the program’s end date, because when the modernization money stops, the new system’s $180,000 per thirty days needs an operating budget that does not exist yet.

Where the provider’s planning begins

Microsoft’s annual report for fiscal 2026 says its data centers depend on “permitted and buildable land, predictable energy, networking supplies, and servers,” and reports $329.1 billion of leases, primarily for data centers, that had not yet commenced at June 30, 2026, some still subject to contractual conditions, with start dates running from fiscal 2027 to fiscal 2033. On an April 2025 earnings call, Microsoft’s executives said builds and leases had to be positioned for the demand, shape, and location of future workloads, called the path from land to buildout “very long lead time decisions,” and tied server purchases to demand signals that include customers’ contracted backlog.⁹ Those are additional planning problems, with physical schedules and investment decisions that our worker model does not represent.

For the customer, the useful connection is the readiness estimate. Are we asking for an allocation from an existing fleet, new equipment in a prepared facility, or supply that depends on a new site? Microsoft’s account suggests why the answers differ so much: servers can follow demand signals into buildings already committed, while the land, buildings, and power behind them were decided years earlier. A larger spending commitment can help a supplier plan demand; it cannot by itself complete the physical work. The agreement in Chapter 20 must say which supply obligation, if any, accompanies that commitment.

At our size, we need the harder answer more often. Suppose we decide to move our biggest workload from one provider to another. The new provider will be really excited to help us succeed, and it will also take a deep breath and ask for the timeline of the move and some paperwork, to make sure it is ready with the capacity we need at the right date and time. At that level of consumption we may need to sign a commitment, because we are asking a provider to move mountains to get a data center ready for a workload.

Providers like to give the impression that capacity is infinite. It isn’t, especially for AI workloads and specialized hardware. Websites and vendors constantly sell pictures of perfect elasticity, and one provider may be marketing elasticity that another can’t currently provide. All that may mean is that the provider doing the marketing doesn’t have your workload yet, so it hasn’t met the complications.

The general rule is that the larger the ask, the longer the commitment has to be, and the longer it takes to change. People like to say it takes a long time to turn an oil tanker. In capacity, it takes a long time to migrate: moving hundreds of millions of dollars of workload from one data center to another doesn’t happen quickly, and it takes real time for a data center to get ready for that kind of work.

Once real money and real capacity are involved, engineering managers have to know what their contractual commitments are, and they don’t like to be boxed in. Technology is supposed to be frictionless, free, infinite, and amazing. Telling someone “I need a two-year projection for your capacity, and I’m going to hold you to it” almost runs counter to the way we’ve trained engineers to think, where everything is elastic. At scale, though, you have to have commitments and agreements, and some of them you can’t back out of.

Where I would start

If I inherited this portfolio, I would not start by renegotiating anything. I would build the register from the ledger, reconcile it to the $2,815,000 floor, and mark every agreement whose eligible consumption comes from owners who do not share a budget. Provider B would head that list. Then I would find out when the support organization next plans to evaluate its models, and make sure the owner of the Provider B agreement is in that meeting with the $15.6 million figure in hand. Before the next commitment is signed, I would document upfront how much its decisions and deadlines are going to cost and who is responsible for that cost, because it can’t be the capacity team.

A buyer at this size still negotiates with only its own prices and its own supplier’s answers in view. The last chapter looks at what markets for compute could add to that picture.

Notes and sources

1. Microsoft Learn, “Track your Microsoft Azure Consumption Commitment (MACC)”, checked October 4, 2026. Definition; drawdown by eligible Azure services and Marketplace offers; optional milestones; shortfall charges, as Azure prepayment credit, for an unmet milestone or final balance; portal and REST API tracking; and alerts to billing account administrators 90, 60, and 30 days before an unmet commitment or milestone ends. Portal tracking covers direct Microsoft Customer Agreement and Enterprise Agreement customers only. Other providers’ commitments differ, and the customer’s own agreement governs.↩︎

2. FinOps Foundation, FOCUS Specification 1.4, “Contract Applied”, checked October 4, 2026. One charge associated with one or more contract commitments, with the applied amount in the billing currency or as a quantity in a stated unit. Version 1.4 was ratified on June 4, 2026, according to Shawn Alpay and Matt Cowsert, “Introducing FOCUS 1.4”, June 10, 2026, checked October 3, 2026. The data exists only where a provider’s exports supply it.↩︎

3. Microsoft Corporation, Form 10-K for the fiscal year ended June 30, 2026, filed July 29, 2026, Part I, Item 1, checked October 4, 2026. Lists the aggregation of diverse customer, geographic, and application demand patterns among three economies of scale. The company’s description of its business, not a measurement of the effect.↩︎

4. Microsoft Learn, “Track your Microsoft Azure Consumption Commitment (MACC)”, checked October 4, 2026. Definition; drawdown by eligible Azure services and Marketplace offers; optional milestones; shortfall charges, as Azure prepayment credit, for an unmet milestone or final balance; portal and REST API tracking; and alerts to billing account administrators 90, 60, and 30 days before an unmet commitment or milestone ends. Portal tracking covers direct Microsoft Customer Agreement and Enterprise Agreement customers only. Other providers’ commitments differ, and the customer’s own agreement governs.↩︎

5. FinOps Foundation, “Rate Optimization”, FinOps Framework capability, checked October 4, 2026. The Crawl-stage description quoted in the text. Practitioner guidance, not measured results.↩︎

6. Microsoft Learn, “Save on compute costs with Azure Reservations: Azure SQL Database & SQL Managed Instance”, checked October 3, 2026. A discounted price that does not pre-allocate or guarantee infrastructure; one- or three-year terms; no automatic renewal, with pay-as-you-go pricing afterward; up-front or monthly payment. One provider’s product; Chapter 1’s providers are generic.↩︎

7. Microsoft Learn, “Track your Microsoft Azure Consumption Commitment (MACC)”, checked October 4, 2026. Definition; drawdown by eligible Azure services and Marketplace offers; optional milestones; shortfall charges, as Azure prepayment credit, for an unmet milestone or final balance; portal and REST API tracking; and alerts to billing account administrators 90, 60, and 30 days before an unmet commitment or milestone ends. Portal tracking covers direct Microsoft Customer Agreement and Enterprise Agreement customers only. Other providers’ commitments differ, and the customer’s own agreement governs.↩︎

8. Microsoft Learn, “Save on compute costs with Azure Reservations: Azure SQL Database & SQL Managed Instance”, checked October 3, 2026. A discounted price that does not pre-allocate or guarantee infrastructure; one- or three-year terms; no automatic renewal, with pay-as-you-go pricing afterward; up-front or monthly payment. One provider’s product; Chapter 1’s providers are generic.↩︎

9. Microsoft Corporation, Form 10-K for the fiscal year ended June 30, 2026, filed July 29, 2026, Part I, Item 1 (“Operations”) and Part II, Item 8, Note 13 (“Leases”); Microsoft, FY2025 third-quarter earnings call, April 30, 2025; the filing checked October 4, 2026, the call October 3, 2026. The filing: dependence on land, energy, networking supplies, and servers; $329.1 billion of leases not yet commenced, some subject to contractual conditions, commencing in fiscal 2027 through 2033. The call: builds and leases positioned for demand, workload shape, and location; very long lead times from land to buildout; server purchases based on demand signals that include contracted backlog. Company statements at those dates; they establish no capacity or delivery date for any customer request.↩︎