N100FN100F
Published on

FOCUS explained

FOCUS is the open standard that gives every provider's billing the same columns and the same meaning. What it solves, what it does not, and why it is worth adopting from the start.

Service line FinOps Engineering

The problem it solves

Every cloud provider delivers its billing in its own format: different column names, different units, different ways of representing discounts and commitments. Anyone working with more than one provider ends up maintaining a translation for each, and every translation is a place where errors creep in.

FOCUS (FinOps Open Cost and Usage Specification) is an open specification, driven by the FinOps Foundation, that defines a common format for cost and usage data: which columns exist, what each one means and what values they can take. The major providers already offer FOCUS exports or are adopting them, and the specification evolves through versions.

Which columns matter to begin with

You do not need to know them all. A handful answers most of the questions:

Column mapping into FOCUSThe AWS, Azure and GCP column name for cost, date, service and account, and its equivalent FOCUS column.FINOPS · THE FOCUS STANDARDEvery provider calls it something differentHOW MUCH IT COSTAWSlineItem/UnblendedCostAzureCostInBillingCurrencyGCPcostBilledCostWHENAWSlineItem/UsageStartDateAzureDateGCPusage_start_timeChargePeriodStartWHICH SERVICEAWSlineItem/ProductCodeAzureMeterCategoryGCPservice.descriptionServiceNameWHICH ACCOUNTAWSlineItem/UsageAccountIdAzureSubscriptionIdGCPproject.idSubAccountIdSimplified mapping: the exact one depends on the FOCUS versionand on each provider's export type.N100F · n100f.com

  • What was consumed: the service and its category (ServiceName, ServiceCategory), the charge type (ChargeCategory: usage, purchase, tax, credit, adjustment) and the period (ChargePeriodStart).
  • How much it cost: the four readings of cost (ListCost, ContractedCost, BilledCost, EffectiveCost) and the quantities consumed.
  • Whose it is: the account or sub-account (SubAccountId), the tags (Tags) and the relationship with commitments (CommitmentDiscountId).

Exact names may vary between versions of the specification. It is therefore worth pinning down which version you work with and reviewing it when that changes.

What it solves and what it does not

It solves: that a query written once works for every provider; that 'effective cost' means the same thing in AWS as in Azure or GCP; that adding and comparing stops being an exercise in translation.

It does not solve:

  • The quality of the source data. If the export brings duplicate rows or badly reflected commitments, FOCUS brings them through just the same.
  • Allocation. FOCUS tells you which account each cost comes from and with which tags, but not which team or product it belongs to if the tags are missing.
  • Each provider's particularities. Some information does not fit in the standard columns; the specification allows provider-specific columns, which have to be handled separately.

Adopting it from the start

The practical recommendation is to use FOCUS as your internal working format from day one, even with a single provider. If another one is added tomorrow, nothing has to be rebuilt: you simply add one more translation into the same format.

FOCUS is the central layer, but not the only one. Getting from raw data to data you can decide on takes several more layers. That is the next article.

How we apply it: FinOps Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk