The principles of Cost as Code

The principles describe a way of working, not a tool. A team can follow them with the tools it already runs, with a service, or with both. They are our own: they come from how software teams already manage change, applied to the money that change costs. Each one below says what it means, why it matters, what it looks like day to day, and the habit it replaces.

1. Every saving is a change its owner approves

The principle. A saving is not a recommendation on a report. It is a proposed change to a real system, and the team that owns that system reviews and approves it before it ships. Nobody approves their own change.

Why it matters. Review before a change ships is one of the oldest habits in software. Michael Fagan's paper on design and code inspections at IBM dates from 1976 (IBM Systems Journal, checked November 8, 2026). The team that owns a service knows what a smaller instance or a cheaper model will break, and the cost owner should not be the one who decides that alone.

What it looks like. A pull request in the owning team's repository, with the change, the reason and the expected saving. GitHub describes pull requests as "proposals to merge code changes into a project" (GitHub Docs, checked November 8, 2026). That is exactly what a saving should be.

It replaces a list of findings sent to a team that has no time to read it, and changes made in a console that nobody reviewed.

2. One saving, one change, one rollback

The principle. Each saving travels on its own: one change, one estimate, one way to undo it. Savings are not bundled into a large clean-up.

Why it matters. Small changes are easier to review and easier to reverse. Martin Fowler, writing about infrastructure as code, puts it plainly: "Small updates make it easier to find errors and are easier to revert" (martinfowler.com, checked November 8, 2026). When a smaller instance turns out to be too small, one revert brings it back and every other saving stays in.

What it looks like. A pull request that moves one service to a smaller instance family, with the rollback written in it. A second pull request for the unattached volumes. A third for the Savings Plan.

It replaces the big quarterly clean-up that nobody dares to merge, and the one that breaks something and gets rolled back whole.

3. Estimate before, measure on the bill after

The principle. Every saving carries an estimate when it is proposed. About 30 days after the merge, the real effect is measured on the bill and written down next to the estimate.

Why it matters. An estimate is a forecast, not a result. AWS Cost Optimization Hub, for example, helps you "quantify and aggregate estimated savings" (AWS, checked November 8, 2026). Only the bill says what a change really saved. The cost pillar of AWS Well-Architected lists "Measure overall efficiency" among its design principles (AWS, checked November 8, 2026).

What it looks like. A savings ledger: one line per change, with the estimate, the measured saving and a link to the pull request. Finance can audit it line by line.

It replaces a total of estimated savings that nobody can trace back to the bill.

4. Spend rules live in versioned files

The principle. Budgets, allowed instance families, commitment targets, allowed models per route and token limits are written in files, kept in a repository and changed by pull request, like code.

Why it matters. Rules that sit in a spreadsheet, a wiki and a console drift apart. Policy as code solved this for security rules years ago: Open Policy Agent "lets you specify policy as code" (Open Policy Agent, checked November 8, 2026). The OpenGitOps principles ask for desired state that is "Versioned and Immutable", with "a complete version history" (OpenGitOps, checked November 8, 2026).

What it looks like. A short file per team next to its code. Raising a budget is a pull request with a reason, approved by the person who owns the budget.

It replaces limits agreed in a meeting and remembered by nobody.

5. Check the rule before the money is spent

The principle. A rule is checked when a change is proposed, not only when the bill arrives.

Why it matters. Alerts on spend come after the spend. AWS says it plainly: "There can be a delay between when you incur a charge and when you receive a notification from AWS Budgets for the charge" (AWS, checked November 8, 2026). A check in review stops the change while fixing it is still one pull request.

What it looks like. A check on the pull request that fails when a change would break a budget or use a model outside the allowed list, with the reason in the message. Budget alerts stay, as the second line.

It replaces finding out at the end of the month.

6. Remove waste, then resize, then commit

The principle. Savings follow an order: first delete what nobody uses, then resize what is too large, and only then buy commitments for the steady usage that is left.

Why it matters. A commitment sized to an oversized fleet locks the waste in for one or three years. Removing waste first is also the lowest risk: an unattached volume has no users to disturb.

What it looks like. The first pull requests remove idle resources and old storage. Resizing follows, service by service. The Savings Plan or reservation comes last, sized to what the bill shows after the other changes.

It replaces buying a commitment because it is the quickest saving to sign.

7. Cloud and AI are one practice

The principle. Models are rightsized like instances. A route that calls a large model where a smaller one meets the quality bar is waste, and it is fixed the same way: a reviewed change, measured on the bill.

Why it matters. The price spread is wide. Researchers at Stanford found in 2023 that fees across LLM APIs "can differ by two orders of magnitude" (arXiv, checked November 8, 2026). Providers give the same advice: OpenAI tells teams to "keep the lightest setting that meets your quality bar" (OpenAI, checked November 8, 2026), and Anthropic says to upgrade "only if necessary for specific capability gaps" (Anthropic, checked November 8, 2026).

What it looks like. A pull request that routes one task to a smaller model, with the quality bar results and the cost per request before and after. See Savings as Code for AI.

It replaces AI spend that sits outside every cost review because it arrives on a different invoice.

Where to go next

• Where Cost as Code comes from: the engineering and cost management ideas these principles borrow.
• The lifecycle: what happens to one saving, from finding to the rule that keeps it.
• In practice: how it looks on AWS, with your own tools or with our service.