This chapter is a catalog of cloud waste patterns: 22 cases in which a bill counts units that do no work, one pattern per page across all three providers, with the symptom in billing data, one listing command per provider, the fix, its risks and the proof in the following month's invoice. The patterns are the ones the providers' recommenders and the open rule sets find most often, from idle virtual machines to premium tiers nobody chose.
What this chapter covers
Every page follows the same structure, because every pattern takes the same path: the symptom is a line in billing data that does not move with use; the detection is a command that lists the candidates and the provider's check that proposes them; the fix starts with the reversible change and ends with the template the pattern came from; the risks name what breaks along the way; and the proof compares the line before and after the change, by the loop of estimated, accepted, implemented, verified that turns a savings opportunity into a realised saving.
The first section, Compute, takes the instances: the ones that run and do nothing, the ones that are stopped and still cost, the ones on hardware two generations old, the move to ARM and the serverless that is set too large. The second, Storage, takes the volumes without an instance, the snapshots without a period, the volume types their successor undercuts, the ordered performance nobody draws on, and the object storage without a lifecycle rule. The third, Databases, takes idle databases, high availability in environments without a requirement, the fees for versions past the end of support and the provisioned capacity that stays below the load. The fourth, Network, takes NAT gateways and endpoints without traffic, public addresses without a resource and load balancers without a target. The fifth takes logs, container registries and AI endpoints, the sixth the purchases nobody uses any more and the premium tiers a template chose.
What this chapter is not: a list of the general levers. Rightsizing, schedules, commitments and the choice of architecture are the pages of the chapter Optimisation and savings; here stand their concrete children, each with the commands that find it and end it. A pattern whose detection and fix coincide with another page's has no page of its own here.
The commands are checked against the providers' reference documentation on the read date, never against a real account; every command that deletes or changes something stands behind one that lists, and carries a dry run where the CLI offers one. Where none does, the page says so, and the list from the detection stands in for it.
Key terms
- savings opportunity: a recognised pattern with an estimated effect before anyone has decided; every page of this chapter produces one.
- realised savings: the difference in the following month's invoice that the last section of every page proves.
- idle cost: the cost of a resource that runs and does no work; the pattern of the first pages.
- lifecycle rule: the rule on a bucket that moves or deletes objects by age; without it, object storage grows forever.
- provisioned capacity: capacity billed by the ordered figure, used or not; the gap between ordered and consumed is the saving.
- extended support: the fee for a version past the end of its standard support, per vCPU-hour or per cluster hour.
- NAT gateway: the gateway billed per hour and per gigabyte, with or without traffic.
- rightsizing: the general lever whose concrete cases sit here.
Neighbouring chapters
Before this chapter stands Optimisation and savings: it explains the loop from estimate to proof and the usage and rate levers this chapter assumes. Every page here is a child of a page there, idle and orphaned resources, storage optimisation, database optimisation or data transfer optimisation, and points to it where the mechanics are explained there.
After it comes Templates and checklists, which provides the documents in which this chapter's decisions are recorded: the checklist for the monthly review, in which the lists of these pages are worked through, and the decision record for commitment purchases, which comes only after the patterns here, because a commitment locks in the usage it covers.
Two chapters supply the groundwork: What cloud services cost explains the units every page here reads as a symptom, and Billing data explains the exports in which the usage types, meters and SKUs every page names are found. The full list of chapters is in the handbook.