Cost as Code by MoreThanOps

Where Cost as Code comes from

Two traditions meet here, one from software engineering and one from cloud financial management.

Last reviewed

Two timelines run side by side, one with code review, infrastructure as code, GitOps and policy as code, the other with cost reports, budgets and showback; they bend toward each other and meet in a single pull request card.
Engineering learned to manage change. Cost management learned what to change. Cost as Code joins them.

In 30 seconds

  • From engineering: reviewed changes (1976), declared configuration (1995), infrastructure as code, GitOps (2017) and policy as code (2016 onwards).
  • From cost management: the FinOps Foundation™ (2019), cloud financial management in AWS Well-Architected, showback, chargeback and a common billing data format.
  • The gap: findings with estimates are easy to get; changes that reach the bill are not.
  • Cost as Code applies the first tradition to the second: every saving is a reviewed change, and the bill is the test.

Cost as Code is less an invention than a meeting point. Software engineering learned to manage change with version control, review and declared state. Cloud cost management learned what to measure, who should own each cost, and where the waste usually is. Each half has its own history; this page traces both. Every source on this page was checked on November 8, 2026.

From engineering: change as reviewed code

Review before it ships. Formal review of a change by someone other than its author goes back at least to Michael Fagan's design and code inspections at IBM, published in 1976 (IBM Systems Journal, checked November 8, 2026). The pull request is the everyday form of that idea today: GitHub describes pull requests as "proposals to merge code changes into a project" (GitHub Docs, checked November 8, 2026).

Declare the desired state. Mark Burgess described CFEngine, "A Site Configuration Engine", in 1995: machines configured from files that declare how they should be (USENIX, checked November 8, 2026). That idea grew into infrastructure as code, which Martin Fowler describes as "defining computing and network infrastructure through source code that can then be treated just like any software system" (martinfowler.com, checked November 8, 2026). Terraform, announced in July 2014, brought execution plans that "show you what changes Terraform plans on making to your infrastructure" before they are made (HashiCorp, checked November 8, 2026).

Operations by pull request. In August 2017 Weaveworks named GitOps, "our name for how we use developer tooling to drive operations", with the line "Operational changes are made by pull request" (Weaveworks, archived, checked November 8, 2026). The OpenGitOps project later wrote the principles down: declarative, versioned and immutable, pulled and continuously reconciled (OpenGitOps, checked November 8, 2026).

Rules as code. Policy as code put rules into versioned files that tools check. Open Policy Agent published its first release in July 2016 (GitHub, checked November 8, 2026) and graduated in the Cloud Native Computing Foundation in February 2021 (CNCF, checked November 8, 2026).

Two traditions, one method: how engineering manages change, applied to what change costs.

From cloud financial management

A discipline with a name. The FinOps Foundation™ was founded in February 2019, and in June 2020 it merged with the Linux Foundation (FinOps Foundation, Linux Foundation, checked November 8, 2026). The book "Cloud FinOps" by J.R. Storment and Mike Fuller was published by O'Reilly in 2020, with a second edition in 2023 (FinOps Foundation, Open Library, first edition, Open Library, second edition, checked November 8, 2026). The Foundation describes FinOps work in three iterative phases: Inform, Optimize and Operate (FinOps Foundation, checked November 8, 2026).

Cost in the architecture. AWS put cost into its Well-Architected Framework as a pillar of its own, with design principles such as "Implement cloud financial management" and "Analyze and attribute expenditure" (AWS, checked November 8, 2026).

Owners for every cost. Showback and chargeback became standard practice. AWS describes cost allocation used "for visibility of cost ownership, often referred to as 'showback'", and chargeback as recording costs with their owner in the general ledger (AWS, checked November 8, 2026). Unit economics asks what each unit of business costs, such as "the cost per ride" for a rideshare company (FinOps Foundation, checked November 8, 2026).

One format for billing data. The FinOps Open Cost and Usage Specification (FOCUS™) is "an open specification that normalizes billing datasets" (FOCUS, checked November 8, 2026). Version 1.0 was announced in June 2024 (FinOps Foundation, checked November 8, 2026).

Where the work stops

Finding waste is well served. AWS Cost Optimization Hub, for example, consolidates recommendations and helps you "quantify and aggregate estimated savings" (AWS, checked November 8, 2026). AWS shows where to look; most of the work is still yours.

That work is where teams slow down. In a 2025 survey of 700 respondents in the US and the UK, an estimated 21% of enterprise cloud infrastructure spend was wasted, 61% of developers did not rightsize instances, and enterprises took an average of 31 days to identify and eliminate cloud waste (Harness, checked November 8, 2026). In the State of FinOps 2026, "workload optimization and waste reduction" remain the top current priority for FinOps teams (State of FinOps, checked November 8, 2026).

The gap is not a lack of findings. It is the distance between a finding and a merged change that someone owns, that can be undone, and that shows up on the bill.

Cost review meets code review

Engineering already had the answer to that distance: changes are proposed, reviewed, merged and reverted in one place, with a history. Cost can join that review: a team can see what a change will cost before it ships. What Cost as Code adds is the other direction: the saving itself arriving as a reviewed change, with its result checked on the bill.

What Cost as Code adds

Cost management knew what to change: the idle resource, the oversized instance, the uncovered steady usage, and now the oversized model. Engineering knew how to change things well: in files, by pull request, reviewed by the owner, easy to revert. Cost as Code applies the second to the first:

  • The change and its approval are one pull request, with the estimate and the rollback in it.
  • The bill is the test. About 30 days after the merge, the saving is measured and recorded in a savings ledger.
  • The rule that keeps the saving lives in the same repository, checked in review before money is spent.
  • Cloud and AI are one practice: models are rightsized like instances.

The FinOps Foundation does not endorse Cost as Code, and Cost as Code is not part of the Foundation's work. It is one way to do the implementing work with the habits of software teams.

Where to go next