FinOps & Cost Engineering

The Cost & FinOps page made the foundational case: in the cloud the bill scales with carelessness, so cost has to become a feedback loop — measured, attributed, and continuously optimized — rather than a quarterly surprise. That page taught the mechanics: on-demand vs reserved vs spot, tagging, rightsizing, unit economics. This page is about what happened next: those mechanics grew into a named profession with a foundation, a defined framework, and a maturity model. As of 2024–2025, “FinOps practitioner” is a job, and “cost as a first-class SLO” is the framing that turns all of it from a cleanup chore into engineering. The thread is unchanged; the discipline around it hardened.

FinOps, defined by the people who named it

The term is owned by the FinOps Foundation, a non-profit under the Linux Foundation. Their definition is worth stating precisely because it corrects the most common misreading: FinOps is not “spend less.” It is bringing financial accountability to the variable spend model of the cloud so that engineering, finance, and product make data-driven trade-offs about cost together. Sometimes the right call is to spend more — on a feature that earns more than it costs. FinOps is the practice that lets you know that, instead of guessing.

Their framework gives the field a shared lifecycle — three phases run as a continuous loop:

   ┌──────────── FinOps lifecycle (continuous) ────────────┐
   │  INFORM    allocate + show cost: who spends what,        │
   │            and the unit economics ($ per request/user)   │
   │  OPTIMIZE  act: rightsize, commit (reserved/savings),     │
   │            run spot, scale idle to zero, kill orphans      │
   │  OPERATE   govern: budgets, anomaly alerts, policy,        │
   │            make cost a metric teams own continuously       │
   └────────────────────┬──────────────────────────────────────┘
                        └── repeat; visibility never stops

This is the cloud-cost feedback loop with names attached. Inform is the measure + report the earlier page insisted on (you cannot reduce what you cannot attribute, which is why tagging is step zero). Optimize is the levers — rightsizing, the reserved/spot layering, scale-to-zero. Operate is the part the foundation added emphasis to: making cost governed and owned, with budgets and alerts, not just cleaned up once.

Unit economics is still the only number that matters

The earlier page’s central insight survives intact and gets sharper at the frontier: a total bill is nearly meaningless; cost per unit of value is everything. “$80k/month” tells you nothing. $0.0004 per request, $0.11 per active user, $0.02 per transaction — those you can reason about, trend, and steer by.

   bill +40%, traffic +60%   →  cost/request FELL   →  healthy growth
   bill flat, traffic −30%   →  cost/request ROSE   →  a quiet leak

What the FinOps discipline adds is making this number first-class: published per team, per service, per feature, on a dashboard next to latency and error rate — not buried in a finance spreadsheet. When a product team can see its own cost-per-request move in response to a deploy, cost becomes a thing engineers optimize the way they optimize p99 latency. That is the cultural shift the whole discipline is selling.

The levers, one frontier layer deeper

The cost page covered the purchase-model levers. Two deserve a sharper look here because the tooling around them matured.

Commitment discounts have gotten more flexible. The original “reserved instance” locked you to a specific instance type for 1–3 years. Newer commitment models (AWS Savings Plans and the equivalents on other clouds) let you commit to a dollar-per-hour spend rather than a specific machine, so you keep the discount even as your fleet’s shape changes. The principle is identical — pay the provider to surrender flexibility you don’t need on your steady-state baseline — but the commitment is less brittle.

Scale-to-zero became a default, not a trick. Driving idle workloads to zero capacity used to require custom scheduling. The frontier tooling makes it routine:

Under the hood — how scale-to-zero actually works

The mechanism is event-driven autoscaling. Tools like KEDA (Kubernetes Event-Driven Autoscaling, a CNCF project) and serverless platforms like Knative watch a signal — queue depth, request rate, a cron schedule — and scale a workload’s replica count down to zero when the signal is quiet, then back up when work arrives. The cost win is total: a workload at zero replicas bills nothing for compute. The cost is the cold start — the first request after idle has to wait for an instance to spin up. This is the same trade-off the autoscaling page named, now with a money lens: you are exchanging a few hundred milliseconds of first-request latency for paying nothing while idle. Whether that trade is worth it is exactly a unit-economics question — and it’s a major reason the WASM-and-edge page’s near-zero cold starts matter for cost, not just speed.

Cost as a first-class SLO

The framing that defines cost engineering at the frontier: treat cost like reliability. You already learned to set a reliability target — an SLO with an error budget — and to alert on the burn rate before the budget is gone. Cost gets the same treatment:

Reliability discipline	Cost discipline (the parallel)
SLO: “99.9% of requests succeed”	Budget: “this service costs ≤ $X / month” or ”≤ $Y per 1k requests”
Error budget: how much failure you can spend	Cost budget: how much spend the unit economics allow
Burn-rate alert: page when you’ll blow it early	Anomaly alert: page when spend deviates from forecast
Blameless postmortem on an outage	Cost review on a spend spike — why did it move?

The key move is the anomaly alert. Instead of discovering a doubled bill at the end of the month (the manual, error-prone “notice by accident” the cost page warned about), a cost budget with anomaly detection pages the day spend deviates from its forecast — the same way a burn-rate alert fires the moment reliability starts draining too fast. Cost stops being a lagging monthly report and becomes a leading signal a team owns, on call, like any other.

The savings aren’t additive; they multiply, because each lever shrinks the base the next one acts on. Take a naive baseline of 20 on-demand instances running 24/7 and apply the levers in sequence (approximate mid-2020s discount ranges — verify current numbers before quoting):

   start:        20 instances, on-demand, 24/7          = 100%  of baseline cost

   1. rightsize  most were 2× too big → drop a size      ≈  ×0.6  → 60%
   2. scale idle non-prod (~8 of them) to zero
      nights+weekends (~75% idle hours saved on those)   ≈  ×0.7  → 42%
   3. commit the steady baseline to a savings plan
      (~40% off the ~half that's always-on)              ≈  ×0.8  → 34%
   4. move fault-tolerant batch to spot (~80% off)       ≈  ×0.9  → 30%

   result: ≈ 30% of the naive bill — a ~70% cut, same workload

No single lever is dramatic. Compounded — and kept compounded by the Operate phase so the next forgotten dev box doesn’t undo it — they routinely cut a cloud bill by half or more. That is the whole argument for making cost a continuous loop instead of a one-time cleanup.

The most public reminder that cloud unit economics are not automatically favorable came from 37signals (makers of Basecamp and HEY). In late 2022 its co-founder publicly announced the company would leave the cloud and run its own hardware, citing a large annual cloud bill (publicly discussed as on the order of a few million dollars a year) that, for their steady, predictable workload, they judged far more expensive than owning servers. They completed the migration through 2023 and reported substantial multi-year savings (treat the exact figures as the company’s own published numbers, not an independent audit). The lesson is not “the cloud is a scam” — it’s the FinOps lesson exactly: the cloud’s pay-for-flexibility model is a great deal for variable, unpredictable load and a poor one for flat, predictable load you could commit to or own. Knowing which you have — i.e. measuring your unit economics — is the entire point of the discipline.

The thread

The manual, error-prone step FinOps removes is the one the cost page named — noticing waste by accident, usually when a finance review flags a bill that doubled months ago. The frontier discipline closes the gap further by making cost a first-class SLO: a budget with an anomaly alert that pages the owning team the day spend drifts, the same way a burn-rate alert protects reliability. The manual quarterly audit is replaced by a continuous, owned, alerting loop.

Production gets safer in the way that is easy to underrate: uncontrolled cost is an availability risk. A surprise bill triggers panicked, top-down cost-cutting that amputates the wrong things under pressure; a continuously watched cost is trimmed with small, deliberate changes — a rightsize here, a savings plan there, a scale-to-zero schedule — that never threaten reliability. The cost of the discipline is real: tagging hygiene, the upkeep of the loop, and the cultural shift to treating spend as every engineer’s signal rather than Finance’s problem. The 37signals story is the honest counterweight — the discipline can even conclude the cloud is the wrong tool for a given workload, and that, too, is FinOps working. Next, a frontier that adds a new cost line of its own while promising to cut operational toil: AIOps and LLMs in operations.

The architect’s lens

Five questions for FinOps as a named discipline:

Why does it exist? Because the cloud’s bill scales with carelessness, so the ad-hoc cost mechanics hardened into a named discipline (the FinOps Foundation’s Inform/Optimize/Operate) — “FinOps practitioner” is now a job.
What problem does it solve? Noticing waste by accident at month-end: it makes cost a first-class SLO — a budget with an anomaly alert that pages the owning team the day spend drifts — steered by unit economics ($/request, not a meaningless total) published next to latency and error rate.
What are the trade-offs? Real discipline cost — tagging hygiene, the loop’s upkeep, and the cultural shift to treating spend as every engineer’s signal; the levers (rightsize, commit, spot, scale-to-zero) only stay compounded (~70% off) if the Operate phase keeps watching.
When should I avoid it? Never as a discipline — but it can legitimately conclude the cloud is the wrong tool (37signals leaving for owned hardware on steady, predictable load), and that too is FinOps working.
What breaks if I remove it? A surprise bill triggers panicked, top-down cost-cutting that amputates the wrong things under pressure — uncontrolled cost is an availability risk.

Check your understanding

The FinOps Foundation insists FinOps is not “spend less.” What is it, and why does “spend more” sometimes count as a FinOps win?
Map the Inform / Optimize / Operate phases onto the cost feedback loop from the earlier page. Which phase does the frontier put new emphasis on, and why?
Explain “cost as a first-class SLO.” What is the cost-side parallel of a burn-rate alert, and what manual discovery does it replace?
Why do the cost levers multiply rather than add? Use the by-the-numbers sequence to explain why a continuous loop matters more than a one-time cleanup.
Using the 37signals field note, explain when the cloud’s pricing model is a good deal and when it isn’t — and why measuring unit economics is what tells you which case you’re in.

Show answers

It is bringing financial accountability to the cloud’s variable spend so engineering, finance, and product make data-driven cost trade-offs together — not minimizing spend. “Spend more” is a win when the data shows the spend earns more than it costs (e.g. capacity for a feature that drives revenue); FinOps exists to let you know that rather than guess.
Inform = measure + attribute + report (tagging, unit economics); Optimize = act on the levers (rightsize, commit, spot, scale-to-zero, kill orphans); Operate = govern (budgets, anomaly alerts, policy, ownership). The frontier emphasizes Operate — making cost continuously governed and owned, so savings don’t decay the moment the next forgotten resource spins up.
It means treating cost like reliability: set a budget (e.g. ≤ $X/month or ≤ $Y per 1k requests) and alert on anomalies/forecast deviation the way a burn-rate alert fires before an error budget is gone. The cost-side parallel of a burn-rate alert is the anomaly alert, which replaces the manual “notice the doubled bill at month-end by accident” with a same-day page.
Each lever shrinks the base the next one acts on, so they compound multiplicatively (rightsize → scale-to- zero → commit baseline → spot ≈ 60% × 70% × 80% × 90% ≈ 30% of the naive bill). A one-time cleanup decays as new waste appears; only a continuous loop (the Operate phase) keeps the compounded savings in place.
The cloud’s pay-for-flexibility model is a good deal for variable, unpredictable load (you pay only for what you burst to) and a poor deal for flat, predictable load you could commit to or own (you pay a premium for flexibility you don’t use). 37signals had steady, predictable load and judged owning hardware cheaper. Measuring unit economics is what reveals which workload shape you actually have.