The Cost as Code lifecycle
What happens to one saving over its life, what a team needs for each step, and what the method covers.
In 30 seconds
- Find: a finding on the bill, with its estimate.
- Fix: one pull request, with its rollback, approved by the team that owns the system.
- Prove: about 30 days after the merge, the saving is measured on the bill and recorded in a savings ledger.
- Prevent: a spend rule in a versioned file, checked before the money is spent, so the waste does not come back.
The principles say how spend should be managed. The lifecycle says what happens to one saving over its life, which pieces a team needs for each step, and where the method starts and stops. Roles and the maturity model complete it.
The loop of a saving
1. Find
A finding names one thing that costs more than it should: an idle resource, an instance larger than its load, steady usage with no commitment, a task routed to a larger model than it needs. Each finding carries an estimate and an owner. Cloud providers help with this step. 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.
2. Fix
The finding becomes a change. This is where the five steps of Savings as Code sit: the saving is proposed as one pull request with its rollback, the owning team reviews and approves it, and it is merged through the usual pipeline. If the team does not use infrastructure as code, the pull request goes to a small change-log repository and the change is made in the console only after it is approved there.
3. Prove
About 30 days after the merge, the saving is measured on the bill and written down next to its estimate: one line per change in a savings ledger, with a link to the pull request. When the measured saving differs from the estimate, the ledger shows it, and the next estimate is better for it.
4. Prevent
A saving that is not protected creeps back: a new service on a default size, a model upgrade on one route. Prevent adds a spend rule that keeps the saving: an allowed instance family, a budget, an allowed model per route. The rule lives in a versioned file and is checked when a change is proposed. A change that would break it fails its check, which starts a new finding. This step is the idea behind Spend as Code, which is coming soon.
What a team needs
Each piece serves one or more steps. A team can build them, buy them, or mix both.
| Piece | What it does | Steps |
|---|---|---|
| Cost and usage data | The bill at resource level, ideally in an open format | Find, Prove |
| Owners for each cost | Every cost line points to a team that can change it (showback or chargeback) | Find, Fix |
| Findings with estimates | Each candidate saving with its expected effect a month | Find |
| Change proposals | One pull request per saving, with the reason, the estimate and the rollback | Fix |
| Approval rules | Who approves which change; nobody approves their own | Fix |
| Savings ledger | One line per merged change: estimate, measured saving, link | Prove |
| Measurement on the bill | The same cost line compared before and after the merge | Prove |
| Spend rules file | Budgets, allowed instance families, allowed models per route, token limits | Prevent |
| Checks | The rules checked in review, in the cloud account and in the AI gateway | Prevent |
Cost and usage data can follow a common format, the FinOps Open Cost and Usage Specification (FOCUS™), "an open specification that normalizes billing datasets" (FOCUS, checked November 8, 2026). Owners per cost come from cost allocation, which AWS describes as used "for visibility of cost ownership, often referred to as 'showback'" (AWS, checked November 8, 2026). Budgets in the cloud account alert "when costs approach or exceed your defined threshold" (AWS, checked November 8, 2026).
How it relates to the FinOps phases
The FinOps Foundation™ describes FinOps work in three iterative phases: Inform, Optimize and Operate (FinOps Foundation, checked November 8, 2026). Those phases describe a whole practice across an organization, from visibility to running it day to day.
The Cost as Code lifecycle is narrower. Its unit is one change, and its test is the bill. It does not replace the phases, and it is not a version of them; it describes how one saving moves from a finding to a merged, measured and protected change, with the habits of software teams. A team that already runs a FinOps practice can use it for the implementing work.
Scope: what the method covers
In scope. Changes to cloud resources (sizes, families, storage, idle resources, schedules), commitments such as Savings Plans and reservations, AI model routes and token use (model choice, caching, batch, output limits), and the spend rules that protect each saving.
Out of scope. Forecasting, the yearly budgeting process, negotiating prices with providers, and invoicing. Those are finance work that Cost as Code feeds with data (the ledger, the owners), but does not run.
Where to go next
- Roles: who proposes, who approves, who owns the budget and who audits.
- Maturity model: from measured spend to guarded spend, and how to measure progress.
- In practice: the lifecycle on AWS, with your own tools or with our service.