This chapter explains how the cloud providers price usage and which commitments lower that price. It starts at the pay-as-you-go list price, works through the commitment programmes of AWS, Azure and Google Cloud, and ends with how a commitment is managed over its term. Reading a bill or judging a commitment needs both halves: the pricing model that produces the line items, and the mechanism by which a discount is applied to them.
What this chapter covers
The first section, Pay as you go, answers what a resource costs with no commitment at all. On-demand is the list price per second, hour, request or gigabyte that every invoice starts from. Spot and preemptible capacity sells the same compute for less because the provider may take it back at any moment. Sustained-use and tiered discounts lower the price automatically once usage or volume crosses a threshold, without anyone buying anything. Each page in the section explains how the price is formed, how it appears in the billing data, and where teams misread it.
The second section, Commitments, answers what discount a provider gives for a promise and what it binds that promise to. AWS offers Reserved Instances, bound to an instance configuration, and Savings Plans, bound to an hourly amount in US dollars. Azure has reservations and savings plans for compute; Google Cloud has committed use discounts on resources or on spend. Reserved capacity for databases, storage and serverless services follows rules of its own. Each page describes one programme as its provider documents it: term, payment options, scope, flexibility, and how the commitment shows up on the invoice, in the export and in a cost report.
The third section, Managing commitments, answers what remains to be done after the purchase. Coverage says what share of usage runs under a commitment; utilisation says what share of the commitment is actually used. Choosing between commitment types depends on how certain the usage is and how much flexibility the discount may cost. Exchange, return and expiry decide whether a commitment that no longer fits burns money or can be rescued.
This chapter describes the mechanics. Which commitment a team should buy, at what size and in what order, is an optimisation decision and belongs to the chapter on optimisation and savings.
Key terms
- Reserved Instances: the AWS commitment bound to instance type, region, platform and tenancy, treated here as a billing discount rather than a machine.
- Savings Plans: the commitment to an hourly amount that AWS and Azure apply automatically to matching usage.
- Effective cost: what an hour of usage really costs once every discount and commitment has been applied.
- Amortized cost: a commitment's upfront payment spread across its term, so the purchase month does not read as a spike.
- Effective savings rate: the saving against on-demand across every commitment, the one measure of a commitment portfolio.
- Savings opportunity: the amount an additional or better-fitting commitment would save at unchanged usage.
Neighbouring chapters
The preceding chapter, Billing data and standards, supplies the data in which a commitment's effect becomes visible: the line item types of an export, the reservation and savings plan columns, and the distinction between billed, amortized and effective cost. This chapter assumes that data and explains the pricing mechanics that produce it.
The following chapter, What cloud services cost, applies the pricing models to the services themselves: compute, storage, databases, data transfer, and the units each service is metered in. The chapter Optimisation and savings takes up commitment strategy as one optimisation among several and places it beside rightsizing and switching things off. The first chapter, FinOps and cloud cost management, gives the frame in which these decisions are made. Every chapter is collected in the handbook.