Skip to main content
Week 1

FOCUS Recap for Analysts + The Toolkit

The five-minute version of what FOCUS is, the four numbers every charge carries, and the query environment you'll use for the next five weeks — against a real multi-cloud scenario you'll keep coming back to.

~20 min read · Text + interactive

By the end of this lesson, you can…

  • Place FOCUS in one sentence — what it is, why it exists, and how many providers now publish it natively — without re-deriving the whole spec.
  • Pick the right one of ListCost, ContractedCost, BilledCost, or EffectiveCost for a given analyst question, from memory.
  • Query a FOCUS-normalized dataset with SQL and pull results into pandas for further slicing.
  • Read FOCUS's account and resource hierarchy (BillingAccountId, SubAccountId, ResourceId, Tags) on a real row.
  • Reproduce a query from the FinOps Foundation's FOCUS Use Case Library and write commentary on what it actually shows.

FOCUS, in 90 Seconds

If you came from a fundamentals course (or just already know your way around a FOCUS export), this is a recap, not a re-teach. FOCUS — the FinOps Open Cost and Usage Specification — is one normalized billing schema that replaces every provider's own export format. Instead of learning AWS's Cost and Usage Report, then Azure's Cost Management export, then GCP's BigQuery billing export as three separate schemas, you learn one set of column names and apply it everywhere. It's now published natively by 11+ FOCUS-conformant providers, including AWS, Azure, GCP, Oracle, and Alibaba Cloud — and that list is the reason this course can teach cross-cloud analysis as a single skill instead of three.

That's it for the recap. The rest of this lesson, and the four weeks after it, assume you can already read a FOCUS row — ChargeCategory, ServiceCategory/ServiceSubcategory, ChargeClass, the two period pairs — and spends its time on what an analyst actually does with one.

The Four Cost Lenses, One Table

You've seen ListCost, ContractedCost, BilledCost, and EffectiveCost before. What matters at the analyst level isn't the definitions — it's picking the right one under time pressure, when someone in Slack wants a number in the next ten minutes.

MetricFormulaQuestion it answersReach for it when…
ListCostPricingQuantity × ListUnitPriceWhat would this cost with zero discounts at all?Baselining how much leverage every other number represents
ContractedCostPricingQuantity × ContractedUnitPriceWhat does our negotiated rate get us, before any commitment?Measuring the value of an EDP or private pricing agreement on its own
BilledCostThe actual invoiced amountWhat did the invoice actually charge for this row, this period?Reconciling to AP, closing the books, anything that has to tie to a real payment
EffectiveCostAmortized, recognized costWhat did this really cost us, once commitments are smoothed out?Forecasting, showback/chargeback, and every unit-economics model in this course

The two highlighted rows are the ones you'll actually reach for most weeks. BilledCost and EffectiveCost diverge whenever a commitment (RI, Savings Plan, CUD) is in play — Week 3 spends an entire lesson on exactly that divergence, because it's the single most common source of a wrong number in a FinOps report.

Setting Up a Real Query Environment

Every exercise in this course runs against real, FOCUS-normalized data — not a toy CSV you'd never see in production. Two tools do essentially all of the work:

The FOCUS Sandbox
A hosted query environment at focus.finops.org/sandbox that runs SQL directly against real (anonymized) FOCUS data from AWS, GCP, and OCI, blended with sample data from Microsoft. Pick a use case, run it, read the result — no local setup required.
SQL over your own FOCUS exports
The same queries you run in the Sandbox work unmodified against a real warehouse table loaded from AWS Data Exports, the Azure Cost Management FOCUS export, or a GCP FOCUS BigQuery view — the whole point of the spec is that the column names don't change.
pandas, for ad hoc slicing
Once a query result is bigger than you want to eyeball in a terminal, pull it into a DataFrame. Every anomaly-detection and unit-economics exercise in Weeks 4 and 5 leans on pandas for exactly this.
Python/pandas · same GROUP BY, done outside SQL
import pandas as pd

df = pd.read_csv("meridian_focus_export_2026-08.csv")

by_category = (
    df[df["ChargeCategory"] == "Usage"]
    .groupby("ServiceCategory")["EffectiveCost"]
    .sum()
    .sort_values(ascending=False)
)

print(by_category.round(2))

This course uses one running scenario across all five weeks so the numbers build on each other instead of resetting every lesson: Meridian Retail, whose production checkout and catalog services run on AWS (us-east-1), a secondary EU-facing deployment runs on Azure (eastus2), and the data platform runs on GCP (us-central1). All three exports are already FOCUS v1.4-normalized and loaded into one warehouse table, focus_cost_and_usage, for August 2026 onward. You'll see this same account structure again in Weeks 2 through 5.

The Account and Resource Hierarchy

Before you can group, filter, or attribute anything, you need to know which columns actually identify who a charge belongs to. FOCUS gives you four levels, from broadest to most specific:

Broadest

BillingAccountId

The account an invoice is issued to — for Meridian, one per cloud provider relationship.

Team-level

SubAccountId

A sub-account, project, or subscription under that billing account — Meridian's checkout service has its own.

Resource-level

ResourceId

The specific resource the charge is for, in the provider's own native ID format (an ARN, a resource URI, etc.).

Free-form

Tags

Key-value metadata the account owner applied themselves — team, cost-center, environment — for attribution SQL can't infer on its own.

One row from Meridian's checkout service, hierarchy columns only
BillingAccountId:  acct-meridian-prod
SubAccountId:      acct-checkout-svc
ResourceId:        arn:aws:ec2:us-east-1:111122223333:instance/i-0a1b2c3d4e5f67890
Tags:              {"team": "checkout", "cost-center": "CC-4410", "env": "production"}

Notice what each level buys you: BillingAccountId alone tells you which cloud relationship this is, SubAccountId tells you which team or service owns it, ResourceId pins it to one physical thing, and Tags carries whatever your organization decided mattered (a cost-center code finance can map to a budget, an environment flag that separates production from staging spend). Week 5's allocation section comes back to exactly this hierarchy when it draws the line between showback and chargeback.

Exercise: Reproduce Your First Use Case Library Query

The FinOps Foundation's FOCUS Use Case Library (focus.finops.org/use-cases) is a maintained set of real SQL queries against FOCUS-conformant data, organized by category — Reporting & Analytics, Rate Optimization, Invoicing & Chargeback, and more. Before writing anything custom, an analyst checks whether the question is already answered here. Start with the simplest one in the Reporting & Analytics category: a sanity-check breakdown of spend by ChargeCategory.

The question: for Meridian's August 2026 billing period, how does total EffectiveCost split across ChargeCategory, and does anything look off before you trust the rest of the number?

Write the query yourself first — group EffectiveCost by ChargeCategory for August 2026 — then reveal to compare against a working version and its result.

Quick Check: Is the Unfiltered Query Safe to Ship?

A teammate writes SELECT SUM("EffectiveCost") FROM focus_cost_and_usage WHERE "ChargePeriodStart" >= '2026-08-01' AND "ChargePeriodStart" < '2026-09-01' and calls the result "August spend," no other filters.

Is that number safe to hand to Finance as-is?

Reveal my answer

It depends what question it's answering, and that's the whole point of doing the exercise above first. As a rough gut-check of total recognized cost for the month, it's not wrong — it includes Tax and Adjustment, which genuinely are part of what the org owes. But the moment the question becomes comparative ("which service costs the most," "which cloud is cheaper for Compute"), leaving Tax, Credit, Adjustment, and Purchase rows mixed in with Usage will distort the ranking, because those rows don't scale with actual consumption the way Usage rows do. Know which question you're answering before you decide whether the filter matters — Week 2 makes this the very first rule of any cross-cloud query.

Reflection

Run the ChargeCategory breakdown query above (or its equivalent) against your own environment's FOCUS export, or against the FOCUS Sandbox if you don't have one handy. What's your Usage-to-Tax ratio, and does anything in the Adjustment or Credit rows surprise you?

Putting it together

You now have the four cost lenses as a decision table instead of four definitions, a working query environment (Sandbox or your own export, plus pandas for anything bigger than a terminal), a read on the account hierarchy that every allocation exercise in this course depends on, and a working habit of checking the Use Case Library before writing a query from scratch. Meridian Retail's August 2026 data is the scenario you'll keep working against for the rest of the course — next week, you put ProviderName, ServiceCategory, and EffectiveCost together to actually compare AWS, Azure, and GCP against each other.

Week 1 of 5 complete20%
Up next

Week 2: Cross-Cloud Cost Comparison

Normalizing spend across ProviderName and ServiceCategory, filtering ChargeCategory before you compare anything, and writing the query that ranks AWS, Azure, and GCP against each other.

That's Week 1.

This is one lesson from the full FinOps Certified FOCUS Analyst course.

See the full course →