Cost as Code by MoreThanOps

Roles in Cost as Code

Who proposes a saving, who approves it, who owns the budget, who measures it and who checks it.

Last reviewed

Five figures stand around one pull request card: the implementer writes it, the service owner approves it, the budget owner signs a rule file, finance adds a ledger line and the auditor reads the history.
One change, five roles: each decision sits with the person best placed to make it.

In 30 seconds

  • Service owner: owns the system and approves every change to it.
  • Budget owner: owns a budget and approves changes to the spend rules.
  • Implementer: finds the saving and writes the change, in-house or as a service.
  • Finance: reads the savings ledger and allocates the cost.
  • Auditor: checks that every change was approved and measured.
  • Nobody approves their own change.

Cost as Code works because each decision sits with the person best placed to make it, and because nobody decides alone on a change they wrote. The roles below are roles, not job titles: in a small company one person can hold two of them, as long as they never approve their own change. They appear in the order a saving meets them.

The five roles

Implementer

The person or team that finds savings and turns them into changes. They read the bill and the usage, write the finding with its estimate, open one pull request per saving with the rollback in it, and measure the result on the bill after the merge. The implementer can be an engineer in the team, a central platform or cost team, or an outside service such as ours. Never: merges their own change, or changes an account before the change is approved.

Service owner

The team that owns the code and the system the change touches. They know what a smaller instance, a shorter log retention or a smaller model will break, so they review the change and approve it or decline it with a reason. They also own the rollback if something goes wrong. Never: has a saving pushed onto their system without their review.

Budget owner

The person who answers for a budget: a team lead, a product owner or a head of engineering. They approve changes to the spend rules for their area: a higher budget, a new instance family, a larger model on a route. Never: raises their own budget without a second person approving it.

Finance

The people who report and allocate cloud and AI spend. They read the savings ledger to see what each change saved, compare it with the estimate, and use the owners on each cost line for showback or chargeback. AWS describes showback as cost allocation used "for visibility of cost ownership", and chargeback as recording costs "with the owner in an organization's general ledger" (AWS, checked November 8, 2026). Never: counts an estimate as a saving before the bill confirms it.

Auditor

The people who check that money was spent and saved properly, internal or external. They read the history: who proposed each change, who approved it, when it was merged, what the bill showed afterwards, and who changed each spend rule. Never: needs a report built for them before an audit; the pull requests and the ledger are the record.

Who does what

Step Who What they do
Find Implementer Writes the finding with its estimate and owner
Find Finance Points each cost line to an owner
Fix Implementer Opens one pull request per saving, with the rollback
Fix Service owner Reviews, approves or declines with a reason
Fix Implementer Merges through the usual pipeline once approved
Prove Implementer Measures the saving on the bill about 30 days later
Prove Finance Reads the ledger line and compares it with the estimate
Prevent Implementer or service owner Proposes a spend rule that keeps the saving
Prevent Budget owner Approves changes to the spend rules
Audit Auditor Reads the history of changes, approvals and ledger lines
Who does what at each step of the loop: the implementer proposes, the owners approve, finance and the auditor read the record.

Changes that need two people

Some changes decide what others may spend. Raising a budget, allowing a new instance family or a larger model on a route, or changing who approves the spend rules needs the approval of someone who did not propose it. The person who asks for more budget is never the one who grants it. A saving that touches a shared system, such as a database several teams use, needs the approval of every team that owns a part of it.

Working with an outside implementer

When the implementer is a service, the roles do not move. The service finds the savings and writes the changes; the service owner still approves every change, the budget owner still owns the rules, and finance still reads the ledger. That is how we run our own service, Savings Engine. We find the savings and implement them. You approve every change. More in In practice.

How this relates to FinOps personas

The FinOps Foundation™ describes its own set of personas for an organization's FinOps practice (FinOps Foundation, checked November 8, 2026). The roles on this page are narrower: they describe who does what to one change and one spend rule, not how a whole practice is staffed. One person can hold a persona there and a role here.

Where to go next