Cost as Code by MoreThanOps

The Cost as Code maturity model

Three levels, from spend that is measured and owned to spend that is guarded by rules checked before it happens.

Last reviewed

Three steps rise from left to right, labelled Measured, Reviewed and Guarded; a bill bar on each step gets shorter, and on the top step a dashed rule line holds it steady.
Measured, reviewed, guarded: three levels, each useful on its own.

In 30 seconds

  1. Measured: spend has owners, a baseline and findings with estimates.
  2. Reviewed: every saving is a pull request, measured on the bill and recorded in a ledger.
  3. Guarded: spend rules live in a file and are checked before money is spent. This is the idea behind Spend as Code, which is coming soon.

Each level is useful on its own. Different teams in one company can sit at different levels.

Nobody adopts Cost as Code in one go, and nobody should. The maturity model describes three levels a team can sit at. They are not a score: they describe what a team does, what it can show, and what to do next. A company can have one team at level 3 and another still at level 1.

Level In one sentence Typical length
1. Measured Every cost has an owner, there is a baseline, and findings carry estimates Weeks
2. Reviewed Savings arrive as pull requests, are approved by their owners and are measured on the bill Months
3. Guarded Spend rules live in a file and are checked in review, in the account and in the AI gateway Ongoing
Three levels: measured, reviewed, guarded. Each builds on the one below.

Level 1: Measured

Signs. Each cost line on the cloud bill points to a team or a product that can change it, and AI spend is broken down by feature or route. There is a baseline month to compare against. Findings exist, each with an estimate and an owner, even if few have been applied yet.

Practices.

  • Allocate cost to owners and share it with them (showback). AWS describes showback as cost allocation used "for visibility of cost ownership" (AWS, checked November 8, 2026).
  • Record the baseline month for each owner's spend.
  • Collect findings with estimates, from your provider's tools or your own review. AWS Cost Optimization Hub, for example, helps you "quantify and aggregate estimated savings" (AWS, checked November 8, 2026).

Metrics. Share of spend with an owner; number of open findings and their total estimate.

Ready to move up when most spend has an owner and the owners know which findings are theirs.

Level 2: Reviewed

Signs. Findings no longer sit in a report. Each saving reaches its owning team as a pull request with its estimate and rollback, the team approves it, and about 30 days later the saving is measured on the bill and recorded in a savings ledger.

Practices.

  • One saving per pull request, with the rollback written in it.
  • Approval by the team that owns the system; nobody approves their own change.
  • A change-log repository for teams that change their cloud in the console.
  • A savings ledger with the estimate, the measured saving and a link to each change.
  • The order of work: remove waste, then resize, then commit.

Metrics. Findings turned into merged changes; estimated versus measured saving per change; time from finding to merge; changes rolled back.

Ready to move up when savings flow as reviewed changes, the ledger matches the bill, and the team asks how to stop the same waste from coming back.

Level 3: Guarded

Signs. The rules that protect each saving (budgets, allowed instance families, allowed models per route, token limits) live in a versioned file. A change that would break a rule fails its check before it ships, and changes to the rules are themselves reviewed pull requests.

Coming soon This level describes the idea behind Spend as Code, a solution we are building. It is not for sale yet. You can reach this level today with your own tools.

Practices.

  • Keep the spend rules in one file per team, next to its code.
  • Check the rules on every pull request, in the cloud account and in the AI gateway.
  • Keep budget alerts as the second line. AWS notes "a delay between when you incur a charge and when you receive a notification" (AWS, checked November 8, 2026), so the check in review comes first.
  • Treat a budget increase as a pull request, approved by the budget owner and not by the person asking.

Metrics. Savings that came back after the merge; changes stopped by a check, and why; budget changes and who approved them.

How to measure

The metrics come from the pull requests, the ledger and the bill, so they cost little to collect:

  • Ownership: spend with an owner divided by total spend.
  • Flow: findings turned into merged changes, and the time it took.
  • Accuracy: measured saving divided by estimated saving, change by change.
  • Durability: savings still on the bill six months later.
  • Guarding: changes stopped by a rule check, and budget changes made by pull request.

Measure the trend, not a grade. The point of each metric is to show what to do next.

Where to go next

  • In practice: what each level looks like on AWS, with your own tools or with our service.
  • Roles: who acts at each step as a team moves up.