Cost as Code by MoreThanOps

Cost as Code in practice

What the method looks like on AWS today, with the tools you already have or with our service.

Last reviewed

A split screen: on the left, an engineer's to-do list of findings grows longer; on the right, the same findings turn into pull request cards that are approved one by one, and the monthly bill bar beneath them shrinks.
The same method two ways: with your own tools, or with us doing the work and you approving every change.

In 30 seconds

  • By hand: findings from AWS's own tools, changes as pull requests in your repo, a savings ledger in a file, budgets and alerts in the account. AWS shows where to look; most of the work is still yours.
  • With Savings Engine: a service. We find the savings and implement them. You approve every change.
  • Spend as Code is coming soon.

The principles and the lifecycle do not depend on a tool. This page shows them on AWS, where most of our work happens today, and two ways to put them in place: with the tools you already have, or with our service doing the work while your team approves it.

By hand, with tools you already have

You can run the whole loop with what most AWS teams already have.

  1. Find. Start from AWS's own recommendations. AWS Cost Optimization Hub can "consolidate and prioritize cost optimization recommendations" and helps you "quantify and aggregate estimated savings" (AWS, checked November 8, 2026). Add an owner and a baseline month to each finding you keep.
  2. Fix. Turn each finding into one pull request in the repository that defines the resource, with the estimate and the rollback in the description. If the resource was created in the console, open the pull request in a small change-log repository instead and make the console change only after it is approved.
  3. Prove. About 30 days after the merge, compare the cost line with its baseline and add a line to a savings ledger: a file in the same repository works well, with the estimate, the measured saving and a link to the pull request.
  4. Prevent. Set budgets per team or account. AWS Budgets lets you "set spending limits for services and receive alerts when costs approach or exceed your defined threshold" (AWS, checked November 8, 2026). Keep the limits in a file in the repository too, so changing one is a reviewed change.

The limits you will meet. AWS shows where to look; most of the work is still yours. Someone has to read each recommendation against the real load, decide what is safe, write the change, chase the review and come back a month later to measure it. Budget alerts speak after the money is spent: AWS notes "a delay between when you incur a charge and when you receive a notification" (same source). And AI spend on model providers sits outside these tools, so model choice and token use need their own review. That work is what usually waits behind the sprint.

With Savings Engine

Savings Engine by MTO FinOps is a service, not software you install. People do the work. We find the savings and implement them. You approve every change.

  • A free review first. $0 upfront. We review your AWS bill and usage. During the review we only look.
  • One pull request per saving, in your repository or a change-log repository, with the estimate and the rollback. Your team approves each one like any other change.
  • Measured on the bill about 30 days after each merge, and recorded in a savings ledger you keep.
  • The order of work: waste first, then resizing, then commitments sized to the steady usage that is left.

The fee. You pay 50% of what you save for 6 months. Then 100% is yours. You only pay on savings that show up on your AWS bill. Savings Plans or reservations we buy for you count. The ones you already had don't.

A company spending about $42k a month on AWS can save about $6k a month*.

*Illustrative example.

Side by side

By hand With Savings Engine
Who finds the savings Your team, from AWS's recommendations and its own review We do, in a review of your AWS bill and usage
Who writes the change Your engineers We do, one pull request per saving
Who approves The team that owns the system The team that owns the system
Who measures Your team, if someone has the time We do, on the bill, about 30 days after each merge
The record A ledger file you keep up to date A savings ledger, one line per change
What it costs Your team's time 50% of what you save for 6 months, then nothing

In both columns the approval stays with your team. That is the part of the method that does not change.

Two ways to run the loop. The approval gate is the same in both: your team approves every change.

Spend as Code: coming soon

Coming soon Spend as Code is a solution we are building. It is not for sale yet.

Savings creep back: a new service on a default size, a model upgrade on one route. Spend as Code is the idea of keeping every spend rule for cloud and AI (budgets, allowed instance families, allowed models per route, token limits) in one versioned file, checked in review, in the cloud account and in the AI gateway. Until it exists, the by-hand version above is the way to start: a short file of limits in the repository, and budgets in the account.

For AI spend

The same loop applies to models. A route that calls a large model where a smaller one meets the quality bar is waste, fixed with one reviewed change and measured on the invoice. See Savings as Code for AI. Our review of model and token costs is coming soon; today our review covers your AWS bill.

Where to go next