This chapter follows a saving from the moment a tool or a person spots it to the moment the invoice proves it, and names the levers that actually lower a cloud bill. Every line on that bill is the product of two quantities: usage, meaning what runs, how large it is and for how long, and rate, meaning what one unit of it costs. The two are optimised separately, and both end in the same test against the next invoice.

What this chapter covers

The first section describes the loop every change passes through: estimated, accepted, implemented, verified. A recommendation from a provider's console starts as an estimate resting on assumptions about rate and running hours. It becomes a change when the resource's owner accepts it, a fact when it is implemented, and a realised saving when the following month's invoice shows the difference. The section answers who decides at each stage, what is recorded there, and how the effective savings rate summarises the outcome across commitments, discounts and usage changes. The open list of savings opportunities is the stock from which the monthly cost review picks the few actions due before the next meeting.

The second section covers usage: everything that changes the number of billed units without touching the price of one. That is rightsizing of instances and databases, idle and orphaned resources, schedules and auto-scaling, storage classes and retention, data transfer between zones, regions and the internet, the utilisation of Kubernetes clusters, and architecture choices that avoid a cost before it exists. The question is always the same: which units are billed while doing no work, and who is allowed to switch them off?

The third section covers rate: the same usage at a lower price. That is Reserved Instances, Savings Plans, committed use discounts and spot capacity, together with the question of how much coverage a company can commit to without a later usage change leaving the commitment unused. The order is deliberate: usage first, rate second, because a commitment locks in the usage it covers. Reserve first and downsize afterwards, and the reservation keeps billing.

The distinction between usage and rate is the tool this chapter uses to place every action. A smaller instance changes usage; a Savings Plan changes rate; a newer generation changes both. Billing data keeps the two apart, as a quantity and a rate on every line, and a report that keeps them apart shows which action worked and which one only moved the other side.

Key terms

  • savings opportunity: a change that has been identified and estimated but not yet decided, the stock the loop draws on.
  • realised savings: the difference that actually appears on the invoice after the change, not the estimate before it.
  • effective savings rate: the saving from discounts and commitments as a share of what the same usage would have cost without them, against a stated basis such as contracted or list cost.
  • rightsizing: matching a resource's size to its measured use; a usage lever.
  • Reserved Instances: a reservation of an instance family or service in exchange for a lower rate; a rate lever.
  • Savings Plans: a commitment to an hourly spend rather than to an instance; more flexible than a reservation, with different gaps.
  • data transfer: the line architecture decisions move most, and the one no commitment covers.

Neighbouring chapters

Before this chapter stands Budgets, forecasts and finance: there, a saving is a variance from the plan, and a forecast that leaves out accepted changes is wrong before the month begins. After it comes Governance and the operating model, which answers the question this chapter leaves open on every page: who approves a change, who implements it, and how the company keeps the same waste from reappearing next quarter.

Two earlier chapters supply the groundwork. Pricing models and commitments explains the rate side, how reservations, Savings Plans and spot capacity work and are billed; this chapter assumes that and covers only the strategy. What cloud services cost explains which units each service bills, and so what rightsizing and schedules can change at all. Allocation and ownership is the precondition for everything here: a change without an owner is not implemented, and a saving without allocation cannot be credited to anyone. The full list of chapters is in the handbook.