Publication version 1.1
Copyright © 2024 – FinOps Open Cost and Usage Specification (FOCUS) aSeries of the Joint Development Foundation Projects, LLC. LinuxFoundation
This section describes the status of this document at the time of itspublication.
This is a published release of the FinOps Open Cost and UsageSpecification.
This document was produced by a group operating under the JointDevelopment Foundation Projects agreement. FOCUS maintains a public listof any patent disclosures made in connection with the deliverables ofthe group;
Copyright (c) Joint Development Foundation Projects, LLC, FinOps OpenCost and Usage Specification (FOCUS) Series and its contributors. Thematerials in this repository are made available under the CreativeCommons Attribution 4.0 International license (CC-BY-4.0), available at[
This work is made available under:
THESE MATERIALS ARE PROVIDED “AS IS.” The parties expressly disclaimany warranties (express, implied, or otherwise), including impliedwarranties of merchantability, non-infringement, fitness for aparticular purpose, or title, related to the materials. The entire riskas to implementing or otherwise using the materials is assumed by theimplementer and user. IN NO EVENT WILL THE PARTIES BE LIABLE TO ANYOTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL,INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OFACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNINGAGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDINGNEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEENADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This document is governed by the Patent Policy Option 4: W3C Mode:See
FOCUS is an open-source specification for billing data. It defines a common schema for billing data, aligns terminology with the FinOpsFramework and defines a minimum set of requirements for billing data. The specification provides clear guideline for billing data generators to produce FinOps-serviceable data. The specification enables FinOps practitioners to perform common FinOps capabilities such as chargeback,cost allocation, budgeting and forecasting etc. using a generic set of instructions, regardless of the origin of the FOCUS compatible dataset.
Thanks to the following FOCUS Maintainers for their leadership andcontributions to the FOCUS Release v1.1specification.
Thanks to the following FOCUS members for their contributions to theFOCUS Release v1.1 specification.
Thanks to the following FOCUS Steering Committee members for theirleadership on the FOCUS specification.
This section is non-normative.
FOCUS aims to establish a community-driven specification forconsumption-based billing data. Due to the lack of a broadly adoptedspecification, infrastructure and services
The FOCUS specification’s schema definition and FinOps-alignedterminology provide a clear guide for producing FinOps-serviceablebilling datasets. Datasets conforming to FOCUS enable FinOpspractitioners to perform common FinOps capabilities, like the onesmentioned above, using a generic set of instructions, regardless of theorigin of the dataset.
This project is supported by the
This specification is designed to be used by three major groups:
The FOCUS working group will develop an open-source specification forbilling data. The schema will define data
The following principles were considered while building thespecification.
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,”SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and”OPTIONAL” in this specification are to be interpreted as described inBCP14 [
Under each column defined in the FOCUS specification, there exists a’Feature level’ designation that describes the column as ‘Mandatory’,’Conditional’, or ‘Optional’. Feature level is designated based on thefollowing criteria described in the normative requirements in eachcolumn definition:
There are no current resources available to test for specificationconformance or validators to run on sample data. When one becomesavailable, this section of the specification will be updated withdetails.
The FOCUS specification defines a group of columns that providequalitative values (such as dates, resource, and provider information)categorized as “dimensions” and quantitative values (numeric values)categorized as “metrics” that can be used for performing various
An availabilityzone is a provider-assigned identifier for a physicallyseparated and isolated area within a Region that provides highavailability and fault tolerance. Availability Zone is commonly used forscenarios like analyzing cross-zone data transfer usage and thecorresponding cost based on where
The AvailabilityZone column is RECOMMENDED to be present in a
AvailabilityZone
Availability Zone
A provider-assigned identifier for a physically separated andisolated area within a Region that provides high availability and faulttolerance.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The billed costrepresents a charge serving as the basis for invoicing, inclusive of theimpacts of all reduced rates and discounts while excluding the
The BilledCost column MUST be present in a
BilledCost
Billed Cost
A charge serving as the basis for invoicing, inclusive of all reducedrates and discounts while excluding the amortization of upfrontcharges (one-time or recurring).
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid decimal value |
A Billing Account ID is a provider-assigned identifier for a
The BillingAccountId column MUST be present in a
See Appendix:Grouping constructs for resources or services for details andexamples of the different grouping constructs supported by FOCUS.
BillingAccountId
Billing Account ID
The identifier assigned to a billing account by theprovider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
A Billing Account Name is a display name assigned to a
The BillingAccountName column MUST be present in a
See Appendix:Grouping constructs for resources or services for details andexamples of the different grouping constructs supported by FOCUS.
BillingAccountName
Billing Account Name
The display name assigned to a billing account.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Billing currency isan identifier that represents the currency that a charge for
The BillingCurrency column MUST be present in a
BillingCurrency
Billing Currency
Represents the currency that a charge was billed in.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | CurrencyCode Format |
Billing Period End represents the
The BillingPeriodEnd column MUST be present in a
BillingPeriodEnd
Billing Period End
The exclusive enddate and time of a billingperiod.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/TimeFormat |
Billing Period Start represents the
The BillingPeriodStart column MUST be present in a
BillingPeriodStart
Billing Period Start
The inclusive startdate and time of a billingperiod.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/TimeFormat |
A Capacity Reservation ID is the identifier assigned to a
The CapacityReservationId column adheres to the followingrequirements:
CapacityReservationId
Capacity Reservation ID
The identifier assigned to a capacity reservation by theprovider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Capacity Reservation Status indicates whether the charge representseither the consumption of the
The CapacityReservationStatus column adheres to the followingrequirements:
CapacityReservationStatus
Capacity Reservation Status
Indicates whether the charge represents either the consumption of acapacity reservation or when a capacity reservation isunused.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Value | Description |
|---|---|
| Used | Charges that utilized a specific amount ofa capacity reservation. |
| Unused | Charges that represent the unused portionof a capacity reservation. |
Charge Category represents the highest-level classification of acharge based on the nature of how it is billed. Charge Category iscommonly used to identify and distinguish between types of charges thatmay require different handling.
The ChargeCategory column MUST be present in a
ChargeCategory
Charge Category
Represents the highest-level classification of a charge based on thenature of how it is billed.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Usage | Positive or negative charges based on thequantity of a service or resource that was consumed over a given periodof time including refunds. |
| Purchase | Positive or negative charges for theacquisition of a service or resource bought upfront or on a recurringbasis including refunds. |
| Tax | Positive or negative applicable taxes thatare levied by the relevant authorities including refunds. Tax chargesmay vary depending on factors such as the location, jurisdiction, andlocal or federal regulations. |
| Credit | Positive or negative charges granted bythe provider for various scenarios e.g promotional credits orcorrections to promotional credits. |
| Adjustment | Positive or negative charges the providerapplies that do not fall into other category values. |
Charge Class indicates whether the row represents a correction to apreviously invoiced billingperiod. Charge Class is commonly used to differentiatecorrections from regularly incurred charges.
The ChargeClass column MUST be present in a
ChargeClass
Charge Class
Indicates whether the row represents a correction to a previouslyinvoiced billing period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Correction | Correction to a previously invoicedbilling period (e.g., refunds and credit modifications). |
A Charge Description provides a high-level context of a
The ChargeDescription column MUST be present in a
ChargeDescription
Charge Description
Self-contained summary of the charge’s purpose and price.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Charge Frequency indicates how often a charge will occur. Along withthe charge period related columns,the Charge Frequency is commonly used to understand recurrence periods(e.g., monthly, yearly), forecast upcoming charges, and differentiatebetween one-time and recurring fees for purchases.
The ChargeFrequency column is RECOMMENDED be present in a
ChargeFrequency
Charge Frequency
Indicates how often a charge will occur.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| One-Time | Charges that only happen once and will notrepeat. One-time charges are typically recorded on the hour or day whenthe cost was incurred. |
| Recurring | Charges that repeat on a periodic cadence(e.g., weekly, monthly) regardless of whether the product or service wasused. Recurring charges typically happen on the same day or point withinevery period. The charge date does not change based on how or when theservice is used. |
| Usage-Based | Charges that repeat every time the serviceis used. Usage-based charges are typically recorded hourly or daily,based on the granularity of the cost data for the period when theservice was used (referred to as charge period). Usage-based charges arenot recorded when the service is not used. |
Charge Period End represents the
ChargePeriodEnd MUST be present in a
ChargePeriodEnd
Charge Period End
The exclusive enddate and time of a charge period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/TimeFormat |
Charge Period Start represents the
ChargePeriodStart MUST be present in a
ChargePeriodStart
Charge Period Start
The inclusive startdate and time within a chargeperiod.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/TimeFormat |
Commitment Discount Category indicates whether the
The CommitmentDiscountCategory column MUST be present in a
CommitmentDiscountCategory
Commitment Discount Category
Indicates whether the commitment discount identified in theCommitmentDiscountId column is based on usage quantity or cost (aka”spend”).
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Value | Description |
|---|---|
| Spend | Commitment discounts that require apredetermined amount of spend. |
| Usage | Commitment discounts that require apredetermined amount of usage. |
A Commitment Discount ID is the identifier assigned to a
The CommitmentDiscountId column MUST be present in a
CommitmentDiscountId
Commitment Discount ID
The identifier assigned to a commitment discount by theprovider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Commitment Discount Name is the display name assigned to a
The CommitmentDiscountName column MUST be present in a
CommitmentDiscountName
Commitment Discount Name
The display name assigned to a commitment discount.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Commitment Discount Quantity is the amount of a
When
The CommitmentDiscountQuantity column adheres to the followingrequirements:
In cases where the ChargeCategory is “Purchase”, CommitmentDiscountIdis not null, and ChargeClass is not “Correction”, the followingapplies:
In cases where the ChargeCategory is “Usage”, CommitmentDiscountId isnot null, and ChargeClass is not “Correction”, the followingapplies:
CommitmentDiscountQuantity MUST be null in all other cases.
CommitmentDiscountQuantity
Commitment Discount Quantity
The amount of a commitment discount purchased or accountedfor in commitment discount related rows that isdenominated in Commitment Discount Units.
Aggregation: When aggregating Commitment DiscountQuantity for commitment utilization calculations, it’s important toexclude commitment discount purchases (i.e. when ChargeCategoryis “Purchase”) that are paid to cover future eligible charges (e.g.,commitment discount). Otherwise, when accounting for allupfront or accrued purchases, it’s important to exclude commitmentdiscount usage (i.e. when ChargeCategory is “Usage”). Thisexclusion helps prevent double counting of these quantities in theaggregation.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid decimal value |
Commitment Discount Status indicates whether the charge correspondswith the consumption of a
The CommitmentDiscountStatus column MUST be present in a
CommitmentDiscountStatus
Commitment Discount Status
Indicates whether the charge corresponds with the consumption of acommitment discount or the unused portion of the committedamount.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Value | Description |
|---|---|
| Used | Charges that utilized a specific amount ofa commitment discount. |
| Unused | Charges that represent the unused portionof the commitment discount. |
Commitment Discount Type is a provider-assigned name to identify thetype of commitmentdiscount applied to the
The CommitmentDiscountType column MUST be present in a
CommitmentDiscountType
Commitment Discount Type
A provider-assigned identifier for the type of commitmentdiscount applied to the row.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Commitment Discount Unit represents the provider-specifiedmeasurement unit indicating how a provider measures the
The CommitmentDiscountUnit column adheres to the followingrequirements:
In cases where the CommitmentDiscountUnit is not null, the followingapplies:
CommitmentDiscountUnit
Commitment Discount Unit
The provider-specified measurement unit indicating how a providermeasures the Commitment Discount Quantity of a commitmentdiscount.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Format |
The Consumed Quantity represents the volume of a metered SKUassociated with a resource orservice used, based on the
The ConsumedQuantity column adheres to the followingrequirements:
ConsumedQuantity
Consumed Quantity
The volume of a metered SKU associated with a resource orservice used, based on the Consumed Unit.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid decimal value |
The Consumed Unit represents a provider-specified measurement unitindicating how a provider measures usage of a metered SKU associatedwith a resource or
The ConsumedUnit column adheres to the following requirements:
ConsumedUnit
Consumed Unit
Provider-specified measurement unit indicating how a providermeasures usage of a metered SKU associated with a resource orservice.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Formatrecommended |
Contracted Cost represents the cost calculated by multiplying
The ContractedCost column MUST be present in a
In cases where the ContractedUnitPrice is present and null, thefollowing applies:
ContractedCost
Contracted Cost
Cost calculated by multiplying contracted unit price and thecorresponding Pricing Quantity.
Aggregation: When aggregating Contracted Cost forsavings calculations, it’s important to exclude either
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid decimal value |
The Contracted Unit Price represents the agreed-upon unit price for asingle Pricing Unit of the associated SKU,inclusive of negotiateddiscounts, if present, while excluding negotiated
The ContractedUnitPrice column MUST be present in a
ContractedUnitPrice
Contracted Unit Price
The agreed-upon unit price for a single Pricing Unit of theassociated SKU, inclusive of negotiated discounts, if present, whileexcluding negotiated commitment discounts or any other discounts.
Aggregation: Column values should only be viewed inthe context of their row and not aggregated to produce a total.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid non-negative decimal value |
Effective Cost represents the
This column resolves two challenges that are faced bypractitioners:
The EffectiveCost column MUST be present in a
In cases where the ChargeCategory isnot “Usage” or “Purchase”, the following applies:
EffectiveCost
Effective Cost
The amortized cost of the charge after applying allreduced rates, discounts, and the applicable portion of relevant,prepaid purchases (one-time or recurring) that covered this charge.
Providers should distribute the commitment purchase amountinstead of including a row at the beginning of a period sopractitioners do not need to manually distribute the fee themselves.
Eligible purchases should be amortized using a methodologydetermined by the provider that reflects the needs of their customerbase and is proportional to the Pricing Quantity and the timegranularity of the row. Should a practitioner desire toamortize relevant purchases using a different approach, thepractitioner can do so using the Billed Costfor the line item representing the initial purchase.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid decimal value |
An Invoice Issuer is an entity responsible for invoicing for the
The InvoiceIssuer column MUST be present in a
See Appendix: Origination of costdata section for examples of Provider,
InvoiceIssuerName
Invoice Issuer
The name of the entity responsible for invoicing for theresources or services consumed.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
List Cost represents the cost calculated by multiplying the
The ListCost column MUST be present in a
In cases where the ListUnitPrice is present and is null, thefollowing applies:
ListCost
List Cost
Cost calculated by multiplying List Unit Price and the correspondingPricing Quantity.
Aggregation: When aggregating List Cost for savingscalculations, it’s important to exclude either
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid decimal value |
The List Unit Price represents the suggested provider-published unitprice for a single Pricing Unit of theassociated SKU, exclusive of any discounts. This price is denominated inthe Billing Currency. The List Unit Priceis commonly used for calculating savings based on various rateoptimization activities.
The ListUnitPrice column MUST be present in a
ListUnitPrice
List Unit Price
The suggested provider-published unit price for a single Pricing Unitof the associated SKU, exclusive of any discounts.
Aggregation: Column values should only be viewed inthe context of their row and not aggregated to produce a total.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | NumericFormat |
| Number range | Any valid non-negative decimal value |
Pricing Category describes the pricing model used for a charge at thetime of use or purchase. It can be useful for distinguishing betweencharges incurred at the listunit price or a reduced price and exposing optimizationopportunities, like increasing
The PricingCategory column adheres to the following requirements:
PricingCategory
Pricing Category
Describes the pricing model used for a charge at the time of use orpurchase.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Standard | Charges priced at the agreed upon rate forthe billing account, including |
| Dynamic | Charges priced at a variable ratedetermined by the provider. This includes any product or service with aunit price the provider can change without notice, like interruptible orlow priority resources. |
| Committed | Charges with reduced pricing due to theapplication of the commitment discount specified by theCommitment Discount ID. |
| Other | Charges priced in a way not covered byanother pricing category. |
The Pricing Quantity represents the volume of a given SKU associatedwith a resource or
The PricingQuantity column MUST be present in a
PricingQuantity
Pricing Quantity
The volume of a given SKU associated with a resource orservice used or purchased, based on the Pricing Unit.
Aggregation: When aggregating Pricing Quantity forcommitment utilization calculations, it’s important to excludecommitment discount purchases (i.e. whenChargeCategory is “Purchase”) that are paid to cover futureeligible charges (e.g., Commitment Discount). Otherwise, whenaccounting for all upfront or accrued purchases, it’s important toexclude commitment discount usage (i.e. whenChargeCategory is “Usage”). This exclusion helps prevent doublecounting of these quantities in the aggregation.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | Decimal |
| Value format | NumericFormat |
| Number Range | Any valid decimal value |
The Pricing Unit represents a provider-specified measurement unit fordetermining unit prices, indicating how the provider rates measuredusage and purchase quantities after applying pricing rules like Hours), gigabyte-hours for a storage appliance (e.g.,GB-Hours), or an accumulated count of requests for anetwork appliance or API service (e.g., 1000 Requests).Pricing Unit complements the PricingQuantity metric. Distinct from the ConsumedUnit, it focuses on pricing and cost, not
The PricingUnit column MUST be present in a
The PricingUnit value MUST be semantically equal to the correspondingpricing measurement unit value provided in:
PricingUnit
Pricing Unit
Provider-specified measurement unit for determining unit prices,indicating how the provider rates measured usage and purchase quantitiesafter applying pricing rules like block pricing.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Format |
A Provider is an entity that makes the
The Provider column MUST be present in a
See Appendix: Origination of costdata section for examples of Provider, Publisher and Invoice Issuervalues that can be used for various purchasing scenarios.
ProviderName
Provider
The name of the entity that made the resources orservices available for purchase.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
A Publisher is an entity that produces the
The Publisher column MUST be present in a
See Appendix: Origination of costdata section for examples of Provider,Publisher and Invoice Issuer values thatcan be used for various purchasing scenarios.
PublisherName
Publisher
The name of the entity that produced the resources orservices that were purchased.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
A Region ID is a provider-assigned identifier for an isolatedgeographic area where a
The RegionId column MUST be present in a
RegionId
Region ID
Provider-assigned identifier for an isolated geographic area where aresource is provisioned or a service is provided.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Region Name is a provider-assigned display name for an isolatedgeographic area where a
The RegionName column MUST be present in a
RegionName
Region Name
The name of an isolated geographic area where a resource isprovisioned or a service is provided.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Resource ID is an identifier assigned to a
The ResourceId column MUST be present in a
ResourceId
Resource ID
Identifier assigned to a resource by the provider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The Resource Name is a display name assigned to a
The ResourceName column MUST be present in a
ResourceName
Resource Name
Display name assigned to a resource.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Resource Type describes the kind of
The ResourceType column MUST be present in a
ResourceType
Resource Type
The kind of resource the charge applies to.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The Service Category is the highest-level classification of a
The ServiceCategory column MUST be present in a
ServiceCategory
Service Category
Highest-level classification of a service based on the corefunction of the service.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Service Category | Description |
|---|---|
| AI and Machine Learning | Artificial Intelligence and MachineLearning related technologies. |
| Analytics | Data processing, analytics, andvisualization capabilities. |
| Business Applications | Business and productivity applications andservices. |
| Compute | Virtual, containerized, serverless, orhigh-performance computing infrastructure and services. |
| Databases | Database platforms and services that allowfor storage and querying of data. |
| Developer Tools | Software development and delivery toolsand services. |
| Multicloud | Support for interworking of multiple cloudand/or on-premises environments. |
| Identity | Identity and access managementservices. |
| Integration | Services that allow applications tointeract with one another. |
| Internet of Things | Development and management of IoT devicesand networks. |
| Management and Governance | Management, logging, and observability ofa customer’s use of cloud. |
| Media | Media and entertainment streaming andprocessing services. |
| Migration | Moving applications and data to thecloud. |
| Mobile | Services enabling cloud applications tointeract via mobile technologies. |
| Networking | Network connectivity and management. |
| Security | Security monitoring and complianceservices. |
| Storage | Storage services for structured orunstructured data. |
| Web | Services enabling cloud applications tointeract via the Internet. |
| Other | New or emerging services that do not alignwith an existing category. |
A service represents anoffering that can be purchased from a provider (e.g., cloud virtualmachine, SaaS database, professional services from a systemsintegrator). A service offering can include various types ofusage or other charges. For example, a cloud database servicemay include compute, storage, and networking charges.
The Service Name is a display name for the offering that waspurchased. The Service Name is commonly used for scenarios likeanalyzing aggregate cost trends over time and filtering data toinvestigate anomalies.
The ServiceName column MUST be present in a
ServiceName
Service Name
An offering that can be purchased from a provider (e.g., cloudvirtual machine, SaaS database, professional services from asystems integrator).
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The Service Subcategory is a secondary classification of the
The ServiceSubcategory column adheres to the followingrequirements:
ServiceSubcategory
Service Subcategory
Secondary classification of the Service Category for aservice based on its core function.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Service Category | Service Subcategory | Service Subcategory Description |
|---|---|---|
| AI and Machine Learning | AI Platforms | Unified solution that combines artificial intelligence and machinelearning technologies. |
| AI and Machine Learning | Bots | Automated performance of tasks such as customer service, datacollection, and content moderation. |
| AI and Machine Learning | Generative AI | Creation of content like text, images, and music by learningpatterns from existing data. |
| AI and Machine Learning | Machine Learning | Creation, training, and deployment of statistical algorithms thatlearn from and perform tasks based on data. |
| AI and Machine Learning | Natural Language Processing | Generation of human language, handling tasks like translation,sentiment analysis, and text summarization. |
| AI and Machine Learning | Other (AI and Machine Learning) | AI and Machine Learning services that do not fall into one of thedefined subcategories. |
| Analytics | Analytics Platforms | Unified solution that combines technologies across the entireanalytics lifecycle. |
| Analytics | Business Intelligence | Semantic models, dashboards, reports, and data visualizations totrack performance and identify trends. |
| Analytics | Data Processing | Integration and transformation tasks to prepare data foranalysis. |
| Analytics | Search | Discovery of information by indexing and retrieving data fromvarious sources. |
| Analytics | Streaming Analytics | Real-time data stream processes to detect patterns, trends, andanomalies as they occur. |
| Analytics | Other (Analytics) | Analytics services that do not fall into one of the definedsubcategories. |
| Business Applications | Productivity and Collaboration | Tools that facilitate individuals managing tasks and workingtogether. |
| Business Applications | Other (Business Applications) | Business Applications services that do not fall into one of thedefined subcategories. |
| Compute | Containers | Management and orchestration of containerized computeplatforms. |
| Compute | End User Computing | Virtualized desktop infrastructure and device / endpointmanagement. |
| Compute | Quantum Compute | Resources and simulators that leverage the principles of quantummechanics. |
| Compute | Serverless Compute | Enablement of compute capabilities without provisioning or managingservers. |
| Compute | Virtual Machines | Computing environments ranging from hosts with abstracted operatingsystems to bare-metal servers. |
| Compute | Other (Compute) | Compute services that do not fall into one of the definedsubcategories. |
| Databases | Caching | Low-latency and high-throughput access to frequently accesseddata. |
| Databases | Data Warehouses | Big data storage and querying capabilities. |
| Databases | Ledger Databases | Immutable and transparent databases to record tamper-proof andcryptographically secure transactions. |
| Databases | NoSQL Databases | Unstructured or semi-structured data storage and queryingcapabilities. |
| Databases | Relational Databases | Structured data storage and querying capabilities. |
| Databases | Time Series Databases | Time-stamped data storage and querying capabilities. |
| Databases | Other (Databases) | Database services that do not fall into one of the definedsubcategories. |
| Developer Tools | Developer Platforms | Unified solution that combines technologies across multiple areas ofthe software development lifecycle. |
| Developer Tools | Continuous Integration and Deployment | CI/CD tools and services that support building and deploying codefor software and systems. |
| Developer Tools | Development Environments | Tools and services that support authoring code for software andsystems. |
| Developer Tools | Source Code Management | Tools and services that support version control of code for softwareand systems. |
| Developer Tools | Quality Assurance | Tools and services that support testing code for software andsystems. |
| Developer Tools | Other (Developer Tools) | Developer Tools services that do not fall into one of the definedsubcategories. |
| Identity | Identity and Access Management | Technologies that ensure users have appropriate access toresources. |
| Identity | Other (Identity) | Identity services that do not fall into one of the definedsubcategories. |
| Integration | API Management | Creation, publishing, and management of application programminginterfaces. |
| Integration | Messaging | Asynchronous communication between distributed applications. |
| Integration | Workflow Orchestration | Design, execution, and management of business processes andworkflows. |
| Integration | Other (Integration) | Integration services that do not fall into one of the definedsubcategories. |
| Internet of Things | IoT Analytics | Examination of data collected from IoT devices. |
| Internet of Things | IoT Platforms | Unified solution that combines IoT data collection, processing,visualization, and device management. |
| Internet of Things | Other (Internet of Things) | Internet of Things (IoT) services that do not fall into one of thedefined subcategories. |
| Management and Governance | Architecture | Planning, design, and construction of software systems. |
| Management and Governance | Compliance | Adherance to regulatory standards and industry best practices. |
| Management and Governance | Cost Management | Monitoring and controlling expenses of systems and services. |
| Management and Governance | Data Governance | Management of the availability, usability, integrity, and securityof data. |
| Management and Governance | Disaster Recovery | Plans and procedures that ensure systems and services can recoverfrom disruptions. |
| Management and Governance | Endpoint Management | Tools that configure and secure access to devices. |
| Management and Governance | Observability | Monitoring, logging, and tracing of data to track the performanceand health of systems. |
| Management and Governance | Support | Assistance and expertise supplied by providers. |
| Management and Governance | Other (Management and Governance) | Management and governance services that do not fall into one of thedefined subcategories. |
| Media | Content Creation | Production of media content. |
| Media | Gaming | Development and delivery of gaming services. |
| Media | Media Streaming | Multimedia delivered and rendered in real-time on devices. |
| Media | Mixed Reality | Technologies that blend real-world and computer-generatedenvironments. |
| Media | Other (Media) | Media services that do not fall into one of the definedsubcategories. |
| Migration | Data Migration | Movement of stored data from one location to another. |
| Migration | Resource Migration | Movement of resources from one location to another. |
| Migration | Other (Migration) | Migration services that do not fall into one of the definedsubcategories. |
| Mobile | Other (Mobile) | All Mobile services. |
| Multicloud | Multicloud Integration | Environments that facilitate consumption of services from multiplecloud providers. |
| Multicloud | Other (Multicloud) | Multicloud services that do not fall into one of the definedsubcategories. |
| Networking | Application Networking | Distribution of incoming network traffic across application-basedworkloads. |
| Networking | Content Delivery | Distribution of digital content using a network of servers(CDNs). |
| Networking | Network Connectivity | Facilitates communication between networks or network segments. |
| Networking | Network Infrastructure | Configuration, monitoring, and troubleshooting of networkdevices. |
| Networking | Network Routing | Services that select paths for traffic within or acrossnetworks. |
| Networking | Network Security | Protection from unauthorized network access and cyber threats usingfirewalls and anti-malware tools. |
| Networking | Other (Networking) | Networking services that do not fall into one of the definedsubcategories. |
| Security | Secret Management | Information used to authenticate users and systems, includingsecrets, certificates, tokens, and other keys. |
| Security | Security Posture Management | Tools that help organizations configure, monitor, and improve systemsecurity. |
| Security | Threat Detection and Response | Collect and analyze security data to identify and respond topotential security threats and vulnerabilities. |
| Security | Other (Security) | Security services that do not fall into one of the definedsubcategories. |
| Storage | Backup Storage | Secondary storage to protect against data loss. |
| Storage | Block Storage | High performance, low latency storage that provides randomaccess. |
| Storage | File Storage | Scalable, sharable storage for file-based data. |
| Storage | Object Storage | Highly available, durable storage for unstructured data. |
| Storage | Storage Platforms | Unified solution that supports multiple storage types. |
| Storage | Other (Storage) | Storage services that do not fall into one of the definedsubcategories. |
| Web | Application Platforms | Integrated environments that run web applications. |
| Web | Other (Web) | Web services that do not fall into one of the definedsubcategories. |
| Other | Other (Other) | Services that do not fall into one of the defined categories. |
A SKU ID is a unique identifier that defines a provider-supportedconstruct for organizing properties that are common across one or moreSKU Prices. SKU ID can bereferenced on a catalog or pricelist published by a provider to look up detailed informationabout the SKU. The composition of the properties associated with the SKUID may differ across providers. Some providers may not support the
The SkuId column MUST be present in a
SkuId
SKU ID
A unique identifier that defines a provider-supported construct fororganizing properties that are common across one or more SKUPrices.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The SKU Meter describes the functionality being metered or measuredby a particular SKU in a charge.
Providers often have billing models in which multiple SKUs exist fora given service to describe and bill for different functionalities forthat service. For example, an object storage service may have separateSKUs for functionalities such as object storage, API requests, datatransfer, encryption, and object management. This field helpspractitioners understand which functionalities are being metered by thedifferent SKUs that appear in a
The SkuMeter column adheres to the following requirements:
Compute Usage, Block Volume Usage, Data Transfer, API Requests
SkuMeter
SKU Meter
Describes the functionality being metered or measured by a particularSKU in a charge.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The SKU Price Details column represents a list of relevant propertiesshared by all charges with the same SKU PriceID. These properties provide qualitative and quantitative detailsabout the service represented by a SKU Price ID. This can enablepractitioners to calculate metrics such as total units of a service whenit is not directly billed in those units (e.g. cores) and thus enablesFinOps capabilities such as unit economics. These properties can alsohelp a practitioner understand the specifics of a SKU Price ID anddifferentiate it other SKU Price IDs.
The SkuPriceDetails column adheres to the following requirements:
SkuPriceDetails
SKU Price Details
A set of properties of a SKU Price ID which are meaningful and commonto all instances of that SKU Price ID.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | JSON |
| Value format | Key-ValueFormat |
A SKU Price ID is a unique identifier that defines the unit priceused to calculate the charge. SKU Price ID can be referenced on a
The SkuPriceId column adheres to the following requirements:
SkuPriceId
SKU Price ID
A unique identifier that defines the unit price used to calculate thecharge.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Sub Account ID is a provider-assigned identifier assigned to a
The SubAccountId column MUST be present in a
See Appendix:Grouping constructs for resources or services for details andexamples of the different grouping constructs supported by FOCUS.
SubAccountId
Sub Account ID
An ID assigned to a grouping of
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Sub Account Name is a display name assigned to a
The SubAccountName column MUST be present in a
See Appendix:Grouping constructs for resources or services for details andexamples of the different grouping constructs supported by FOCUS.
SubAccountName
Sub Account Name
A name assigned to a grouping of
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The Tags column represents the set of tags assigned to
A tag becomes
The Tags column adheres to the following requirements:
Provider-defined Tags additionally adhere to the followingrequirements:
This example illustrates three different tagging scenarios. The firsttwo illustrate when the provider supports both keys and values, whilethe third is for supporting keys only. The first tag is user-defined anddoesn’t have a provider prefix. The second tag is provider-defined andhas a prefix of acme/, which is reserved by the provider.The third tag has a tag key of baz and its value isassigned the boolean value true since the tag doesn’tsupport a value.
Within a provider, tag keys may be associated with multiple values,and potentially defined at different levels within the provider, such asaccounts, folders, resourceand other resource grouping constructs. When finalizing,providers must reduce these multiple levels of definition to asingle value where each key is associated with exactly one value. Themethod by which this is done and the semantics are up to each providerbut must be documented within their respective documentation.
As an example, let’s assume 1 subaccount exists with 1 virtual machine with the followingdetails, and tag inheritance favors Resources over SubAccounts.
The table below represents a finalized dataset with theseresources. It also shows the finalized state after allresource-oriented, tag inheritance rules are processed.
| ResourceType | ResourceId | Tags |
|---|---|---|
| Sub Account | my-sub-account | { “team”: “ops”, “env”: “prod” } |
| Virtual Machine | my-vm | { “team”: “web”, “env”: “prod”} |
Because the the Virtual Machine Resource did not have anenv tag, it inherited tag, env:prod(italicized), from its parent sub account. Conversely, becausethe Virtual Machine Resource already has a team tag(team:web), it did not inherit team:ops fromits parent sub account.
Tags
Tags
The set of tags assigned to tag sources that account forpotential provider-defined or user-defined tag evaluations.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | JSON |
| Value format | Key-ValueFormat |
1.0-preview
Attributes are requirements that apply across a
Column IDs provided in cost data following a consistent naming andordering convention reduce friction for FinOps practitioners who consumethe data for analysis, reporting, and other use cases.
All columns defined in the FOCUS specification MUST follow the namingand ordering requirements listed below.
ColumnNamingAndOrdering
Column Naming and Ordering
Naming and ordering convention for columns appearing in a
Id orName suffix in the Column ID. Display Name for a Column MAYavoid the Name suffix if there are no other columns with the same nameprefix.x_ prefix to identify them as external, custom columns anddistinguish them from FOCUS columns to avoid conflicts in futurereleases.Id orName suffix in the Column ID. Display Name for a Column MAYavoid the Name suffix if it is considered superfluous.Category suffix MUST benormalized.Columns that contain currency information in cost data following aconsistent format reduce friction for FinOps practitioners who consumethe data for analysis, reporting, and other use cases.
All columns capturing a currency value, defined in the FOCUSspecification, MUST follow the requirements listed below. Customcurrency-related columns SHOULD also follow the same formattingrequirements.
CurrencyCodeFormat
Currency Code Format
Formatting for currency columns appearing in a
Currency-related columns MUST be represented as a three-letteralphabetic code as dictated in the governing document
None
Columns that provide date and time information conforming tospecified rules and formatting requirements ensure clarity, accuracy,and ease of interpretation for both humans and systems.
All columns capturing a date/time value, defined in the FOCUSspecification, MUST follow the formatting requirements listed below.Custom date/time-related columns SHOULD also follow the same formattingrequirements.
DateTimeFormat
Date/Time Format
Rules and formatting requirements for date/time-related columnsappearing in a FOCUSdataset.
None
A discount is a pricing construct where providers offer a reducedprice for services. Providersmay have many types of discounts, including but not limited tocommercially negotiateddiscounts,
Some discount offers can be purchased from a provider to get reducedprices. The most common example is a commitment discount, whereyou “purchase” a commitment to use or spend a specific amount within aperiod. When a commitment isn’t fully utilized, the unused amountreduces the potential savings from the discount and can even result inpaying higher costs than without the discount. Due to this risk, unusedcommitment amounts need to be clearly identifiable at a granular level.To facilitate this, unused commitments are recorded with a separate rowfor each charge period where the commitment was not fully utilized. Toshow the impact of purchased discounts on each discounted row, discountpurchases need the purchase amount to be amortized over the
Amortization is a process used to break down and spread purchasecosts over a period of time or term of use. When a purchase isapplicable to resources, like commitment discounts, theamortized cost of a resource takes the initial payment and terminto account and distributes it out based on the resource’s usage,attributing the prorated cost for each unit of billing. Amortizationenables users of billing data to distribute purchase charges to theappropriate audience in support of cost allocation efforts. DiscountHandling for purchased commitments is commonly used for scenarios likecalculating utilization and implementing chargeback for the purchaseamount.
While providers may use different terms to describe discounts, FOCUSidentifies a discount as being a reduced price applied directly to arow. Any price or cost reductions that are awarded after the fact areidentified as a “Credit” Charge Category. One example might be when aprovider offers a reduced rate after passing a certain threshold ofusage or spend.
All rows defined in FOCUS MUST follow the discount handlingrequirements listed below.
DiscountHandling
Discount Handling
Indicates how to include and apply discounts to usage charges or rowsin a FOCUS dataset.
None
Columns that provide Key-Value information are often used in place ofseparate columns for enumerating data which would be inherently sparseand/or without predetermined keys. This consolidates related informationand provides more consistency in the schema. Key-value pairs are alsoreferred to as name-value pairs, attribute-value pairs, or field-valuepairs.
All key-value related columns defined in the FOCUS specification MUSTfollow the key-value formatting requirements listed below.
KeyValueFormat
Key-Value Format
Rules and formatting requirements for columns appearing in a
true, false, ornull.None
Cost data rows that don’t have avalue that can be presented for a column must be handled in a consistentway to reduce friction for FinOps practitioners who consume the data foranalysis, reporting, and other use cases.
All columns defined in the FOCUS specification MUST follow the nullhandling requirements listed below. Custom columns SHOULD also followthe same formatting requirements.
NullHandling
Null Handling
Indicates how to handle columns that don’t have a value.
None
Columns that provide numeric values conforming to specified rules andformatting requirements ensure clarity, accuracy, and ease ofinterpretation for humans and systems. The FOCUS specification does notrequire a specific level of precision for numeric values. The level ofprecision required for a given column is determined by the provider andshould be part of a data definition published by the provider.
All columns capturing a numeric value, defined in the FOCUSspecification, MUST follow the formatting requirements listed below.Custom numeric value capturing columns SHOULD adopt the same formatrequirements over time.
NumericFormat
Numeric Format
Rules and formatting requirements for numeric columns appearing in aFOCUS dataset.
Allowed values:
| Data Type | Type Description |
|---|---|
| Integer | Specifies a numeric value represented by awhole number or by zero. Integer number formats correspond to standarddata types defined by ISO/IEC 9899:2018 |
| Decimal | Specifies a numeric value represented by adecimal number. Decimal formats correspond to ISO/IEC/IEEE 60559:2011and IEEE 754-2008 definitions. |
Allowed values:
| Data Type | Precision | Definition | Range / Significant Digits |
|---|---|---|---|
| Integer | Short | 16-bit signed short int ISO/IEC9899:2018 | -32,767 to +32,767 |
| Integer | Long | 32-bit signed long int ISO/IEC9899:2018 | -2,147,483,647 to +2,147,483,647 |
| Integer | Extended | 64-bit signed two’s complement integeror higher | -(2^63 – 1) to (2^63 – 1) |
| Decimal | Single | 32-bit binary format IEEE 754-2008floating-point (decimal32) | 9 |
| Decimal | Double | 64-bit binary format IEEE 754-2008floating-point (decimal64) | 16 |
| Decimal | Extended | 128-bit binary format IEEE 754-2008floating-point (decimal128) or higher | 36+ |
This format requires that single numeric values be represented usingan integer or decimal format without additional characters orqualifiers. The following lists provide examples of values that meet therequirements and those that do not.
Values Meeting Numeric Requirements:
Values NOT Meeting Numeric Requirements
None
Columns that capture string values conforming to specifiedrequirements foster data integrity, interoperability, and consistency,improve data analysis and reporting, and support reliable data-drivendecision-making.
All columns capturing a string value, defined in the FOCUSspecification, MUST follow the requirements listed below. Custom stringvalue capturing columns SHOULD adopt the same requirements overtime.
StringHandling
String Handling
Requirements for string-capturing columns appearing in a
Billing data frequently captures data measured in units related todata size, count, time, and other
All columns defined in FOCUS specifying Unit Format as a value formatMUST follow the requirements listed below.
UnitFormat
Unit Format
Indicates standards for expressing measurement units in columnsappearing in a FOCUS dataset.
<plural-units> – “GB”, “Seconds”<singular-unit>-<plural-time-units> -“GB-Hours”, “MB-Days”<plural-units>/<singular-time-unit> -“GB/Hour”, “PB/Day”<quantity> <plural-units> – “1000 Tokens”,”1000 Characters”<plural-units>/<interval> <plural-time-units>– “Units/3 Months”Data size unit names MUST be abbreviated using one of theabbreviations in the following table. For example, a unit name of “TB”is a valid unit name, and a unit name of “terabyte” is an invalid unitname. Data size abbreviations can be considered both the singular andplural form of the unit. For example, “GB” is both the singular andplural form of the unit “gigabyte”, and “GBs” would be an invalid unitname. Values that exceed 10^18 MUST use the abbreviation for exabit,exabyte, exbibit, and exbibyte, and values smaller than a byte MUST usethe abbreviation for bit or byte. For example, the abbreviation “YB” for”yottabyte” is not a valid data size unit name as it represents a valuelarger than what is listed in the following table.
The following table lists the valid abbreviations for data size unitsfrom a single bit or byte to 10^18 bits or bytes.
| Data size in bits | Data size in bytes |
|---|---|
| b (bit) = 10^1 | B (byte = 10^1) |
| Kb (kilobit = 10^3) | KB (kilobyte = 10^3) |
| Mb (megabit = 10^6) | MB (megabyte = 10^6) |
| Gb (gigabit = 10^9) | GB (gigabyte = 10^9) |
| Tb (terabit = 10^12) | TB (terabyte = 10^12) |
| Pb (petabit = 10^15) | PB (petabyte = 10^15) |
| Eb (exabit = 10^18) | EB (exabyte = 10^18) |
| Kib (kibibit = 2^10) | KiB (kibibyte = 2^10) |
| Mib (mebibit = 2^20) | MiB (mebibyte = 2^20) |
| Gib (gibibit = 2^30) | GiB (gibibyte = 2^30) |
| Tib (tebibit = 2^40) | TiB (tebibyte = 2^40) |
| Pib (pebibit = 2^50) | PiB (pebibyte = 2^50) |
| Eib (exbibit = 2^60) | EiB (exbibyte = 2^60) |
A count-based unit is a noun that represents a discrete number ofitems, events, or actions. For example, a count-based unit can be usedto represent the number of requests, instances, tokens, orconnections.
If the following list of recommended values does not cover acount-based unit, a provider MAY introduce a new noun representing acount-based unit. All nouns appearing in units that are not listed inthe recommended values table will be considered count-based units. A newcount-based unit value MUST be capitalized.
| Count |
|---|
| Count |
| Unit |
| Request |
| Token |
| Connection |
| Certificate |
| Domain |
| Core |
A time-based unit is a noun that represents a time interval.Time-based units can be used to measure consumption over a time intervalor in combination with another unit to capture a rate of consumption.Time-based units MUST match one of the values listed in the followingtable.
| Time |
|---|
| Year |
| Month |
| Day |
| Hour |
| Minute |
| Second |
If the unit value is a composite value made from combinations of oneor more units, each component MUST also align with the set ofrecommended values.
Instead of “per” or “-” to denote a Composite Unit, slash (“/”) andspace(” “) MUST be used as a common convention. Count-based units likerequests, instances, and tokens SHOULD be expressed using a value listedin the count dimension. For example, if a usage unit ismeasured as a rate of requests or instances over a period of time, theunit SHOULD be listed as “Requests/Day” to signify the number ofrequests per day.
None
1.0-preview
The FOCUS specification defines a metadata structure to be suppliedby data providers to facilitate practitioners’ use of FOCUS data. Thismetadata includes general information about the data generator and theschema of the FOCUSdataset.
FOCUS Metadata SHOULD be provided in a format that is accessibleprogrammatically, such as a file, website, API, or table. ProvidersSHOULD provide documentation on their implementation of the FOCUSmetadata.
The FOCUS metadata about the generator of the FOCUS data.
The FOCUS Data Generator metadata MUST be provided. This metadataMUST be of type Object and MUST NOT contain null values.
For an example of the FOCUS Data Generator metadata please refer to:Data Generator Example
Human-readable name of the entity that is generating the data.
The DataGenerator MUST be provided in the metadata. DataGeneratorMUST be of type String and MUST NOT be null. The DataGenerator SHOULD beeasily associated with the provider who generated the
DataGenerator
Data Generator
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The schema metadata object and its contents provides informationabout the structure of the data provided.
FOCUS data artifacts, whether they are data files, data streams, ordata tables, MUST provide a clear reference to the schema of the data.This reference MUST be retrievable without inspection of the contents ofthe FOCUS data within the data artifact. For some delivery mechanismssuch as database tables, the provider may rely on the schemafunctionality of the providing system.
It is recommended that the schema reference be provided as anexternal reference rather than included in full as metadata accompanyingthe data artifact. This allows for easier understanding of when changesto the schema of the FOCUSdatasets occurs.
Should the provider change the structure of the supplied FOCUS dataartifact, a new schema metadata object MUST be supplied. These scenariosinclude, but are not limited to:
Should there be an error where the schema metadata object does notmatch the schema of the FOCUS data artifact, the provider MUST updatethe schema metadata object to match the schema of the FOCUS dataartifact. This is to ensure that the schema metadata object is alwaysaccurate.
For an example of the FOCUS schema metadata please refer to:
The Schema ID provides the reference item to associate which Schemawas used for the generation of a FOCUS Dataset.
The SchemaId MUST be present in the metadata. The SchemaId MUST be ofString. It is RECOMMENDED for SchemaId to be a Globally UniqueIdentifier (GUID).
SchemaId
Schema ID
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | STRING |
| Value format | Recommend GUID String |
Date the schema was created.
The CreationDate MUST be present in the metadata. This MUST be oftype Date/Time and MUST NOT contain null values. CreationDate MUSTconform to DateTimeFormat.
CreationDate
Creation Date
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/TimeFormat |
The version of FOCUS utilized for building the dataset.
The FocusVersion MUST be provided in the metadata. FocusVersion MUSTbe of type String and MUST NOT contain null values. FocusVersion MUSTmatch one of the published versions of the FOCUS specification.FocusVersion MUST match the version of the FOCUS specification that theFOCUS dataset conformsto.
FocusVersion
FOCUS Version
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | STRING |
| Value format | Must align with a publishedFocusVersion |
The ProviderVersion MAY be supplied to declare the version of logicby which the FOCUSdataset was generated and is separate from FOCUS Version.ProviderVersion allows for the provider to specify changes that may notresult in a structural change in the data. It is suggested that theprovider version use a versioning approach such as
ProviderVersion MUST be of type String and MUST NOT contain nullvalues. If FocusVersion is changed a new ProviderVersion MUST be alsochanged. The provider MUST document what changes are present in theProviderVersion.
ProviderVersion
Provider Version
| Constraint | Value |
|---|---|
| Feature level | Optional |
| Allows nulls | False |
| Data type | STRING |
| Value format | <not specified> |
The FOCUS metadata schema column definition provides a list of thecolumns present in the FOCUSdataset along with metadata about the columns.
This metadata MUST be present in the FOCUS metadata schema. Thismetadata MUST be of type Object and MUST NOT contain null values.
The name of the column provided in the
The ColumnName MUST be provided in the FOCUS Metadata schema.ColumnName MUST be of type String and MUST NOT contain null values.
ColumnName
Column Name
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The data type of the column provided in the
The DataType MUST be provided in the FOCUS Metadata schema. DataTypeMUST be of type String and MUST NOT contain null values.
DataType
Data Type
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
Numeric Precision is the maximum number of digits for the values inthe column.
NumericPrecision SHOULD be provided in the FOCUS Metadata schema forNumeric Format columns. NumericPrecision MUST be of type Integer andMUST NOT contain null values.
NumericPrecision
Numeric Precision
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Integer |
| Value format | NumericFormat |
The number scale of the data provides the maximum number of digitsafter the decimal point in decimal numbers.
NumberScale SHOULD be provided in the FOCUS Metadata schema forDecimal columns. NumberScale MUST be of type Integer and MUST NOTcontain null values.
NumberScale
Number Scale
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Integer |
| Value format | NumericFormat |
The Provider Tag Prefixes defines the list of prefixes used in thetag name of provider-defined tags. This metadata isuseful for the consumer to identify which tags are provider-defined vsuser-defined.
The ProviderTagPrefixes MUST be provided when ColumnName is equal toTags. The ProviderTagPrefix MUST be of type Array of Strings. TheProviderTagPrefixes SHOULD be easily associated with the provider whogenerated the FOCUSdataset.
ProviderTagPrefixes
Provider Tag Prefixes
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Array |
| Value format | STRING datatype values in the array |
The string encoding scheme of the column provided in the
StringEncoding SHOULD be provided in the FOCUS Metadata schema whenit is required to know this information in order to successfully readthe data. StringEncoding MUST be of type String and MUST NOT containnull values.
StringEncoding
StringEncoding
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The string max length of the data that can be stored in thecolumn.
StringMaxLength SHOULD be provided in the FOCUS Metadata schema forString columns. StringMaxLength MUST be of type Integer and MUST NOTcontain null values.
StringMaxLength
String Max Length
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Integer |
| Value format | NumericFormat |
1.0
This specification is based on a set of common FinOps use cases,which are publicly available at [
A charge representing a modification to billing data to account forcertain events or circumstances not previously captured, or capturedincorrectly. Examples include billing errors, service disruptions, orpricing changes.
The distribution of upfront costs over time to accurately reflect theconsumption or benefit derived from the associated resources orservices. Amortization is valuable when the commitment period (timeduration of the cost) extends beyond the granularity of the sourcereport.
A collection of geographically separated locations containing a datacenter or cluster of data centers. Each availability zone (AZ) shouldhave its own power, cooling, and networking, to provide redundancy andfault tolerance.
A charge that serves as the basis for invoicing. It includes thetotal amount of fees and discounts, signifying a monetary obligation.Valuable when reconciling cash outlay with incurred expenses isrequired, such as cost allocation, budgeting, and invoicereconciliation.
A container for resources and/or services that are billed together inan invoice. A billing account may have sub accounts, all of whose costsare consolidated and invoiced to the billing account.
An identifier that represents the currency that a charge forresources and/or services was billed in.
The time window that an organization receives an invoice for,inclusive of the start date and exclusive of the end date. It isindependent of the time of usage and consumption of resources andservices.
A pricing approach where the cost of a particular resource or serviceis determined based on predefined quantities or tiers of usage. In thesescenarios, the Pricing Unit and the corresponding Pricing Quantity canbe different from the Consumed Unit and Consumed Quantity.
A capacity reservation is an agreement that secures a dedicatedamount of resources or services for a specified period. This ensures thereserved capacity is always available and accessible, even if it’s notfully utilized. Customers are typically charged for the reservedcapacity, regardless of actual consumption.
A row in a FOCUS-compatible cost and usage dataset.
The time window for which a charge is effective, inclusive of thestart date and exclusive of the end date. The charge period forcontinuous usage should match the time granularity of the dataset (e.g.,1 hour for hourly, 1 day for daily). The charge period for a non-usagecharge with time boundaries should match the duration ofeligibility.
A company or organization that provides remote access to computingresources, infrastructure, or applications for a fee.
A customer’s agreement to consume a specific quantity of a service orresource over a defined period, usually also creating a financialcommitment throughout the entirety of the commitment period. Somecommitments also hold Providers to certain assurance levels of resourceavailability.
A billing discount model that offers reduced rates on preselectedSKUs in exchange for an obligated usage or spend amount over apredefined term. Commitment discount purchases, made upfront and/or withrecurring monthly payments are amortized evenly across predefined chargeperiods (i.e. hourly), and unused amounts cannot be carried over tosubsequent charge periods. Commitment discounts are publicly availableto customers without special contract arrangements.
CommitmentDiscount Flexibility
A feature of commitmentdiscounts that may further transform the predetermined amountof usage purchased or consumed based on additional, provider-specificrequirements.
The agreed-upon unit price for a single
A specification-defined categorical attribute that provides contextor categorization to billing data.
The amortized cost of the charge after applying all reduced rates,discounts, and the applicable portion of relevant, prepaid purchases(one-time or recurring) that covered this charge.
A Date/Time Format value that is not contained within the endingbound of a time period.
A tag with one tag value chosen from a set of possible tag valuesafter being processed by a set of provider-defined or user-definedrules.
FinOps Costand Usage Specification (FOCUS)
An open-source specification that defines requirements for billingdata.
A structured collection of cost and usage data that meets or exceedsthe Basic compliance criteria of FOCUS.
A Date/Time Format value that is contained within the beginning boundof a time period.
A category of compute resources that can be paused or terminated bythe CSP within certain criteria, often advertised at reduced unitpricing when compared to the equivalent non-interruptible resource.
The suggested provider-published unit price for a single
A company or organization that provides outsourced management andsupport of a range of IT services, such as network infrastructure,cybersecurity, cloud computing, and more.
A FOCUS-defined column that provides numeric values, allowing foraggregation operations such as arithmetic operations (sum,multiplication, averaging etc.) and statistical operations.
A contractual agreement where a customer commits to specific spend orusage goals over a term inexchange for discounted rates across varying SKUs. Unlike
A term that describes a service that is available and providedimmediately or as needed, without requiring a pre-scheduled appointmentor prior arrangement. In cloud computing, virtual machines can becreated and terminated as needed, i.e. on demand.
Pascal Case (PascalCase, also known as UpperCamelCase) is a formatfor identifiers which contain one or more words meaning the words areconcatenated together with no delimiter and the first letter of eachword is capitalized.
A long and often painful conversation had by the FOCUS contributors.Sometimes the name of a thing that we could not yet name. No starchyroot vegetables were harmed during the production of this specification.We thank potato for its contribution in the creation of thisspecification.
An individual who performs FinOps within an organization to maximizethe business value of using cloud and cloud-like services.
A comprehensive list of prices offered by a provider.
An entity that made internal or 3rd party resources and/or servicesavailable for purchase.
A unique component that incurs a charge.
A row in a FOCUS-compatible cost and usage dataset.
An offering that can be purchased from a provider, and can includemany types of usage or other charges; eg., a cloud database service mayinclude compute, storage, and networking charges.
A construct composed of the common properties of a product offeringassociated with one or many SKU Prices.
The unit price used to calculate a charge that is associated with oneSKU. SKU Prices are usually referenced from the provider’s price listand are unique to various providers.
A sub account is an optional provider-supported construct fororganizing resources and/or services connected to a billing account. Subaccounts must be associated with a billing account as they do notreceive invoices.
A metadata label assigned to a resource to provide information aboutit or to categorize it for organizational and management purposes.
A Resource or Provider-defined construct for grouping resourcesand/or other Provider-defined construct that a Tag can be assignedto.
A duration of a contractual agreement like with a
This section is non-normative.
A commitmentdiscount is a billing discount model that offers reduced rateson preselected SKUs in exchange foran obligated usage or spend amount over a predefined
Usage-based commitment discounts obligate a customer to apredetermined amount of usage over a preselected term. In somecases, usage-based commitment discounts also feature
Spend-based commitment discounts obligate a customer to apredetermined amount of spend over a preselected term. In theusage examples below, each rowmeasures the monetary amount of the hourly commit consumed by thecommitment discount, so the CommitmentDiscountUnit chosen is”USD”, or the billingcurrency.
While customers are bound to the term of a commitmentdiscounts, providers offer some or all of the following paymentoptions before and/or during the term:
For example, if a customer buys a 1-year, spend-based commitmentdiscount with a $1.00 hourly commit and pays with the partialoption, the commitment discount’s payment consists of aone-time purchase in the beginning of the termandmonthly recurring purchases with the following totals:
24 hours * 365 days * $1.00 * 0.5)24 hours * 365 days * $1.00 / 12 months)Commitment discounts follow a “use-it-or-lose-it” model where the
For example, if a customer buys a spend-based commitmentdiscount with a $1.00 hourly commit in January (31 days), only$1.00 is eligible for consumption for each hourly chargeperiod. If a customer has eligible resources runningduring this charge period, an amount of up to $1.00 will beallocated to these resources. Conversely, if a customer doeshave eligible resources running that fully take advantage ofthis $1.00 during this charge period, then some or all of thisamount will go to waste.
Within the FOCUS specification, the following examples demonstratehow a commitment discount appears across various payment andusage scenarios.
All commitment discount purchases appear with a positive
Recurring purchases are allocated across all corresponding chargeperiods of the term when ChargeCategory is “Purchase”,ChargeFrequency is “Recurring”, and CommitmentDiscountQuantity andCommitmentDiscountUnit are reflected only for that chargeperiod.
Using the same commitment discount example as above with aone-year, spend-based commitment discount with a $1.00 hourlycommit purchased on Jan 1, 2023, various purchase options areavailable:
The entire commitment discount is billed onceduring the first charge period of the term for $8,670(derived as 24 hours * 365 days * $1.00).
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2024-01-01T00:00:00Z","ChargeCategory":"Purchase","ChargeFrequency":"One-Time","PricingCategory":"Standard","ResourceId":"<commitment-discount-id>","BilledCost":8760.00,"EffectiveCost":0.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":8760.00,"CommitmentDiscountUnit":"USD"}]
The commitment discount is billed across all 8,760(24 hours * 365 days) charge periods of theterm with $1.00 allocated to each charge period overthe term.
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Purchase","ChargeFrequency":"Recurring","PricingCategory":"Standard","ResourceId":"<commitment-discount-id>","BilledCost":1.00,"EffectiveCost":0.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":1.00,"CommitmentDiscountUnit":"USD"},/*...8,759morerecurringpurchaserecordsforthe*term*...*/]
With a 50/50 split, half of the commitment is billed onceduring the first charge period of the term for $4,380(derived as 24 hours * 182.5 days * $1.00), andthe other half is billed across each charge period over theterm, derived as ($1.00 * 8,760 hours * 0.5).Amortized costs incur half of the amount (i.e. $0.50) from the one-timepurchase and the other half from the recurring purchase.
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2024-01-01T00:00:00Z","ChargeCategory":"Purchase","ChargeFrequency":"One-Time","PricingCategory":"Standard","ResourceId":"<commitment-discount-id>","BilledCost":4380.00,"EffectiveCost":0.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":4380.00,"CommitmentDiscountUnit":"USD"},{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Purchase","ChargeFrequency":"Recurring","PricingCategory":"Standard","ResourceId":"<commitment-discount-id>","BilledCost":0.50,"EffectiveCost":0.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":0.50,"CommitmentDiscountUnit":"USD"},/*...8,759morerecurringpurchaserecordsforthe*term*...*/]
Amortization of commitment discounts occursimilarly regardless of how commitment discount purchases aremade. The same usage-based or spend-based amount is applied evenlyacross all charge periods and potentially allocated to eligibleresources. Continuing with the same commitmentdiscount example, a one-year, spend-based commitmentdiscount with a $1.00 hourly commit and 1 resource (forsimplicity) yields 4 types of scenarios that can occur during acharge period:
In this scenario, one eligible resource runs for the fullhour and consumes $1.00, so one row allocated to theresource is produced.
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Usage","ChargeFrequency":"Usage-Based","PricingCategory":"Committed","ResourceId":"<resource-id>","ConsumedQuantity":1,"ConsumedUnit":"Hour","BilledCost":0.00,"EffectiveCost":1.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":1.00,"CommitmentDiscountStatus":"Used","CommitmentDiscountUnit":"USD"}]
In this situation, the full eligible, $1.00 amount remainedunutilized and results in 1 unused row. In this scenario, it isimportant to note that while CommitmentDiscountQuantity is not because$1 was still drawn down by the commitment discount even though,no resource was allocated, so
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Usage","ChargeFrequency":"Usage-Based","PricingCategory":"Committed","ResourceId":"<commitment-discount-id>","ConsumedQuantity":null,"ConsumedUnit":null,"BilledCost":0.00,"EffectiveCost":1.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":1.00,"CommitmentDiscountStatus":"Unused","CommitmentDiscountUnit":"USD"}]
In this scenario, one eligible resource runs for the fullhour and consumes $0.75 of the $1.00 allocation. One row shows$0.75 to a resource, and the other row shows that$0.25 was unused.
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Usage","ChargeFrequency":"Usage-Based","PricingCategory":"Committed","ResourceId":"<resource-id>","ConsumedQuantity":1,"ConsumedUnit":"Hour","BilledCost":0.00,"EffectiveCost":0.75,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":0.75,"CommitmentDiscountStatus":"Used","CommitmentDiscountUnit":"USD"},{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Usage","ChargeFrequency":"Usage-Based","PricingCategory":"Committed","ResourceId":"<commitment-discount-id>","ConsumedQuantity":null,"ConsumedUnit":null,"BilledCost":0.00,"EffectiveCost":0.25,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":0.25,"CommitmentDiscountStatus":"Unused","CommitmentDiscountUnit":"USD"}]
In this scenario, one eligible resource runs for the fullhour and is charged $1.50. One row shows that $1.00 wasamortized from the commitment discount, and the othershows that $0.50 was charged as standard, on-demand spend.
[{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Usage","ChargeFrequency":"Usage-Based","PricingCategory":"Committed","ResourceId":"<resource-id>","ConsumedQuantity":1,"ConsumedUnit":"Hour","BilledCost":0.00,"EffectiveCost":1.00,"CommitmentDiscountId":"<commitment-discount-id>","CommitmentDiscountQuantity":1.00,"CommitmentDiscountStatus":"Used","CommitmentDiscountUnit":"USD"},{"BillingPeriodStartDate":"2023-01-01T00:00:00Z","BillingPeriodEndDate":"2023-02-01T00:00:00Z","ChargePeriodStartDate":"2023-01-01T00:00:00Z","ChargePeriodEndDate":"2023-01-01T01:00:00Z","ChargeCategory":"Usage","ChargeFrequency":"Usage-Based","PricingCategory":"Standard","ResourceId":"<resource-id>","ConsumedQuantity":1,"ConsumedUnit":"Hour","BilledCost":0.50,"EffectiveCost":0.00}]
Providers natively support various constructs for grouping
Providers may support multiple levels of resource or service groupingmechanisms. FOCUS supports two distinct levels of groupings that arecommonly needed for FinOps capabilities like chargeback, invoicereconciliation and cost allocation.
The table below highlights key properties of the two groupingconstructs supported by FOCUS.
| Property | Billing account | Sub account |
|---|---|---|
| Requirement level | Mandatory | Optional |
| Receives an invoice? | Yes | No |
| Invoiced at | Self | Associated billing account |
| Examples | AWS: ManagementAccount* GCP: Billing Account Azure MCA: BillingProfile Snowflake: Organizational Account |
AWS: Member Account GCP:Project Azure MCA: Subscription Snowflake: Account |
* For organizations that have multiple AWS Member Accountswithin an AWS Organization, consolidated billing is enabled by defaultand invoices are received at Management Account level. A Member Accountcan be removed from AWS consolidated billing whereby the removed accountreceives independent invoices and is responsible for payments.
Cost data presented in the billing datasets originates from varioussources depending on the purchasing mechanism. There are at least 3different pieces of information that are important for understandingwhere cost originated from.
The value for each of these may be different depending on the variouspurchasing scenarios for resources or services. Usecases for purchasing direct, via a Managed Service Provider (MSP), via acloud marketplace, and from internal service offerings were considered.The table below presents a few scenarios to show how the value for eachdimension may change based on the purchasing scenario.
| # | Scenario | Provider | Publisher | Invoice Issuer |
|---|---|---|---|---|
| 1.1 | Purchasing cloud services directly fromcloud provider | Cloud service provider | Cloud service provider | Cloud service provider |
| 1.2 | Purchasing cloud services from the cloudprovider where the cloud region is operated by a 3rd party | Cloud service provider | Cloud service provider | Entity operating the region for the cloudservice provider |
| 2.1 | Purchasing cloud services via MSP | Managed Service Provider | Cloud service provider | Managed Service Provider |
| 2.2 | Purchasing cloud-agnostic resources orservices built/sold by an MSP | Managed Service Provider | Managed Service Provider | Managed Service Provider |
| 2.3 | Purchasing labor services from managedservice provider | Managed Service Provider | Managed Service Provider | Managed Service Provider |
| 3.1 | Purchasing a cloud marketplace offeringthat runs on the cloud provider | Cloud service provider | Company building the software or services(Cloud service provider OR third-party software or servicescompany) | Cloud service provider |
| 3.2 | Purchasing a cloud marketplace offeringthat is not running directly on your cloud infrastructure (e.g,. SaaSproduct, Professional Services) | Cloud service provider | Company producing the SaaS or servicesproduct | Cloud service provider |
| 3.3 | Purchasing a SaaS product that is notdirectly running on your cloud infrastructure from a 3rd party resellermanaged cloud marketplace | Cloud service provider | SaaS provider | Reseller |
| 4.1 | Purchasing SaaS software directly fromprovider | SaaS provider | SaaS provider | SaaS provider |
| 4.2 | Purchasing SaaS software that additionallyruns on your cloud resources (in addition to #4.1) | Cloud service provider | Cloud service provider | Cloud service provider |
| 5.1 | Purchasing internal infrastructure orservices offerings running on-premise | Internal product name | Internal product name | Internal product name |
| 5.2 | Purchasing internal infrastructure orservices offerings running on cloud | Internal product name | Internal product name | Internal product name |
| 5.3 | Associated software license cost for useon an on-premise infrastructure platform (Where license cost ispresented separately in cost data) | Internal product name | Company producing the software | Internal product name |
This section is non-normative.
The following sections contain examples of metadata provided by ahypothetical FOCUS data provider called ACME to supply the requiredreference between the FOCUSdataset and the schema metadata. Provider implementations willvary on how the metadata is disseminated; however, the provider’s chosenmetadata delivery approach should be able to support the structurerepresented in this example.
In this example, the provider supports delivery of FOCUS data viafile export to a data storage system. It uses JSON as the format forproviding the metadata. The provider delivers data every 12 hours into apath structure described below:
| Type of data | Path |
|---|---|
| Export location | /FOCUS |
| Metadata location | /FOCUS/metadata |
| Cost data location | /FOCUS/data |
Here are some metadata examples for various scenarios:
Acme provides metadata about the data generator as a part of theirFOCUS data export. They provide the relevant data via the
Metadata can be provided at a location such as/FOCUS/metadata/data_generator.json.
The updated data generator related metadata could look like this:
ACME has only provided one Schema for theirFOCUS data export. ACME provides a directory of schemas and each schemais a single file. Acme’s provides a file representing the schema for thedata they provide.
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-1234-abcde-12345-abcde-12345.json.
The updated schema related metadata could look like this:
{"SchemaId":"1234-abcde-12345-abcde-12345","FocusVersion":"1.0","CreationDate":"2024-01-01T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]}]}
ACME makes a change to the Schema of their dataexports. For each FOCUS data export, ACME includes a metadata referenceto the schema object. Because multiple files are provided in eachexport, Acme has elected to include a metadata file in each exportfolder that includes the FOCUS schema reference that applies to the dataexport files within that folder. When the schema changes, they includethe new Schema ID in their export metadata fileof the new folder.
Metadata can be provided at a location such as/FOCUS/data/export1-metadata.json
The export metadata could look like this:
{"SchemaId":"1234-abcde-12345-abcde-12345","data_location":[{"filepath":"/FOCUS/data/export1/export1-part1.csv","total_bytes":9010387,"total_rows":4450},{"filepath":"/FOCUS/data/export1/export1-part2.csv","total_bytes":9010387,"total_rows":4450},{"filepath":"/FOCUS/data/export1/export1-part3.csv","total_bytes":9010387,"total_rows":4450},{"filepath":"/FOCUS/data/export1/export1-part4.csv","total_bytes":9010387,"total_rows":4450}]}
New metadata can be provided at a location such as/FOCUS/data/export2-metadata.json.
The new export metadata could look like this:
{"SchemaId":"23456-abcde-23456-abcde-23456","data_location":[{"filepath":"/FOCUS/data/export2/export2-part1.csv","total_bytes":9010387,"total_rows":4450},{"filepath":"/FOCUS/data/export2/export2-part2.csv","total_bytes":9010387,"total_rows":4450},{"filepath":"/FOCUS/data/export2/export2-part3.csv","total_bytes":9010387,"total_rows":4450},{"filepath":"/FOCUS/data/export2/export2-part4.csv","total_bytes":9010387,"total_rows":4450}]}
ACME has decided add additional columns to their FOCUS data export.The new columns are x_awesome_column1, x_awesome_column2, andx_awesome_column3. The provider creates a new
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-23456-abcde-23456-abcde-23456.json.
The updated schema related metadata could look like this:
{"SchemaId":"23456-abcde-23456-abcde-23456","FocusVersion":"1.0","CreationDate":"2024-02-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["awecorp","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"},{"ColumnName":"x_awesome_column3","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"}]}
For an example of how ACME ensures the schema metadata referencerequirement is met see:
ACME has decided to remove columns from their FOCUS data export. Thecolumn removed is x_awesome_column3. The provider creates a new
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-34567-abcde-34567-abcde-34567.json.
The updated schema related metadata could look like this:
{"SchemaId":"34567-abcde-34567-abcde-34567","FocusVersion":"1.0","CreationDate":"2024-03-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"}]}
For an example of how ACME ensures the schema metadata referencerequirement is met see:
ACME has decided to change the datatype of column x_awesome_column1from a string to a number. ACME creates a new
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-67891-abcde-67891-abcde-67891.json.
The updated schema related metadata could look like this:
{"SchemaId":"67891-abcde-67891-abcde-67891","FocusVersion":"1.0","CreationDate":"2024-06-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"}]}
For an example of how ACME ensures the schema metadata referencerequirement is met see:
ACME has discovered that while their export includes the columnx_awesome_column3, the Schema metadata does notinclude this column. In this case, the provider fixes the metadata inthe existing schema object and does not need to create a new schemaobject. Reference metadata remains the same.
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-34567-abcde-34567-abcde-34567.json.
The updated schema related metadata could look like this:
{"SchemaId":"34567-abcde-34567-abcde-34567","FocusVersion":"1.0","CreationDate":"2024-03-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"}]}
ACME’s previous exports used FOCUS version 1.0. They are now going toadopt FOCUS version 1.1. It is required that they create a new schemametadata object which specifies the new FOCUS version via the
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-45678-abcde-45678-abcde-45678.json.
The updated schema related metadata could look like this:
{"SchemaId":"45678-abcde-45678-abcde-45678","FocusVersion":"1.1","CreationDate":"2024-04-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"}]}
For an example of how ACME ensures the schema metadata referencerequirement is met see:
ACME specifies the optional metadata property
The provider creates a new schema object to represent the new schema.The provider includes both the new FOCUS Version and Provider Version inthe schema object.
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-45678-abcde-45678-abcde-45678.json.
The updated schema related metadata could look like this:
{"SchemaId":"45678-abcde-45678-abcde-45678","FocusVersion":"1.1","ProviderVersion":"2.3","name":"New Columns","CreationDate":"2024-04-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"}]}
For reference, the prior schema object looked like this:
{"SchemaId":"34567-abcde-34567-abcde-34567","FocusVersion":"1.0","ProviderVersion":"2.2","CreationDate":"2024-04-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"}]}
For an example of how ACME ensures the schema metadata referencerequirement is met see:
ACME specifies the optional metadata property
The provider creates a new schema object to represent the new schema.The provider includes both the FOCUS Version and Provider Version in theschema object.
Metadata can be provided at a location such as/FOCUS/metadata/schemas/schema-56789-abcde-56789-abcde-56789.json.
The updated schema related metadata could look like this:
{"SchemaId":"56789-abcde-56789-abcde-56789","FocusVersion":"1.1","ProviderVersion":"2.4","CreationDate":"2024-05-02T12:01:03.083z","ColumnDefinition":[{"ColumnName":"BillingAccountId","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"BillingAccountName","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"ChargePeriodStart","DataType":"DATETIME"},{"ColumnName":"ChargePeriodEnd","DataType":"DATETIME"},{"ColumnName":"BilledCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"EffectiveCost","DataType":"DECIMAL","NumericPrecision":20,"NumberScale":10},{"ColumnName":"Tags","DataType":"JSON","ProviderTagPrefixes":["acme","ac"]},{"ColumnName":"x_awesome_column1","DataType":"STRING","StringMaxLength":64,"StringEncoding":"UTF-8"},{"ColumnName":"x_awesome_column2","DataType":"DATETIME"}]}
For an example of how ACME ensures the schema metadata referencerequirement is met see: