Skip to main content

Chapter 9 · Cost & FinOps

Everything you've learned to build costs money — by the second, by the gigabyte, by the request. The pay-as-you-go model from Chapter 1 is a superpower and a trap: the same elasticity that lets you scale instantly also lets your bill balloon silently. FinOps (Financial Operations) is the discipline of bringing financial accountability to cloud spending — making cost a first-class engineering concern that everyone, not just finance, understands and manages.

Why this chapter matters​

Cloud bills are notoriously surprising. A forgotten oversized VM, an un-tiered storage bucket, runaway data-transfer charges, or a serverless function called a billion times can each quietly cost a fortune. Engineers make spending decisions every time they choose an instance size or a storage class, so cost control can't live only in finance — it has to be an engineering practice. FinOps gives teams the visibility, the shared language, and the loop to make cost-aware decisions continuously, turning the bill from a monthly shock into a managed metric. It uses the same instrument-measure-improve instinct as observability (Chapter 6), pointed at dollars.

The durable idea​

Cloud cost is an engineering responsibility. Make spending visible and attributable (tagging), continuously optimize (rightsizing, tiers, commitments), and run it as a loop — inform, optimize, operate — that everyone participates in.

The FinOps loop and cost-driver concepts are durable; specific prices, instance families, and discount programs are intensely dated.

Lessons in this chapter​

  • 9.1 — How cloud pricing actually works. The main cost drivers — compute hours, storage by volume and tier, data transfer (especially the often-overlooked egress), and per-request charges. Why the bill is hard to predict, and the biggest hidden costs.
  • 9.2 — Pricing models & commitments. On-demand vs reserved/committed-use discounts vs spot/preemptible (cheap, interruptible) capacity, and when each fits. The trade-off of commitment vs flexibility.
  • 9.3 — Tagging & cost allocation. Why consistent resource tagging is the foundation of FinOps — you can't optimize what you can't attribute. Showback and chargeback to teams.
  • 9.4 — Rightsizing & eliminating waste. Finding and fixing over-provisioned resources, idle/zombie resources, and un-tiered storage; autoscaling to match real demand (callback to Ch. 2 and 4).
  • 9.5 — The FinOps loop. The three-phase cycle — inform (visibility), optimize (act on it), operate (make it continuous and cultural) — and how it embeds cost-awareness into engineering.
  • 9.6 — Architecting for cost. How design choices from earlier chapters (serverless vs VMs, storage tiers, managed vs self-hosted, multi-region) are also cost decisions, with the trade-offs made explicit.
  • 9.7 — Checkpoint. Quiz on cost drivers, pricing models, and the FinOps loop.

Where this connects​

  • Back to Chapter 1 — pay-as-you-go is the root of both the benefit and the risk.
  • Back to Chapters 2 & 4 — every compute/storage/scaling choice is also a cost choice.
  • Back to Chapter 6 — FinOps is observability's instinct (measure, then improve) applied to spending.
  • Forward to Chapter 10 — GPU and ML-serving costs are a major, fast-growing line item that FinOps now has to handle.

Next: Chapter 10: MLOps / LLMOps →