Without Surprise.
Chapter 20Commitments Between Organizations
Summary PDF

Volume II · Part IV · Chapter 20

Commitments Between Organizations

Timothy O’Brien 17 min read Free online

“We expect to have it in six weeks” is useful information. It becomes a different kind of information when a project plan turns it into a date and a customer announcement turns that date into a promise. By the time the estimate returns to the capacity team, several people may be relying on a level of certainty that the supplier never offered.

Nobody needs to have intended that transformation. Each person used the best information available to move their own work forward while the original answer’s conditions became harder to see. We need those conditions to survive the journey, whether the arrangement is between companies or between teams whose shared company logo conceals different customers, budgets, and obligations.

How to read this chapter

This chapter is about promises that cross organizational lines: discounts, commitments, and the conditions that travel with them.

  1. A discount and a resource are different things — committed spend versus held supply, on Azure and AWS.
  2. Keep an honest channel to each provider — the cadence of the conversation, and failures on both sides.
  3. The internal promise is still a promise — assurances between teams and the external terms behind them.
  4. Follow the borrowed workers to their return — who must agree to an extension, when the answer is due, and whether it can be revoked.
  5. Make estimates travel with their uncertainty — what “available” meant, who said so, and when.
  6. Decide what changes when demand changes — holds for tentative demand and the incentive to release them.
  7. Evaluate the price of certainty — take-or-pay break-even, commitment size, exits, and shortfalls.
  8. When a commitment cannot be met — remedies versus available capacity.
  9. Carry the conditions into the review — keeping commitments and their dates visible after signature.

The lesson to carry: a commitment is a trade of flexibility for terms, and its conditions must survive the journey from the agreement to the bill and the review.

A discount and a resource are different things

Before discussing the price of an agreement, I want to understand what we need it to do. We might want a lower unit rate for predictable consumption, a resource held in a particular location, a delivery window, or priority within a shared pool. A good answer to one of those needs can leave another unresolved.

Microsoft’s documentation draws the line plainly. An Azure Reserved VM Instance is a billing discount, and a deployment can still fail for lack of capacity after the reservation has been bought and the quota approved; an on-demand capacity reservation is what holds a VM size and quantity in a region or zone, and the two can be combined.12 Chapter 18 follows the mechanics of that hold. When somebody tells me “we bought reservations,” I want to know which kind, whether a capacity reservation was actually created, and which parts of service readiness, such as data, network, and the recovery procedure, it leaves untouched.

The vocabulary does not travel well between providers. On AWS, a zonal Reserved Instance reserves capacity in its Availability Zone, while regional Reserved Instances and Savings Plans do not.34 An Azure reservation scoped to one subscription can choose capacity priority, which improves access to capacity without an SLA.56 The word reservation settles very little until we know whose terms we are reading.

Azure and AWS arrangements, as of October 2026:

Arrangement What we owe What we have when supply is short
Spend commitment: Azure savings plan, AWS Savings Plans78 A fixed amount per hour for one or three years No capacity; unused hours expire but are still paid for
Consumption commitment, such as Microsoft’s MACC9 A total over the term, perhaps with milestones; any shortfall is charged No capacity; only eligible spending reduces the balance
Instance commitment: Azure Reserved VM Instance, AWS regional Reserved Instance1011 The reservation price for one or three years, upfront or monthly No capacity; the discount covers only what we can deploy
Capacity reservation: Azure on-demand capacity reservation, AWS On-Demand Capacity Reservation1213 The on-demand rate for the reserved quantity, used or not; discounts can apply The reserved size and quantity in one region or zone; Azure’s SLA remedy is a service credit
Dated capacity: AWS Capacity Blocks for ML, future-dated Capacity Reservations1415 Blocks: the full price upfront, no cancellation. Future-dated: the on-demand rate for a minimum term, usually 14 days The reserved instances for the booked period; a future-dated request can be delayed or declined before it starts

Only the last two rows hold supply, and only for the size, location, and period written into them. The first three change what we pay.

The table thins out where supply is scarcest. As Volume I, Chapter 2 noted, Azure’s capacity reservations do not currently support ND-series or NCads H100 v5 GPU sizes, and AWS’s future-dated reservations exclude its P-family GPU instances, whose scheduled route is the Capacity Block Volume I, Chapter 10 describes: at most 64 instances per block, booked no more than eight weeks ahead, at a price set by supply and demand.161718 Beyond that I would expect a negotiation, and the negotiated paper needs the same reading. Some of it may be a contracted commitment from us: “we have committed to use this many cores of this SKU by this date in these data centers.” If you can avoid that commitment, great; sometimes it is only a promise, not a contract. Capacity reservations, the paper that holds supply, are very important, especially for AI.

Procurement and Engineering can each answer their own question well and leave the combined one open: excellent financial terms on a service still exposed to a supply constraint, or resources arranged without appreciating the payment that survives a cancellation. A quota increase, as Volume I, Chapter 2 showed, may permit a larger request without guaranteeing fulfillment, and a budget approval permits spending without establishing supply. The customer needs to know which step has actually been completed before promising a service to somebody else.

Keep an honest channel to each provider

Paper is only part of the arrangement. I would meet each major provider at least monthly about consumption, forecast, and predictions, and in my experience being on the phone every few days is actually very helpful. At scale there is most likely a team at the provider dedicated to your capacity and cost, so use it; if not, you probably have a representative who wants to talk often, so take them up on it.

The relationship does not have to be great, and sometimes it cannot be, but it has to be honest. You cannot treat a provider as being there to serve every need without question; the relationship takes conversations, negotiation, and some empathy for the provider’s constraints, especially for GPUs. Both sides will fail. We will fail to predict demand in a way that causes the provider problems, and the provider will make a bad assumption that causes us problems. For those moments we need an honest, direct channel that does not require looping in the CTO every time. Chapter 17 describes the reciprocity that keeps it open.

The internal promise is still a promise

A platform’s informal assurance can travel almost as far as a commercial agreement. A product team that hears capacity will be available may make promises downstream, just as a batch team lending resources may rearrange work that somebody else is waiting for. The lack of a commercial remedy does not make a missed internal promise particularly gentle.

An internal promise usually rests on an external one and should not claim more than stands behind it. A platform that calls its capacity guaranteed while holding a savings plan and a quota approval has promised more than its supplier promised it. Its own headroom or priority may cover the difference, but the product team should know which is doing the work.

I would keep the agreement short enough that the people relying on it can read it, but specific enough to establish the resource or service, quantity and unit, placement, readiness date, duration, quality or failure condition, and payer. It also needs the authority to change the arrangement and the demand assumption behind it. If the plan works only for a staged rollout, that condition is doing more work than another list of administrative approvals.

The detail should grow with the consequence. A small, reversible experiment might need an allowance and a person to contact when it approaches the limit. A customer taking a large share of a constrained pool needs a clearer account of what is being held, and a critical service may require evidence of readiness and a prepared response if the promised condition cannot be met. The important customer does not automatically receive everything it asks for, but the answer, yes or no, deserves more than an informal estimate.

Follow the borrowed workers to their return

Volume I, Chapter 4 found the gap in our constructed portfolio: the loan covers day 2 up to the start of day 32, once the eight workers have been prepared and tested, and the replacement group’s day-42 estimate already includes delivery, preparation, and qualification. Chapter 18 priced the extensions: $9,600 of attribution for the agreed thirty days, $12,800 to the expected supply date, and $21,760, or 544 worker-days of postponed batch work, if supply slips to day 70. We know how to calculate an extension; we still need to find out whether we may make one.

The companion starts the attribution on day 2 because batch keeps running on the eight workers through the two preparation days, a convention the agreement should state rather than leave each team to assume. In the companion’s calendar the loan starts on June 30, a quarter-end, and an extension to day 42 runs through the July 31 month-end; Volume I, Chapter 1 shows these batch workers spiking at both. The batch owner needs to work through what will remain unfinished, who needs it, and whether the catch-up plan remains credible before deciding that an extension is acceptable.

An agreement makes that discussion much easier by saying who may request an extension, when the answer is needed, and what the service will do if the answer is no. The answer is due well before day 32: at the latest, day 32 less the lead time of whatever we would do instead. Without them, it is tempting to let the transfer continue while everybody assumes somebody else is arranging the next conversation; silence does not give the capacity team authority to keep the workers.

We also need to settle whether an approved extension can be revoked. Batch may need an emergency right to reclaim the resources, while the service may need an uninterrupted hold. Both needs are understandable; promising both unconditionally is not. Discuss the notice, trigger, and response while the arrangement is being made, rather than discover during an urgent event that each team thought the other one would yield.

A slip to day 70 turns a ten-day extension into 38 additional days of batch deferral, large enough to need another substantive decision rather than an administrative update to the old one. The useful agreement says who participates and what happens if a condition fails.

Make estimates travel with their uncertainty

I would treat supplier information with the same care as customer demand intelligence. Who supplied it, when, and what state were they describing? Installed inventory, unallocated stock, planned delivery, confirmed allocation, and qualified service capacity can all be called “available” in an imprecise conversation, although they leave very different amounts of work still to do.

Providers draw some of these lines themselves. A future-dated AWS Capacity Reservation is assessing while AWS weighs it against forecast supply, scheduled once approved, and usable only when active; it can also turn up delayed or unsupported.19

Delivered resources may need configuration, data movement, performance qualification, network preparation, and an operating handoff before they can carry the promised service. If those tasks sit outside the delivery estimate, we have to plan their time too; changing the column heading to “ready” does not shorten them.

Release estimates deserve the same scrutiny. A customer may expect to return resources after a migration, while an unfinished dependency keeps the old system running. Once we promise those resources to another customer, the first customer’s exit has become part of the second customer’s supply plan. Both projects can look healthy until we compare the dates and find that they need the same capacity at the same time.

That comparison is part of the central team’s job. I would distinguish the earliest plausible readiness, the working estimate, and whatever conditions have actually been committed, keeping the source, the date we last checked, and the next expected update with each. A supplier who cannot offer a reliable range has given us an uncertainty to manage rather than an invitation to invent probability weights; we can ask what evidence will come next and which options to preserve while waiting for it.

Decide what changes when demand changes

Holding capacity for a customer who may use it gives that customer flexibility, but somebody funds the hold and another customer may be unable to obtain the resource. That can be a worthwhile choice if it is made with the cost and priority understood, not by treating an unconfirmed forecast as a free option.

For tentative demand, the conversation should establish when the customer can confirm, what happens if the date moves, and which part of the hold can be released. A stronger promise needs stronger evidence and financial support. Where demand is deliberately uncertain, bounded scenarios and review dates serve better than a precise answer neither side believes.

Experimental AI work is an obvious place to use that judgment. The team is trying to discover whether something is useful; demanding a stable annual consumption curve before it begins would make the forecast an exercise in satisfying us. An allowance within a constrained pool, a discussion of readiness, and a trigger for bringing a larger request back can support the experiment until it becomes a promise to customers, when the operating arrangement must catch up.

I would also make it easy to reduce a request. A capacity team that collects forecasts enthusiastically and makes cancellations difficult can produce a shortage by preserving holds nobody needs anymore. An early cancellation should earn an account of what the released option made possible elsewhere, so the customer does not wonder whether admitting the change will make its next request harder.

Evaluate the price of certainty

To evaluate a commitment, I want to see demand that disappoints us as well as demand that makes the preferred case look attractive.

In a simplified pricing illustration, variable purchase costs $10 per unit-period. A take-or-pay agreement offers $7 per unit-period for 100 units over twelve periods, with no resale, cancellation, or other charges. Assume use never exceeds 100 units in any period, so there are no overage charges. We would commit to 100 × 12 × $7 = $8,400, the same amount that 840 unit-periods would cost at the variable price.

There are 1,200 possible unit-periods, so break-even use is 840 ÷ 1,200 = 70 percent, which is simply $7 ÷ $10. At 600 unit-periods, variable purchase would cost $6,000, so the agreement costs $2,400 more; at all 1,200, variable purchase costs $12,000 and the agreement costs $3,600 less. That $3,600 is the most it can gain, while demand that disappears entirely would lose the whole $8,400. The $7 rate has not changed between the cases; the amount of useful demand has changed its value to us.

How much to commit is a separate decision. If the disappointing case means a steady 50 units in every period, a 50-unit commitment costs 50 × 12 × $7 = $4,200, which is $1,800 less than those 600 unit-periods at $10. At full use, the other 600 cost $6,000 at the variable rate, for $10,200 against $12,000, again $1,800 less. The smaller commitment gives up half the best-case advantage and turns the $2,400 loss into an $1,800 advantage.

The illustration has no exits, and real agreements differ most in their exits. Azure savings plans cannot be canceled or refunded; AWS Savings Plans can be returned only within seven days, in the same calendar month, and only at $100 an hour or less.2021 Azure caps refunds of canceled reservations at USD 50,000 in a rolling twelve months per billing profile or enrollment, and from February 1, 2027, new reservations for services that savings plans cover cannot be exchanged, though they can still be traded in for a savings plan.22 AWS lets Standard Reserved Instances be resold on its marketplace for a 12 percent fee, up to $50,000 over the account’s lifetime.23 For a portfolio holding millions of dollars of reservations, neither cap is much of an exit, and Capacity Blocks cannot be canceled at all.24

Timing can change the result even when total use is unchanged. Both providers apply a savings plan commitment hour by hour, and an hour’s unused commitment expires.2526 A busy afternoon cannot recover an unused overnight allowance, so the 50-unit sizing works only if the disappointing demand really is steady. Evaluate the actual hourly demand before translating the illustration’s 70 percent into a purchasing rule; pooling eligible workloads can improve coverage, but an annual consumption total cannot establish it. AWS also fixes Savings Plans prices for the term, while Azure applies its current prices, so an Azure commitment can buy a different amount of compute before it ends.

A consumption commitment applies the same arithmetic to the whole account. Under a Microsoft Azure Consumption Commitment, eligible spending draws down a total over the term, and a balance left at the end date, or at a milestone, is charged as a shortfall, which Microsoft applies as Azure prepayment credit.27 Below the commitment, consumption that an efficiency program removes comes back as shortfall rather than as cash saved. Microsoft’s description of the shortfall says nothing about capacity that could not be obtained, so if a shortage could stop us spending, the relief has to be negotiated in; otherwise one event can cost us the capacity and the shortfall. Chapter 23 works through sizing such a commitment when the spending that could leave sits in other budgets.

When a platform buys a commitment for several teams, the internal agreement has to say who carries the unused part; Volume I, Chapter 13 discusses how it is reported.

When a commitment cannot be met

The least useful time to discover what an agreement means is when it is already failing. I want a response to bad news that says who needs to hear it, how early they can hear it, and which choices remain open.

For an internal customer, we might change rollout scope, qualify a temporary alternative, revise priority, or take the conflict to a person able to change several obligations together. External arrangements also need the commercial and legal owners to establish the actual terms and remedies; an informal exchange may have informed our planning without creating the enforceable promise we would now like it to contain.

Remedies need to be evaluated against the customer’s problem. Azure’s capacity reservation SLA shows one remedy and its limit together: in Microsoft’s worked example, a reserved unit that could not be deployed for 55 minutes in a month, 99.87 percent availability, earns a 10 percent service credit, claimed from unavailable minutes the customer calculates from its own failed deployments.28 The credit returns part of what we paid for the hold; the workload still needs somewhere to run. An escalation route may get attention faster without creating physical supply, and a substitute resource may require more qualification work than the remaining time permits. Each can be worth having, if we follow it far enough to say what it can accomplish before the deadline.

In the constructed portfolio, a delayed supply estimate therefore sends us back to Product, the batch owner, Finance, and operations to decide what service can be promised while waiting. Keep the earlier date in the history with its original status as an estimate: recasting it afterward as a broken guarantee would distort what we knew, and deleting it would make our earlier decision look more cautious than it was.

Carry the conditions into the review

Agreement gives us a set of conditions to watch. Product changes the rollout, a new request mix changes the service rate, a supplier revises delivery, or qualification reveals less throughput than expected, while the borrowed workers approach their return date regardless. Any one of these changes can reopen the combined decision; Chapter 22 turns them into triggers agreed in advance.

Someone has to own those connections, not just the inputs. In the constructed portfolio, the capacity lead maintains the joined view and brings the choice back before the available options expire; the people with authority over the promises still decide which ones can change.

External agreements bring their own calendar: renewal and expiry dates, milestones, the end of each booked window, and the last day an exchange or refund can still be used. Renewal needs an owner. Azure savings plans do not renew unless somebody turns renewal on, and since July 1, 2026 Microsoft has stopped renewing Reserved VM Instances for several older series; either way, usage falls back to pay-as-you-go rates at expiry.2930 Microsoft warns of an unmet consumption commitment 90, 60, and 30 days before it expires,31 which may be too late if closing the gap means moving workloads. The six-week estimate this chapter began with belongs in the same review, with who gave it, the state it described, and when we expect to hear more, before a project plan or a customer announcement turns it into something else.

Notes and sources

  1. Microsoft Learn, “Prepay for Azure virtual machines to save money” and “Transition guide for retired Azure Reserved VM Instances”, checked October 3, 2026 (transition guide checked October 4, 2026). Reserved VM Instances are a billing discount, not a capacity guarantee, and can be combined with capacity reservations; capacity priority requires single-subscription scope; purchases and renewals for several older series ended July 1, 2026, with existing reservations running to term. Vendor documentation; terms change.↩︎

  2. Microsoft Learn, “On-demand capacity reservation in Azure” and “Create a capacity reservation”, checked October 3, 2026 (overview checked October 4, 2026). Region or zone holds billed at the VM rate whether used or not, with discounts applicable; no SLA for capacity priority; the SLA’s worked service-credit example and customer-calculated claims; ND-series and NCads H100 v5 unsupported. Microsoft’s SLA text governs, and supported sizes change.↩︎

  3. Amazon Web Services, Amazon EC2 User Guide, “Reserve compute capacity with EC2 On-Demand Capacity Reservations”, “Concepts for Amazon EC2 Capacity Reservations”, “View the state of a Capacity Reservation”, “Capacity Reservation pricing and billing”, and “Regional and zonal Reserved Instances (scope)”, checked October 3, 2026 (future-dated terms and eligible families checked October 4, 2026). Billing and discounts for Capacity Reservations; zonal versus regional Reserved Instances; future-dated lead times, minimum commitment, eligible families, and states. Product limits change.↩︎

  4. Amazon Web Services, Savings Plans User Guide, “What are Savings Plans?”, “Compute Savings Plans and Reserved Instances”, “Understanding how Savings Plans apply to your usage”, and “Returning a purchased Savings Plan”, checked October 3, 2026 (return conditions checked October 4, 2026). Hourly commitment with prices fixed for the term; no capacity reservation; no cancellation; unused hours not carried over; the seven-day return conditions.↩︎

  5. Microsoft Learn, “Prepay for Azure virtual machines to save money” and “Transition guide for retired Azure Reserved VM Instances”, checked October 3, 2026 (transition guide checked October 4, 2026). Reserved VM Instances are a billing discount, not a capacity guarantee, and can be combined with capacity reservations; capacity priority requires single-subscription scope; purchases and renewals for several older series ended July 1, 2026, with existing reservations running to term. Vendor documentation; terms change.↩︎

  6. Microsoft Learn, “On-demand capacity reservation in Azure” and “Create a capacity reservation”, checked October 3, 2026 (overview checked October 4, 2026). Region or zone holds billed at the VM rate whether used or not, with discounts applicable; no SLA for capacity priority; the SLA’s worked service-credit example and customer-calculated claims; ND-series and NCads H100 v5 unsupported. Microsoft’s SLA text governs, and supported sizes change.↩︎

  7. Microsoft Learn, “What are savings plans?” and “Automatically renew your savings plan”, checked October 4, 2026. Hourly commitment for one or three years; unused hours expire; no cancellation or refund; current savings plan prices apply; renewal turned off by default, with pay-as-you-go rates after expiry. The $10/$7 illustration is hypothetical, not an Azure offer.↩︎

  8. Amazon Web Services, Savings Plans User Guide, “What are Savings Plans?”, “Compute Savings Plans and Reserved Instances”, “Understanding how Savings Plans apply to your usage”, and “Returning a purchased Savings Plan”, checked October 3, 2026 (return conditions checked October 4, 2026). Hourly commitment with prices fixed for the term; no capacity reservation; no cancellation; unused hours not carried over; the seven-day return conditions.↩︎

  9. Microsoft Learn, “Track your Microsoft Azure Consumption Commitment (MACC)”, checked October 4, 2026. Commitment, milestones, shortfall charged as Azure prepayment credit, and alerts 90, 60, and 30 days before expiry. The page does not address capacity availability; each agreement’s terms govern.↩︎

  10. Microsoft Learn, “Prepay for Azure virtual machines to save money” and “Transition guide for retired Azure Reserved VM Instances”, checked October 3, 2026 (transition guide checked October 4, 2026). Reserved VM Instances are a billing discount, not a capacity guarantee, and can be combined with capacity reservations; capacity priority requires single-subscription scope; purchases and renewals for several older series ended July 1, 2026, with existing reservations running to term. Vendor documentation; terms change.↩︎

  11. Amazon Web Services, Amazon EC2 User Guide, “Reserve compute capacity with EC2 On-Demand Capacity Reservations”, “Concepts for Amazon EC2 Capacity Reservations”, “View the state of a Capacity Reservation”, “Capacity Reservation pricing and billing”, and “Regional and zonal Reserved Instances (scope)”, checked October 3, 2026 (future-dated terms and eligible families checked October 4, 2026). Billing and discounts for Capacity Reservations; zonal versus regional Reserved Instances; future-dated lead times, minimum commitment, eligible families, and states. Product limits change.↩︎

  12. Microsoft Learn, “On-demand capacity reservation in Azure” and “Create a capacity reservation”, checked October 3, 2026 (overview checked October 4, 2026). Region or zone holds billed at the VM rate whether used or not, with discounts applicable; no SLA for capacity priority; the SLA’s worked service-credit example and customer-calculated claims; ND-series and NCads H100 v5 unsupported. Microsoft’s SLA text governs, and supported sizes change.↩︎

  13. Amazon Web Services, Amazon EC2 User Guide, “Reserve compute capacity with EC2 On-Demand Capacity Reservations”, “Concepts for Amazon EC2 Capacity Reservations”, “View the state of a Capacity Reservation”, “Capacity Reservation pricing and billing”, and “Regional and zonal Reserved Instances (scope)”, checked October 3, 2026 (future-dated terms and eligible families checked October 4, 2026). Billing and discounts for Capacity Reservations; zonal versus regional Reserved Instances; future-dated lead times, minimum commitment, eligible families, and states. Product limits change.↩︎

  14. Amazon Web Services, Amazon EC2 User Guide, “Capacity Blocks for ML” and “Capacity Blocks pricing and billing”, checked October 4, 2026. Up to eight weeks ahead and 64 instances per block; no cancellation; price set at purchase by supply and demand, charged upfront; no Savings Plans or Reserved Instance discounts. Supported types and Regions change.↩︎

  15. Amazon Web Services, Amazon EC2 User Guide, “Reserve compute capacity with EC2 On-Demand Capacity Reservations”, “Concepts for Amazon EC2 Capacity Reservations”, “View the state of a Capacity Reservation”, “Capacity Reservation pricing and billing”, and “Regional and zonal Reserved Instances (scope)”, checked October 3, 2026 (future-dated terms and eligible families checked October 4, 2026). Billing and discounts for Capacity Reservations; zonal versus regional Reserved Instances; future-dated lead times, minimum commitment, eligible families, and states. Product limits change.↩︎

  16. Microsoft Learn, “On-demand capacity reservation in Azure” and “Create a capacity reservation”, checked October 3, 2026 (overview checked October 4, 2026). Region or zone holds billed at the VM rate whether used or not, with discounts applicable; no SLA for capacity priority; the SLA’s worked service-credit example and customer-calculated claims; ND-series and NCads H100 v5 unsupported. Microsoft’s SLA text governs, and supported sizes change.↩︎

  17. Amazon Web Services, Amazon EC2 User Guide, “Reserve compute capacity with EC2 On-Demand Capacity Reservations”, “Concepts for Amazon EC2 Capacity Reservations”, “View the state of a Capacity Reservation”, “Capacity Reservation pricing and billing”, and “Regional and zonal Reserved Instances (scope)”, checked October 3, 2026 (future-dated terms and eligible families checked October 4, 2026). Billing and discounts for Capacity Reservations; zonal versus regional Reserved Instances; future-dated lead times, minimum commitment, eligible families, and states. Product limits change.↩︎

  18. Amazon Web Services, Amazon EC2 User Guide, “Capacity Blocks for ML” and “Capacity Blocks pricing and billing”, checked October 4, 2026. Up to eight weeks ahead and 64 instances per block; no cancellation; price set at purchase by supply and demand, charged upfront; no Savings Plans or Reserved Instance discounts. Supported types and Regions change.↩︎

  19. Amazon Web Services, Amazon EC2 User Guide, “Reserve compute capacity with EC2 On-Demand Capacity Reservations”, “Concepts for Amazon EC2 Capacity Reservations”, “View the state of a Capacity Reservation”, “Capacity Reservation pricing and billing”, and “Regional and zonal Reserved Instances (scope)”, checked October 3, 2026 (future-dated terms and eligible families checked October 4, 2026). Billing and discounts for Capacity Reservations; zonal versus regional Reserved Instances; future-dated lead times, minimum commitment, eligible families, and states. Product limits change.↩︎

  20. Microsoft Learn, “What are savings plans?” and “Automatically renew your savings plan”, checked October 4, 2026. Hourly commitment for one or three years; unused hours expire; no cancellation or refund; current savings plan prices apply; renewal turned off by default, with pay-as-you-go rates after expiry. The $10/$7 illustration is hypothetical, not an Azure offer.↩︎

  21. Amazon Web Services, Savings Plans User Guide, “What are Savings Plans?”, “Compute Savings Plans and Reserved Instances”, “Understanding how Savings Plans apply to your usage”, and “Returning a purchased Savings Plan”, checked October 3, 2026 (return conditions checked October 4, 2026). Hourly commitment with prices fixed for the term; no capacity reservation; no cancellation; unused hours not carried over; the seven-day return conditions.↩︎

  22. Microsoft Learn, “Self-service exchanges and refunds for Azure Reservations” and “Changes to the Azure reservation exchange policy”, checked October 4, 2026. The USD 50,000 refund limit; no early termination fee yet, though Microsoft says a 12 percent fee may follow; no exchanges for affected reservations bought from February 1, 2027, with trade-ins still allowed. Announced policy, subject to change.↩︎

  23. Amazon Web Services, “Sell Reserved Instances for Amazon EC2 in the Reserved Instance Marketplace”, checked October 4, 2026. Standard Reserved Instances only; a 12 percent fee on the upfront price; lifetime limits of $50,000 and 5,000 instances that cannot be increased. A listing still needs a buyer.↩︎

  24. Amazon Web Services, Amazon EC2 User Guide, “Capacity Blocks for ML” and “Capacity Blocks pricing and billing”, checked October 4, 2026. Up to eight weeks ahead and 64 instances per block; no cancellation; price set at purchase by supply and demand, charged upfront; no Savings Plans or Reserved Instance discounts. Supported types and Regions change.↩︎

  25. Microsoft Learn, “What are savings plans?” and “Automatically renew your savings plan”, checked October 4, 2026. Hourly commitment for one or three years; unused hours expire; no cancellation or refund; current savings plan prices apply; renewal turned off by default, with pay-as-you-go rates after expiry. The $10/$7 illustration is hypothetical, not an Azure offer.↩︎

  26. Amazon Web Services, Savings Plans User Guide, “What are Savings Plans?”, “Compute Savings Plans and Reserved Instances”, “Understanding how Savings Plans apply to your usage”, and “Returning a purchased Savings Plan”, checked October 3, 2026 (return conditions checked October 4, 2026). Hourly commitment with prices fixed for the term; no capacity reservation; no cancellation; unused hours not carried over; the seven-day return conditions.↩︎

  27. Microsoft Learn, “Track your Microsoft Azure Consumption Commitment (MACC)”, checked October 4, 2026. Commitment, milestones, shortfall charged as Azure prepayment credit, and alerts 90, 60, and 30 days before expiry. The page does not address capacity availability; each agreement’s terms govern.↩︎

  28. Microsoft Learn, “On-demand capacity reservation in Azure” and “Create a capacity reservation”, checked October 3, 2026 (overview checked October 4, 2026). Region or zone holds billed at the VM rate whether used or not, with discounts applicable; no SLA for capacity priority; the SLA’s worked service-credit example and customer-calculated claims; ND-series and NCads H100 v5 unsupported. Microsoft’s SLA text governs, and supported sizes change.↩︎

  29. Microsoft Learn, “What are savings plans?” and “Automatically renew your savings plan”, checked October 4, 2026. Hourly commitment for one or three years; unused hours expire; no cancellation or refund; current savings plan prices apply; renewal turned off by default, with pay-as-you-go rates after expiry. The $10/$7 illustration is hypothetical, not an Azure offer.↩︎

  30. Microsoft Learn, “Prepay for Azure virtual machines to save money” and “Transition guide for retired Azure Reserved VM Instances”, checked October 3, 2026 (transition guide checked October 4, 2026). Reserved VM Instances are a billing discount, not a capacity guarantee, and can be combined with capacity reservations; capacity priority requires single-subscription scope; purchases and renewals for several older series ended July 1, 2026, with existing reservations running to term. Vendor documentation; terms change.↩︎

  31. Microsoft Learn, “Track your Microsoft Azure Consumption Commitment (MACC)”, checked October 4, 2026. Commitment, milestones, shortfall charged as Azure prepayment credit, and alerts 90, 60, and 30 days before expiry. The page does not address capacity availability; each agreement’s terms govern.↩︎