Cloud Cost Terminology: The FOCUS-First Reference for AI Billing

The vocabulary you need to read an AI cloud bill — FOCUS field names, AI-specific billing terms, and the cross-service awareness that generic glossaries skip.

Most cloud cost glossaries define "reserved instance" and "on-demand pricing" and stop there. That vocabulary is insufficient for reading an AI cloud bill in 2026. If you do not know what x_UsageType: SearchOCU means, why BilledCost and EffectiveCost diverge on Reserved Instance rows, or why the same AI feature can appear under multiple ServiceName values — you will misread the data and miss the patterns that matter.

This reference is organized into four sections: core FOCUS billing fields, AI-specific terms, cost dimension mechanics, and the cross-service billing awareness problem. Each term includes what it actually contains and the practical implication for detection and analysis.

Section 1 — Core FOCUS Billing Fields

FOCUS (FinOps Open Cost and Usage Specification) is the billing schema standard adopted by AWS, Azure, and GCP. The current version is FOCUS 1.2, available via AWS Data Exports. These are the fields that matter for detection work.

Section 2 — AI-Specific Billing Terms

These terms do not appear in traditional FinOps glossaries because they are specific to AI service billing mechanics introduced after 2022.

OCU — OpenSearch Compute Unit

The billing unit for Amazon OpenSearch Serverless. One OCU represents a fixed amount of compute capacity provisioned for either search (SearchOCU) or indexing (IndexingOCU). The critical mechanic: OCUs are provisioned continuously from collection creation to deletion — not on demand. Minimum: 1 SearchOCU + 1 IndexingOCU. Rate: $0.24/OCU/hour. Floor cost at zero queries: $0.48/hour, $345.60/month. ConsumedQuantity in the billing row is always 1.0 regardless of actual query volume — the floor cost and the peak cost are the same row.

Why it matters: "Serverless" in the product name implies consumption-based pricing. It does not. OCU billing is capacity-based. A collection with zero queries is indistinguishable from a collection serving 10,000 queries/day in the billing data — both show ConsumedQuantity = 1.0. The orphaned collection detection query works by joining on the absence of Bedrock inference activity, not on low OCU consumption.

InvokeModelInference — Bedrock inference billing

The x_UsageType value for Amazon Bedrock model invocation charges. Bedrock bills on token consumption: input tokens and output tokens charged separately at model-specific rates. InvokeModelInference rows have ConsumedQuantity in tokens and BilledCost in fractions of a cent per invocation. Unlike OCU billing, this is genuinely consumption-based — zero invocations produces zero BilledCost rows.

Why it matters: The cross-service detection pattern for orphaned Knowledge Bases depends on the ratio between OCU charges (always present once a collection exists) and InvokeModelInference charges (absent once the team stops using the KB). High OCU cost, near-zero InvokeModelInference cost, in the same account and period: the signature of an orphaned collection.

Provisioned Throughput vs On-Demand (Bedrock)

Bedrock offers two inference pricing models. On-demand: pay per token, no commitment, available immediately. Provisioned throughput: purchase a fixed number of Model Units (MUs) for a 1-month or 6-month term — guaranteed capacity, lower per-token rate, but billed regardless of actual usage. Provisioned throughput rows appear in billing as Purchase ChargeCategory rows (the upfront commitment) and Usage rows (the per-token consumption). If a team purchases provisioned throughput for a model they later stop using, the commitment billing continues until term expiry.

Why it matters: Provisioned throughput waste is the Bedrock equivalent of an unused Reserved Instance — the EffectiveCost stays flat while BilledCost on usage rows drops to zero. Detecting it requires checking for Purchase rows with low corresponding Usage rows.

Embedding Tokens

A distinct billing dimension from inference tokens. Embedding models (used to convert documents into vector representations for Knowledge Base search) bill separately from language model inference. In billing data, embedding usage appears under Bedrock with x_UsageType reflecting the embedding model rather than InvokeModelInference. For a team that has indexed documents but stopped querying, embedding costs drop to zero while OCU costs continue — another variant of the orphaned resource signature.

Section 3 — Cost Dimension Mechanics

These fields appear in every FOCUS row. The distinction between them is not cosmetic — queries that use the wrong cost field produce systematically incorrect results.

BilledCost

What was or will be invoiced. For on-demand resources: the charge for that hour of usage. For a one-year Reserved Instance purchased upfront: the full $365 upfront payment appears as BilledCost on the Purchase row on the purchase date. For the daily usage rows during the RI term: BilledCost is $0 (already billed at purchase).

Use BilledCost for: cash flow analysis, invoice reconciliation, actual invoiced amount in any period.

EffectiveCost

The amortized cost — the purchase price spread over the usage period. For the same one-year RI: the Purchase row has EffectiveCost = $0. Each daily usage row has EffectiveCost = $1 (the $365 purchase ÷ 365 days). Over the full year, total EffectiveCost = $365 = total BilledCost. They represent the same money allocated differently across time.

Use EffectiveCost for: cost anomaly detection, trend analysis, comparing periods — EffectiveCost does not spike on RI purchase dates the way BilledCost does, making it the correct field for baseline detection queries.

ListCost / ListUnitPrice

What the resource would have cost at the public on-demand rate, with no discounts applied. The difference between ListCost and EffectiveCost is your realized discount from RIs, Savings Plans, and volume pricing. Useful for quantifying commitment discount value.

ConsumedQuantity / ConsumedUnit

How much was actually used: GB-hours of storage, OCU-hours of compute, tokens of inference, GB of data transfer. ConsumedUnit is the measurement unit for the quantity. For OCU billing: ConsumedQuantity = 1.0 per hour per OCU, always — the floor is in the rate, not in the quantity. For Bedrock inference: ConsumedQuantity is the token count — this field goes to zero when inference stops, making it useful for detecting idle AI resources.

PricingCategory

How the charge was priced: On Demand, Committed (RI/SP rate applied), Dynamic (Spot), or Other. Useful for filtering commitment utilization analysis — looking at rows where PricingCategory = 'Committed' shows which RI/SP commitments are actually being consumed.

Section 4 — The Cross-Service Billing Problem

The most important concept for AI billing in 2026 is not a field definition — it is an architectural awareness: a single AI feature can generate billing rows under multiple ServiceName values, and the most expensive rows are often under the unexpected service name.

The canonical example: Amazon Bedrock Knowledge Base. One feature, four potential billing dimensions across two services:

A FinOps practitioner who filters Cost Explorer by "Amazon Bedrock" to understand Knowledge Base costs will see 40–60% of the actual cost. The other 60% is under "Amazon OpenSearch Service." This is not a reporting quirk — it is the billing architecture of the feature, and it makes standard FinOps attribution systematically incomplete for AI workloads.

The implication for how you read billing data: ServiceName is a starting point, not a destination. The full picture of any AI feature's cost requires querying by ResourceId patterns (the bedrock-knowledge-base-* naming convention links the two services), by x_UsageType patterns across multiple ServiceName values, and by account-period joins that surface the ratio between related cost streams.

This is what behavioral detection queries do — and why they find patterns that dashboard filtering misses.