The bill records what happened, not why
Every month the cloud provider's bill arrives. It carries a total, a breakdown by service and thousands of usage lines. It is accurate, and even so it almost never answers the question that matters when the number goes up: why?
The bill is designed to charge you, not to help you decide. It groups things by what the provider sells (compute hours, gigabytes stored, requests), not by what your organisation does (products, teams, customers). As long as cost is read only from the bill, every increase ends in the same meeting: someone looks at the total, nobody knows what changed, and the conclusion is 'we need to cut', without knowing where.
Three questions the bill does not answer
Who consumes it? A single database service may be serving three applications belonging to three different teams. The bill shows it as one line.
For which product or customer? If you do not know how much it costs to serve a product, you do not know whether that product is profitable. Nor can you explain why cost grew when the business grew, or whether it grew without the business growing at all.
How much should it cost? Without a reference, any number looks reasonable or alarming depending on the day. Cost is only understood when compared against something: the previous month, an estimate made before deploying, or the cost per unit of business (per user, per transaction, per customer).
What changes when cost is normalised
The first obstacle is technical: every provider describes its billing with its own format, its own columns and its own names. Comparing AWS with Azure or with GCP, or simply adding them up, forces you to translate by hand.
FOCUS (FinOps Open Cost and Usage Specification) is the FinOps Foundation's open standard that solves this: it defines a common format for cost and usage data, so that billing from different providers can be read with the same columns and the same rules. The major providers already offer exports in that format, or are adopting it.
With cost normalised, the three questions stop being impossible:
- Who consumes it comes from allocation: tags and accounts that attribute each resource to a team and an application.
- For which product comes from grouping that allocation by what the organisation sells.
- How much it should cost comes from comparing against a prior estimate and from measuring cost per unit.
Where to start
You do not need a platform to take the first step. You need order:
- Inventory of accounts and exports. Know which accounts, subscriptions and projects exist in each cloud, and switch on detailed billing exports in all of them.
- Normalise with FOCUS. Bring those exports into a common format, in a single place, so they can be added up and compared.
- Assign owners. Tag resources by application and team, and decide what to do with whatever carries no tag (which at first will be a great deal).
- Pick one unit metric and review it every month. Just one, tied to the business, with an owner who explains it when it moves.
The goal is not to spend less at any price. It is for every increase in cost to have an explanation, and for that explanation to arrive before the next bill does.
In short
The cloud bill is a charging document. Deciding takes something else: cost that is normalised, allocated and compared. Once that exists, the conversation stops being 'why did it go up?' and becomes 'is it worth what it costs?'.
If your cloud cost is growing and nobody knows why, FinOps Engineering sets out how we approach it.