Visibility, Tagging, and Allocation

Every FinOps capability rests on one foundation: the ability to take a row in a billing CSV and map it to a meaningful business dimension. Without that, the bill is one giant blob. With it, you can answer "what does Product X cost", "what does Customer Y consume", and "is engineering team Z within budget."

The Raw Data

The default cloud cost UIs (Cost Explorer, Cost Management, BigQuery billing reports) work for small estates. Beyond ~$1M/year cloud spend you typically build or buy something on top.

FOCUS — the Open Billing Standard

FOCUS (FinOps Open Cost and Usage Specification) is a FinOps Foundation project to normalise billing across providers. AWS, Azure, GCP, OCI, and many SaaS vendors now publish FOCUS-compliant exports. The same column names mean the same thing across clouds — so a multi-cloud allocation report is finally tractable without bespoke ETL.

If you start a new pipeline today, target FOCUS rather than the native CUR/BigQuery schema.

Tagging — The Practical Bit

Tags are key/value labels on every resource. The billing exports inherit them so you can group spend by tag value. The catch: only tagged resources have tags, and engineers will not tag without enforcement.

The minimal tag set

Resist designing thirty tags. Standardise on 4-6 mandatory keys:

Define each value as a closed list. Free-text tags create twelve variants of "payments" overnight.

Enforcement

• AWS — Service Control Policies (SCP) to deny resource creation without required tags; AWS Config rules to flag drift; AWS Organizations Tag Policies to standardise values.
• Azure — Azure Policy with required tag / inherit from resource group effects.
• GCP — Organization policy on labels; programmatic enforcement (most tag enforcement happens in Terraform / Pulumi).
• Universal — Terraform / Pulumi modules with required tags input; OPA policies in CI that reject plans missing tags.

Enforce at create time. Retrospective tagging campaigns are wasted effort — engineers move on and the next resource is again untagged.

Untaggable resources

Some resources cannot be tagged or have shared costs that resist allocation: NAT gateways, transit gateways, KMS keys at the account level, support charges, data transfer between AZs.

Two coping patterns:

1. Account-per-team or account-per-product. Untagged costs in an account are de facto allocated to that account's owner. The cleanest model.
2. Proportional allocation. Allocate shared costs to teams in proportion to their tagged spend. Easy to compute, easy to explain, accurate enough for showback.

Account / Subscription / Project Strategy

Tagging is one dimension; the account hierarchy is another, often more reliable.

• AWS — AWS Organizations with Organisational Units; one account per environment per team is common.
• Azure — Management Groups / Subscriptions / Resource Groups; one subscription per environment or per product.
• GCP — Folders and projects; usually one project per environment per service.

The account hierarchy is allocated without needing tags — the IAM and network model already requires the split. Many mature FinOps practices rely on accounts for primary allocation and tags for sub-allocation.

The Allocation Report

The basic monthly report:

Add a column for forecast vs actual, and a drill-down into the top 5 cost drivers per team. That single report drives the weekly FinOps conversation.

Anomaly Detection

Each provider has native anomaly detection:

• AWS Cost Anomaly Detection
• Azure Cost Management Anomaly Detection
• GCP Billing budgets with forecast alerts

They are statistical (often Prophet-style) and trigger when a service / account / linked-account spend deviates from forecast. Free, fast to enable, and catches many "test workload left running" incidents in hours rather than at month-end.

Route anomalies to the owner of the affected resource via tag (using owner or team tags) — not to a generic FinOps inbox.

Showback vs Chargeback

Start with showback. Move to chargeback only when allocation quality is consistently above ~95% and finance / engineering trust each other's numbers. Most organisations never move beyond showback and that is fine.

Forecasting

Native providers do trend-based forecasts. For a more business-driven forecast, combine:

• Time-series of past spend per service
• Known events (product launch, region expansion, customer migration)
• Headcount and project plans
• Commitment expiries

Run forecasts monthly with finance. Variance over 10% drives a conversation; over 20% drives an investigation.

What "Good Visibility" Looks Like

• Every engineer can see their team's daily spend, by service, within their existing dashboards.
• Every product manager can see cost per product, including cost per customer if multi-tenant.
• Finance has a monthly allocation that ties to the GL within 1%.
• Anomalies route to owners automatically within 24 hours.
• The FinOps team spends most of its time on optimisation conversations, not on building reports.

That is the baseline that unlocks all the optimisation work the next four lessons cover.