Glossary

FinOps

Also: Cloud Financial Operations · Cloud cost management

The practice of treating cloud cost as an ongoing technical decision rather than a monthly invoice that lands in accounting.

FinOps assumes that the people who decide architecture also see what it costs. That sounds obvious, but in many organizations it is not the case: the invoice goes to procurement, the decision is made in the team, and a month sits in between. Anyone who only sees the effect of a decision after the books close cannot steer it.

At its core are three recurring steps: make it visible who owns which cost, evaluate the largest levers, and measure the effect after implementation. That loop runs continuously, not as a project. A one-off clean-up lowers the bill for a quarter, then it grows back, because the same forces keep working: every new service brings new metrics, every new pipeline brings new data.

It is worth separating cost optimization from FinOps. Optimization is a measure, FinOps is the ability to take such measures regularly and without a special effort. A team with a FinOps practice does not need a savings campaign, because it reads the bill anyway.

AWS bills rarely explode, they sediment. Four years of growth in which there was always something more important produce a bill where every single decision was defensible at the time and the total is still impossible to explain. That is the typical starting position, not the exception.

The number that matters is not the total but cost per business unit: per thousand requests, per customer, per import. A rising total with faster rising usage is success. Without a reference figure you cannot tell the difference, and it is exactly that difference which moves cost discussions from panic to steering.

Organizationally, FinOps needs two things that have nothing to do with technology: one number per week that is visible to the team, and permission to spend time on it. Without the first, nobody sees the effect. Without the second, cost work loses to feature work every single week.

How you notice it

The cloud bill goes to procurement while the architecture decision is made in the team.
Nobody can say which team causes which share.
Cost only becomes a topic when the bill crosses a threshold.
There is no figure for cost per customer, per request or per transaction.
Observability and analytics show up next to the databases on the bill, although no architecture diagram lists them as a cost centre.

Not to be confused with

Cost optimization: A one-off measure with a start and an end. FinOps is the continuous practice that makes such campaigns unnecessary, because it happens all the time.
Cost Explorer: A tool for the overview. It aggregates by service and therefore answers what is expensive, not why. For the second question you need the Cost and Usage Report.
Savings Plans: A discount in exchange for commitment, so the last step. Committing to an uncleaned infrastructure locks in the waste for one to three years.

When it fits

The monthly AWS bill is in the four-figure range or above.
Several teams deploy into the same accounts.
The bill has grown faster than usage over the past twelve months.
Before a commitment decision: clean up first, then commit.

When it does not

At a few hundred euros a month the analysis costs more than it finds.
During an ongoing migration: the target architecture is not settled yet, so optimizing against it is premature.
As a substitute for an architectural decision. If a workload is fundamentally unnecessary, no discount on it helps.

How to approach it

Establish attributionMandatory tags for team, environment, application and cost centre, enforced through tag policies and checks in the IaC pipeline. A voluntary tag is missing on a third of resources after six months, and then every report is worthless.
Make the raw data availableExport the Cost and Usage Report with resource IDs to S3 and make it queryable with Athena. One hour of work, after which you answer cost questions with SQL instead of guesses.
Group by usage type, not by service"CloudWatch: 2,600 euros" is not information. Only the breakdown by usage type shows whether it is metrics, logs or dashboards, and those have completely different causes.
Keep the orderDeletion and retention, then observability, then data, then rightsizing, then architecture, and only at the very end commitments. Starting with the last step makes every earlier one economically pointless.
Measure the effect, do not estimate itMeasure usage, so hours, gigabytes, terabytes scanned and requests, not only euros. Credits, discounts and tax distort the invoice total; usage does not lie.
Prevent regrowthBudgets with alerts per account, anomaly detection, retention rules as mandatory parameters in the IaC modules, and one cost number per week in the team channel. Without this step the savings are gone again within twelve months.

Frequently asked

Where do you start with FinOps?

With attribution, not with saving. As long as it is unclear which cost belongs to which team and which application, every measure stays a management topic. Once attribution exists, teams decide for themselves, because they can see what their architecture does to the bill.

How much can realistically be saved?

It depends on how long nobody has looked. An account someone reviews regularly might give up 20 to 30 per cent. In a grown account with four years of sediment I reached a good 83 per cent over twelve months, from around 15,000 to around 2,500 euros a month, with no compromise on production availability. The method transfers, the percentage does not.

Do you need a FinOps tool for this?

Not for two or three accounts. The Cost and Usage Report plus an afternoon of SQL finds the same things as a tool that permanently costs a percentage of the savings. At hundreds of accounts the calculation looks different. The uncomfortable truth about these tools: finding is not the problem, changing is the problem, and no dashboard does that for you.

How do you stop cost from growing back?

With four things: enforced mandatory tags, budgets with alerts per account rather than only for the whole organization, retention rules as mandatory parameters in the IaC modules, and a weekly cost number visible to the team. Without countermeasures the same forces that drove the bill up keep working.

Does operation have to be paused for this?

No. The first three phases, so deletion, observability and data, work without a single architectural change and usually account for the larger part of the savings. Only one rule matters: never delete immediately, stop first, wait two weeks, then delete.