Copyright © 2023 – FinOps Open Cost and Usage Specification (FOCUS) a
Series of the Joint Development Foundation Projects, LLC. Linux
Foundation trademark,
and document use rules apply.
This section describes the status of this document at the time of its
publication.
This is a published release of the FinOps Open Cost and Usage
Specification.
This document was produced by a group operating under the W3C Patent
Policy. FOCUS maintains a public list of any patent disclosures made in
connection with the deliverables of the group; that
page also includes instructions for disclosing a patent. An
individual who has actual knowledge of a patent which the individual
believes contains Essential Claim(s) must disclose the information in
accordance with section 6 of the W3C Patent Policy.
This document is governed by the 5 February
2004 W3C Patent Policy.
FOCUS is an open-source specification for cloud billing data. It
defines a common schema for billing data, aligns terminology with the
FinOps Framework 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 members for their contributions to this
work.
This section is non-normative.
FOCUS aims to establish a community-driven specification for
consumption-based billing data. Due to the lack of a broadly adopted
specification, infrastructure and services providers have resorted to
proprietary billing schemas and terminology. However, the lack of
conformance amongst the billing data generators has forced FinOps
practitioners to employ disparate, best-effort schemes which each
practitioner must develop individually for each provider in order to
perform essential FinOps capabilities such as chargeback, cost
allocation, budgeting and forecasting.
The FOCUS specification’s schema definition and FinOps aligned
terminology provide a clear guide for producing FinOps-serviceable
billing datasets. Datasets conforming to FOCUS enable FinOps
practitioners to perform common FinOps capabilities, like the ones
mentioned above, using a generic set of instructions, regardless of the
origin of the dataset.
This project is sponsored by the FinOps Foundation. This work initially
started under the Open Billing working group under the FinOps
Foundation. The decision was made in Jan 2023 to begin to migrate the
work to a newly formed project under the Linux Foundation called the
FinOps Open Cost and Usage Specification (FOCUS) to better support the
creation of a specification.
This specification is designed to be used by three major groups:
The FOCUS working group will develop an open-source specification for
billing data. The schema will define data dimensions, metrics, a set of
attributes about billing data, and a common lexicon for describing
billing data.
The following principles were considered while building the
specification.
While the schema, naming, terminology and attributes of many
providers were reviewed during development, this specification aims to
be provider-neutral. In some cases, the approach may closely resemble
one or more provider’s implementation, while in other cases, the
approach might be new. In all cases, the FOCUS group (community composed
of FinOps practitioners, Cloud and SaaS providers and FinOps vendors)
will attempt to prioritize alignment with the FinOps Framework and Capabilities.
The FOCUS group working on the specification aims to work backwards
from essential FinOps capabilities that practitioners need to perform to
prioritize the dimensions, metrics and the attributes of the billing
data that should be defined in the specification to fulfill that
capability. Some of the enabled capabilities will be documented in the
Appendix: FinOps
Capabilities Enabled by FOCUS (TODO).
The initial specification aims to introduce a common schema and
terminology for billing datasets produced by Cloud Service Providers
(CSPs). The specification however aims to be extensible to SaaS products
and other types of cost datasets. Future versions of the specification
will look to expand the content to support a broader set of prioritized
FinOps capabilities.
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 in
BCP14 [RFC2119][RFC8174] when, and only
when, they appear in all capitals, as shown here.
An implementation of this specification is not compliant if it fails
to satisfy one or more of the “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
or “SHALL NOT” requirements defined in the specification. Conversely, an
implementation of the specification is compliant if it satisfies all the
“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, and “SHALL NOT” requirements
defined in the specification.
There are no current resources available to test for specification
conformance or validators to run on sample data. When one becomes
available, this section of the specification will be updated with
details.
The FOCUS specification defines a group of columns that provide
qualitative values (such as dates, resource, and provider information).
These columns are categorized to as ‘dimensions’ within the dataset and
are needed to serve many FinOps
capabilities. You can use dimensions to categorize, filter, and
reveal details in your data when grouped with ‘metrics’, which are the
quantitative (numeric) values. The Dimensions are presented in
Alphabetical order.
Availability Zone is a provider assigned identifier for a physically
separated and isolated area within a Region that provides high
availability and fault tolerance. Availability Zone is commonly used for
scenarios like analyzing cross-zone data transfer cost and usage based
on where resources are deployed.
The AvailabilityZone column SHOULD be present in the billing data.
This column MUST be of type String and MAY contain null values.
AvailabilityZone
Availability Zone
A provider assigned identifier for a physically separated and
isolated area within a Region that provides high availability and fault
tolerance.
| Constraint | Value |
|---|---|
| Column required | False |
| Data type | String |
| Allows nulls | True |
| Value format | <not specified> |
A billing account is a container for resources and/or services that
are billed together in an invoice. Billing accounts are commonly used
for scenarios like grouping based on organizational constructs, invoice
reconciliation and cost allocation strategies.
A Billing Account ID is a provider assigned identifier for a billing
account.
The BillingAccountId column MUST be present in the billing data. This
column must be of type String and MUST NOT contain null values.
BillingAccountId MUST be a globally unique identifier within a
provider.
See Appendix:
Grouping constructs for resources and/or services for details and
examples of the different grouping constructs supported by FOCUS.
BillingAccountId
Billing Account ID
The identifier assigned to a billing account by the provider.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | <not specified> |
A billing account is a container for resources and/or services that
are billed together in an invoice. Billing accounts are commonly used
for scenarios like grouping based on organizational constructs, invoice
reconciliation and cost allocation strategies.
A Billing Account Name is a display name assigned to a billing
account.
The BillingAccountName column MUST be present in the billing data.
This column MUST be of type String. The BillingAccountName MUST NOT be
null if a display name can be assigned to a billing account.
BillingAccountName MUST be unique within a customer when a customer has
more than one billing account.
See Appendix:
Grouping constructs for resources and/or services for details and
examples of the different grouping constructs supported by FOCUS.
BillingAccountName
Billing Account Name
The display name assigned to a billing account.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | True |
| Value format | <not specified> |
Billing Currency is an identifier that represents the currency that a
charge for resources and/or services was billed in. Billing Currency is
commonly used in scenarios where costs need to be grouped or
aggregated.
The BillingCurrency column MUST be present in the billing data.
BillingCurrency MUST match the currency used in the invoice generated by
the invoice issuer. This column must be of type String and MUST NOT
contain null values. BillingCurrency MUST conform to FOCUS Currency Code Format
requirements.
BillingCurrency
Billing Currency
Represents the currency that a charge was billed in.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | list-of-values |
| Allowed Values | Meets FOCUS Currency Code Format requirements |
Billing period represents the time window for which an organization
has or will receive an invoice for. The time window is inclusive of the
start date and exclusive of the end date.
Billing Period End represents the end date and time of the billing
period.
The BillingPeriodEnd column MUST be present in the billing data. This
column MUST be of type Date/Time and MUST NOT contain null values.
BillingPeriodEnd column MUST conform to FOCUS
Date/Time Format. The sum of the Billed Cost metric for line items
in a given billing period MUST match the sum of the invoices received
for that billing period for a billing account.
BillingPeriodEnd
Billing Period End
The end date and time of the billing period.
| Constraint | Value |
|---|---|
| Column Required | True |
| Data type | Date/Time |
| Allows nulls | False |
| Value format | Meets FOCUS Date/Time Format requirements |
Billing period represents the time window for which an organization
has or will receive an invoice for. The time window is inclusive of the
start date and exclusive of the end date.
Billing Period Start represents the start date and time of the
billing period.
The BillingPeriodStart column MUST be present in the billing data.
This column MUST be of type Date/Time and MUST NOT contain null values.
BillingPeriodStart column MUST conform to FOCUS Date/Time Format. The sum of the
Billed Cost metric for line items in a given billing period MUST match
the sum of the invoices received for that billing period for a billing
account.
BillingPeriodStart
Billing Period Start
The beginning date and time of the billing period.
| Constraint | Value |
|---|---|
| Column Required | True |
| Data type | Date/Time |
| Allows nulls | False |
| Value format | Meets FOCUS Date/Time Format requirements |
Charge period represents the time window in which a charge was
incurred. The time window is inclusive of the charge period start date
and exclusive of the charge period end date. A charge can start and/or
end at any time within a charge period window. The charge period for
continuous usage should match the time granularity of the dataset (e.g.,
1 hour for hourly, 1 day for daily).
Charge Period End represents the end date and time of the charge
period.
The ChargePeriodEnd column MUST be present in the billing data. This
column MUST be of type Date/Time and MUST NOT contain null values.
ChargePeriodEnd column MUST conform to FOCUS
Date/Time Format.
ChargePeriodEnd
Charge Period End
The end date and time of a charge period.
| Constraint | Value |
|---|---|
| Column Required | True |
| Data type | Date/Time |
| Allows nulls | False |
| Value format | Meets FOCUS Date/Time Format requirements |
Charge period represents the time window in which a charge was
incurred. The time window is inclusive of the charge period start date
and exclusive of the charge period end date. A charge can start and/or
end at any time within a charge period window. The charge period for
continuous usage should match the time granularity of the dataset (e.g.,
1 hour for hourly, 1 day for daily).
Charge Period Start represents the starting date and time of the
charge period.
The ChargePeriodStart column MUST be present in the billing data.
This column MUST be of type Date/Time and MUST NOT contain null values.
ChargePeriodStart column MUST conform to FOCUS Date/Time Format.
ChargePeriodStart
Charge Period Start
The beginning date and time of a charge period.
| Constraint | Value |
|---|---|
| Column Required | True |
| Data type | Date/Time |
| Allows nulls | False |
| Value format | Meets FOCUS Date/Time Format requirements |
A Charge Type indicates whether the record represents an upfront or
recurring fee, cost of usage that already occurred, an after-the-fact
adjustment (e.g., credits), or taxes. The Charge Type is commonly used
to identify prepaid purchases separately from usage-based charges, to
separate taxes that may require special handling, or to apply
finer-grained allocation logic to purchases or adjustments.
The ChargeType column MUST be present and MUST NOT be null or empty.
This column is of type String and MUST be one of the allowed values.
See Appendix: Charge Type for details
about allowed values and governance criteria for this dimension.
ChargeType
Charge Type
Indicates whether the record represents an upfront or recurring fee,
cost of usage that already occurred, an after-the-fact adjustment (e.g.,
credits), or taxes.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | list-of-values |
Allowed values:
| Value | Description |
|---|---|
| Adjustment | Any adjustments that are applied after the original usage or purchase record. Adjustments may be related to multiple charges. |
| Purchase | Charges for the acquisition of a service or resource bought upfront or on a recurring basis. |
| Tax | Applicable taxes that are levied by the relevant authorities. Tax charges may vary depending on factors such as the location, jurisdiction, and local or federal regulations. |
| Usage | Charges based on the quantity of a service or resource that was consumed over a given period of time. |
An Invoice Issuer is an entity responsible for invoicing for the
resources and/or services consumed. It is commonly used for cost
analysis and reporting scenarios.
The InvoiceIssuer column MUST be present in the billing data. This
column MUST be of type String and MUST NOT contain null values.
See Appendix: Origination of cost
data section for examples of Provider, Publisher and Invoice Issuer
values that can be used for various purchasing scenarios.
InvoiceIssuerName
Invoice Issuer
The name of the entity responsible for invoicing for the resources
and/or services consumed.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | <not specified> |
A Provider is an entity that made the resources and/or services
available for purchase. It is commonly used for cost analysis and
reporting scenarios.
The Provider column MUST be present in the billing data. This column
MUST be of type String and MUST NOT contain null values.
See Appendix: Origination of cost
data section for examples of Provider, Publisher and Invoice Issuer
values that can be used for various purchasing scenarios.
ProviderName
Provider
The name of the entity that made the resources and/or services
available for purchase.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | <not specified> |
A Publisher is an entity that produced the resources and/or services
that were purchased. It is commonly used for cost analysis and reporting
scenarios.
The Publisher column MUST be present in the billing data. This column
MUST be of type String and MUST NOT contain null values.
See Appendix: Origination of cost
data section for examples of Provider, Publisher and Invoice Issuer
values that can be used for various purchasing scenarios.
PublisherName
Publisher
The name of the entity that produced the resources and/or services
that were purchased.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | <not specified> |
A Region is a provider assigned identifier for an isolated geographic
area where a resource is provisioned in and/or a service is provided
from. Region is commonly used for scenarios like analyzing cost and
prices based on where resources are deployed.
The Region column MUST be present in the billing data. This column
MUST be of type String and MUST NOT contain null values. Region values
MUST be consistent within the provider and MUST be the same values used
to indicate the region when provisioning or purchasing the resource or
service.
Region
Region
Isolated geographic area where a resource is provisioned in and/or a
service is provided from.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | <not specified> |
A Resource ID is an identifier assigned to a resource by the
provider. The Resource ID is commonly used for cost reporting, analysis,
and allocation scenarios.
The ResourceId column MUST be present in the billing data. This
column MUST be of type String. The ResourceId value MAY be a nullable
column as some cost data rows may not be associated with a resource.
ResourceId MUST appear in the cost data if an identifier is assigned to
a resource by the provider. ResourceId SHOULD be a fully-qualified
identifier that ensures global uniqueness within the provider.
ResourceId
Resource ID
Identifier assigned to a resource by the provider.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | True |
| Value format | <not specified> |
The Resource Name is a display name assigned to a resource. It is
commonly used for cost analysis, reporting, and allocation
scenarios.
The ResourceName column MUST be present in the billing data. This
column MUST be of type String. The ResourceName value MAY be a nullable
column as some cost data rows may not be associated with a resource or
because a display name cannot be assigned to a resource. ResourceName
MUST NOT be null if a display name can be assigned to a resource.
Resources not provisioned interactively or only have a system generated
ResourceId MUST NOT duplicate the same value as the ResourceName.
ResourceName
Resource Name
Display name assigned to a resource.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | True |
| Value format | <not specified> |
The Service Category is the highest-level classification of a service
based on the core function of the service. Each service should have one
and only one category that best aligns to its primary purpose. The
Service Category is commonly used for scenarios like analyzing costs
across providers and tracking the migration of workloads across
fundamentally different architectures.
The ServiceCategory column MUST be present and MUST NOT be null or
empty. This column is of type String and MUST be one of the allowed
values.
ServiceCategory
Service Category
Highest-level classification of a service based on the core function
of the service.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | List of values |
Allowed values:
| Service Category | Description |
|---|---|
| AI and Machine Learning | Artificial Intelligence and Machine Learning related technologies. |
| Analytics | Data processing, analytics, and visualization capabilities. |
| Business Applications | Business and productivity applications and services. |
| Compute | Virtual, containerized, serverless, or high-performance computing infrastructure and services. |
| Databases | Database platforms and services that allow for storage and querying of data. |
| Developer Tools | Software development and delivery tools and services. |
| Multicloud | Support for interworking of multiple cloud and/or on-premises environments. |
| Identity | Identity and access management services. |
| Integration | Services that allow applications to interact with one another. |
| Internet of Things | Development and management of IoT devices and networks. |
| Management and Governance | Management, logging, and observability of a customer’s use of cloud. |
| Media | Media and entertainment streaming and processing services. |
| Migration | Moving applications and data to the cloud. |
| Mobile | Services enabling cloud applications to interact via mobile technologies. |
| Networking | Network connectivity and management. |
| Security | Security monitoring and compliance services. |
| Storage | Storage services for structured or unstructured data. |
| Web | Services enabling cloud applications to interact via the Internet. |
| Other | New or emerging services that do not align with an existing category. |
A service represents an offering that can be purchased from a
provider (e.g., cloud virtual machine, SaaS database, professional
services from a systems integrator). A service offering can include
various types of usage or other charges. For example, a cloud database
service may include compute, storage, and networking charges.
The Service Name is a display name for the offering that was
purchased. The Service Name is commonly used for scenarios like
analyzing aggregate cost trends over time and filtering data to
investigate anomalies.
The ServiceName column MUST be present in the cost data. This column
MUST be of type String and MUST NOT contain null values.
ServiceName
Service Name
An offering that can be purchased from a provider (e.g., cloud
virtual machine, SaaS database, professional services from a systems
integrator).
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | False |
| Value format | <not specified> |
A sub account is an optional provider-supported construct for
organizing resources and/or services connected to a billing account. Sub
accounts are commonly used for scenarios like grouping based on
organizational constructs, access management needs and cost allocation
strategies. Sub accounts must be associated with a billing account as
they do not receive invoices.
A sub account ID is a provider assigned identifier assigned to a sub
account.
The SubAccountId column MUST be present in the billing data. This
column MUST be of type String. If a provider supports a sub account
construct, that value MUST appear in this column. If a provider does not
support a sub account construct (only has a billing account) or does
support a sub account construct, but the charge does not apply to a sub
account, the SubAccountId column MUST be null.
See Appendix:
Grouping constructs for resources and/or services for details and
examples of the different grouping constructs supported by FOCUS.
SubAccountId
Sub Account ID
An ID assigned to a grouping of resources and/or services, often used
to manage access and/or cost.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | True |
| Value format | <not specified> |
A sub account is an optional provider-supported construct for
organizing resources and/or services connected to a billing account. Sub
accounts are commonly used for scenarios like grouping based on
organizational constructs, access management needs and cost allocation
strategies. Sub accounts must be associated with a billing account as
they do not receive invoices.
A sub account name is a display name assigned to a sub account.
The SubAccountName column MUST be present in the billing data. This
column MUST be of type String. If a provider supports setting a display
name for sub accounts, that value MUST appear in this column. If a
provider does not support a sub account construct (only has a billing
account) or does support a sub account construct, but the charge does
not apply to a sub account, the SubAccountName column MUST be null.
See Appendix:
Grouping constructs for resources and/or services for details and
examples of the different grouping constructs supported by FOCUS.
SubAccountName
Sub Account Name
A name assigned to a grouping of resources and/or services, often
used to manage access and/or cost.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | String |
| Allows nulls | True |
| Value format | <not specified> |
0.5
The FOCUS specification defines a group of columns that provide
numeric values. These columns are categorized to as ‘metrics’ within the
dataset and are needed to serve many FinOps
capabilities. Metric columns in the dataset allow for aggregation
operations such as arithmetic operations (sum, multiplication, averaging
etc.) and statistical operations. When combined with dimensions (which
are qualitative value columns), metrics reveal details in your data.
Amortized cost represents the sum of the amortized upfront fees,
amortized recurring fees, and the usage cost of the line item. This
column is often used to show spending trends that include on demand
rates, effective commitment-based discount rates, recurring commitments,
as well as amortization of upfront fees. The fee and upfront
amortization portion of this column’s value should be proportional to
the number of units for the line item and the time granularity of the
data. The currency for the value specified in Amortized Cost can be
found in the Billing Currency column. The
aggregated Amortized Cost for a billing period may not match the charge
received on the invoice for the same billing period.
Practitioners are faced with two main challenges with respect to this
metric:
The AmortizedCost column MUST be present in the billing data. This
column MUST be a numeric value of type Decimal and MUST NOT contain null
values.
AmortizedCost
Amortized Cost
The cost inclusive of amortized upfront fees, amortized recurring
fees, and the usage cost of the line item.
Providers should distribute the commitment purchase amount instead of
including a line item at the beginning of a period so practitioners do
not need to manually distribute the fee themselves.
The amortization of the upfront charge should be amortized using a
methodology determined by the provider that reflects the needs of their
customer base and is proportional with usage quantity and the time
granularity of the line item. Should a practitioner desire to amortize
upfront fees using a different approach, the practitioner can do so
using the Billed Cost for the line item representing the initial
purchase.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | Decimal |
| Allows nulls | False |
| Value format | Numeric value |
The Billed Cost represents a charge inclusive of negotiated discounts
that a consumer would be charged for each billing period. Billed Cost
does not amortize upfront charges (one-time or recurring). The currency
for the value specified in Billed Cost can be found in the Billing Currency column. Billed Cost is
often used to perform FinOps capabilities that require cash-basis
accounting such as cost allocation, budgeting, and invoice
reconciliation.
The BilledCost column MUST be present in the billing data. This
column MUST be a numeric value of type Decimal and MUST NOT contain null
values. The aggregated BilledCost for a billing period MUST match the
charge received on the invoice for the same billing period.
BilledCost
Billed Cost
A charge inclusive of negotiated discounts that a consumer would be
charged for each billing period.
| Constraint | Value |
|---|---|
| Column required | True |
| Data type | Decimal |
| Allows nulls | False |
| Value format | Numeric value |
0.5
Attributes are requirements that apply to the billing datasets.
Requirements on data content can include naming conventions, data types,
formatting standardizations, etc. Attributes may introduce high-level
requirements for data granularity, recency, frequency, etc. Requirements
defined in attributes are necessary for servicing FinOps
capabilities accurately using a standard set of instructions
regardless of the origin of the data.
Column IDs provided in cost data following a consistent naming
convention reduces friction for FinOps practitioners that consume the
data for analysis, reporting, and other use cases.
All columns defined in FOCUS MUST follow the naming requirements
listed below. Provider generated columns SHOULD adopt these same naming
requirements over time.
ColumnNamingConvention
Column Naming Convention
Naming convention for columns appearing in billing data.
Columns that contain currency information in cost data following a
consistent format reduces friction for FinOps practitioners that consume
the data for analysis, reporting, and other use cases.
All currency related columns defined in the FOCUS schema MUST follow
the currency formatting requirements listed below. Provider generated
currency-related columns SHOULD adopt the same format requirements over
time.
CurrencyCodeFormat
Currency Code Format
Formatting for currency columns appearing in billing data.
None
Columns that provide date and time information conforming to
specified rules and formatting requirements ensure clarity, accuracy,
and ease of interpretation for both humans and systems.
All date/time related columns, defined in the FOCUS specification,
MUST be represented in UTC and follow the ISO 8601 aligned formatting
requirements listed below. Provider generated date/time related columns
SHOULD also be represented in UTC and conform to the ISO 8601
standard.
DateTimeFormat
Date/Time Format
Rules and formatting requirements for date/time related columns
appearing in billing data.
None
Cost data rows that don’t have a value that can be presented for a
column must be handled in a consistent way to reduce friction for FinOps
practitioners that consume the data for analysis, reporting, and other
use cases.
All columns defined in FOCUS MUST follow the null handling
requirements listed below. Provider generated columns SHOULD adopt these
same null handling requirements over time.
NullHandling
Null Handling
Indicates how to handle columns that don’t have a value.
None
0.5
This section is non-normative.
TODO Needs to be completed and linked
Resource:
Add definition
Service:
Add definition
This section is non-normative.
Providers natively support various constructs for grouping resources
and/or services. These grouping constructs are often used to mimic
organizational structures, technical architectures, cost
attribution/allocation and access management boundaries, or other
customer-specific structures based on requirements.
Providers may support multiple levels of resource and/or service
grouping mechanisms. FOCUS supports two distinct levels of groupings
that are commonly needed for FinOps capabilities like chargeback,
invoice reconciliation and cost allocation.
The table below highlights key properties of the two grouping
constructs 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: Management Account* GCP: Billing Account Azure MCA: Billing Profile Snowflake: Organizational Account |
AWS: Member Account GCP: Project Azure MCA: Subscription Snowflake: Account |
* For organizations that have multiple AWS Member Accounts
within an AWS Organization, consolidated billing is enabled by default
and invoices are received at Management Account level. A Member Account
can be removed from AWS consolidated billing whereby the removed account
receives independent invoices and is responsible for payments.
Cost data presented in the billing datasets originates from various
sources depending on the purchasing mechanism. There are at least 3
different pieces of information that are important for understanding
where cost originated from.
The value for each of these may be different depending on the various
purchasing scenarios for resources and/or services. Use cases for
purchasing direct, via a Managed Service Provider (MSP), via a cloud
marketplace, and from internal service offerings were considered. The
table below presents a few scenarios to show how the value for each
dimension may change based on the purchasing scenario.
| # | Scenario | Provider | Publisher | Invoice Issuer |
|---|---|---|---|---|
| 1.1 | Purchasing cloud services directly from cloud provider |
Cloud service provider | Cloud service provider | Cloud service provider |
| 1.2 | Purchasing cloud services from the cloud provider where the cloud region is operated by a 3rd party |
Cloud service provider | Cloud service provider | Entity operating the region for the cloud service provider |
| 2.1 | Purchasing cloud services via MSP | Managed Service Provider | Cloud service provider | Managed Service Provider |
| 2.2 | Purchasing cloud-agnostic resources and/or services built/sold by an MSP |
Managed Service Provider | Managed Service Provider | Managed Service Provider |
| 2.3 | Purchasing labor services from managed service provider |
Managed Service Provider | Managed Service Provider | Managed Service Provider |
| 3.1 | Purchasing a cloud marketplace offering that runs on the cloud provider |
Cloud service provider | Company building the software and/or services (Cloud service provider OR third-party software and/or services company) |
Cloud service provider |
| 3.2 | Purchasing a cloud marketplace offering that is not running directly on your cloud infrastructure (e.g,. SaaS product, Professional Services) |
Cloud service provider | Company producing the SaaS or services product |
Cloud service provider |
| 3.3 | Purchasing a SaaS product that is not directly running on your cloud infrastructure from a 3rd party reseller managed cloud marketplace |
Cloud service provider | SaaS provider | Reseller |
| 4.1 | Purchasing SaaS software directly from provider |
SaaS provider | SaaS provider | SaaS provider |
| 4.2 | Purchasing SaaS software that additionally runs on your cloud resources (in addition to #4.1) |
Cloud service provider | Cloud service provider | Cloud service provider |
| 5.1 | Purchasing internal infrastructure and/or services offerings running on-premise |
Internal product name | Internal product name | Internal product name |
| 5.2 | Purchasing internal infrastructure and/or services offerings running on cloud |
Internal product name | Internal product name | Internal product name |
| 5.3 | Associated software license cost for use on an on-premise infrastructure platform (Where license cost is presented separately in cost data) |
Internal product name | Company producing the software | Internal product name |
Explore the goals of FOCUS, view sample use cases, and learn about gathering FOCUS conformed datasets.
Take the Free course
An in-depth understanding of the FOCUS Specification, learn how to use FOCUS datasets to answer real-world business questions.
Learn more