Cost as Code by MoreThanOps

Why "as code"

What the name commits the method to, what it does not mean, and how it differs from the terms next to it.

Last reviewed

A spreadsheet of budgets and a list of cost findings fold into a short text file in a repository; a diff appears on the file, a reviewer ticks it, and the file's history grows by one line.
From scattered spreadsheets and consoles to one file with a history: that is what "as code" means here.

In 30 seconds

  • "As code" means four things here: the source of truth is files, changes go through pull requests, rules are checked by tools, and the bill is the test.
  • It does not mean that software changes your accounts on its own, or that you need infrastructure as code to start.
  • FinOps as Code is a related term that others use in several ways; Cost as Code is narrower and names the unit of work (one reviewed change) and the test (the bill).

"As code" is a promise about how work is done, borrowed from the way software teams already work. Infrastructure as code, GitOps and policy as code each made the same promise for their own subject. Cost as Code makes it for spend. This page says what that promise includes, what it leaves out, and where the name sits among its neighbours.

What "as code" means here

1. Files are the source of truth. The rules that decide what may be spent, and the changes that reduce what is spent, live in files in a repository. Martin Fowler describes infrastructure as code as defining infrastructure "through source code that can then be treated just like any software system" (martinfowler.com, checked November 8, 2026). Cost as Code treats spend rules and savings the same way.

2. Every change is versioned. The OpenGitOps principles ask that desired state be stored with "a complete version history" (OpenGitOps, checked November 8, 2026). For cost, that history answers the questions finance asks: who raised this budget, when, and why.

3. Changes go through pull requests. When Weaveworks named GitOps in 2017, its summary was "Operational changes are made by pull request", with "Rollback and audit logs" provided through Git (Weaveworks, archived, checked November 8, 2026). A saving is an operational change, so it gets the same treatment: a proposal, a review, a merge and, if needed, a revert.

4. Rules are checked by tools. Policy as code lets you "specify policy as code" and hand the decision to a tool (Open Policy Agent, checked November 8, 2026). A spend rule that lives in a file can be checked on every pull request, not only read in a meeting.

Four habits from software teams, and one addition: the bill as the test.

What it does not mean

It does not mean software acts on its own. Nothing in Cost as Code changes an account without a person approving the change first. A tool can find, estimate and check; the owner of the system decides.

It does not mean you need infrastructure as code first. A team that changes its cloud in the console can still work this way: the pull request goes to a small change-log repository that describes the change, and the team approves it there before anyone touches the account.

It does not mean code is the goal. The goal is spend that is lower, owned and explained. Files and pull requests are the means, because they give review, history and rollback for free.

It does not replace cost reporting. Dashboards and reports show where the money went. Cost as Code is about the changes and rules that decide where it goes next.

The neighbouring terms

Term What it usually means How Cost as Code differs
Infrastructure as code Infrastructure defined in source code and changed like software Uses it where it exists; the subject is the cost of each change, not the infrastructure itself
Policy as code Rules written in files and checked by a tool, often for security or compliance Uses the same idea for spend rules: budgets, instance families, models per route, token limits
GitOps Operations run from Git, with changes made by pull request Applies the pull request to savings, and adds the bill as the test
FinOps as Code A label used in several ways (see below) Names one unit of work, a reviewed change, and one test, the bill
Cost as Code Cloud and AI spend managed like code Every saving is a reviewed change measured on the bill; spend rules live in versioned files

FinOps as Code, a related term

"FinOps as Code" is used by several writers and tool makers, and not always in the same sense:

  • Configuring cost tools in code: a cost tool's reports, alerts and settings kept in files, for example in Terraform.
  • Engineering practice for cost in general: applying the habits of software engineering to how cloud spend is managed.
  • Rules and budgets in version control: cost rules, budgets and policies written as files and reviewed like code.

All three are fair uses, and Cost as Code overlaps with each. The third is close to what we call Spend as Code, which is coming soon. What Cost as Code adds is a precise unit and a precise test: the unit is one reviewed change with its estimate and rollback, and the test is the bill about 30 days later. It also treats AI spend as part of the same practice, with models rightsized like instances.

Why the bill is the test

An estimate is a forecast. AWS Cost Optimization Hub, for example, helps you "quantify and aggregate estimated savings" (AWS, checked November 8, 2026); what the change really saved only shows up later, on the bill. Alerts arrive late too: "There can be a delay between when you incur a charge and when you receive a notification from AWS Budgets" (AWS, checked November 8, 2026).

So Cost as Code tests twice. Before the merge, a check in review compares the change with the rules. After the merge, the bill confirms the saving, and the result goes into a savings ledger next to the estimate. A saving that cannot be measured stays an opinion.

Where to go next