When your cloud environment spans multiple cloud service providers (CSPs) and SaaS providers, it can be challenging to collect cost and usage data in a way that gives you complete visibility. Each provider formats its data according to a unique billing model, and these inconsistencies can leave you with fragmented information about your total cloud spend. Manually collating disparate data from multiple providers is inefficient and can result in incomplete data that doesn’t meet your needs for cost management activities like allocation, forecasting, and unit economics.
In this post, we’ll show you how the FinOps Open Cost and Usage Specification (FOCUS) simplifies the process of understanding and managing your cloud costs. We’ll dig into what FOCUS means for your cost visibility and show you how FOCUS can help you efficiently collect and analyze cost data from multiple providers. We’ll also look at how Datadog is participating in the FOCUS project by applying our expertise as a cost and usage data consumer and provider to help shape the specification. But first, we’ll look more closely at the FOCUS specification and how it normalizes multi-cloud cost data.
FOCUS defines a standard format providers can use to deliver their cost and usage data. By normalizing cloud cost data in a vendor-agnostic format, FOCUS enables users—such as FinOps practitioners, finance team members, engineers, and stakeholders—to analyze costs from all providers. FOCUS promotes efficient cloud cost management and helps organizations understand and maximize the business value of their cloud spending.
In this section, we’ll describe how the FOCUS specification formats cost and usage data and how the FOCUS project maintains and improves the spec.
The FOCUS specification defines a set of columns: specifically, the fields of data that must or may be included in a cost and usage dataset. It also states the type of data each column holds, such as decimal or string. Each row in a FOCUS-compliant dataset describes the charge for a single cost or usage item by conveying its properties within the columns defined by the spec. For example, a row from a FOCUS-compliant AWS billing dataset might describe a charge related to Amazon SQS. That row’s Charge Description column would hold a string value like the one shown here that summarizes the charge:
$0.40 per million Amazon SQS standard requests in Tier1 in US West (Oregon)
Other columns provide additional data about the charge, such as the Billed Cost column, which holds a numeric value representing the charge accrued (including any contractual discounts applied), and the Service Name column, which identifies the provider’s offering. The example row below is excerpted to show only these columns, along with Charge Description:
BilledCost ChargeDescription ServiceName
0.0000008 $0.40 per million Amazon SQS standard requests in Tier1 in US West (Oregon) Amazon Simple Queue Service
Still other columns bring context to cost data by describing how much of a cloud service you have used. The Consumed Quantity and Consumed Unit columns together quantify the hours, bytes, requests, or other units of measure that the row’s cost is derived from. For example, a row in a FOCUS-compliant dataset that describes usage of a particular type of compute instance can help you see not just how much you have paid, but also how many hours during the billing period you have run that instance. The example row below is excerpted to show columns that identify and quantify Amazon EC2 usage.
ConsumedQuantity ConsumedUnit ResourceType ServiceCategory ServiceName
168 Hours instance Compute Amazon Elastic Compute Cloud
For further context, each row also includes a unique product identifier in the SkuId column. In the case of a compute instance charge, SkuId reflects properties of the instance including its instance type, size, and region. SkuPriceId reflects its price.
The FOCUS specification includes a Feature Level designation that indicates whether a field is mandatory, optional, or conditional. By giving providers the flexibility to omit fields from a dataset if they are not relevant, the specification prevents datasets from being any larger than necessary. Alternatively, unused columns can contain a value of NULL. For example, in a dataset from a provider that does not support commitment discount programs,
columns that reference commitment discount data—including Commitment Discount Name and CommitmentDiscountId—will be absent or NULL.
The FOCUS specification was created and is maintained by a group of FinOps practitioners, CSPs, SaaS providers, and other contributors in an open source project led by the FinOps Foundation. Datadog helped co-found the project and is actively engaged in it to this day. Later in this post, we’ll take a closer look at Datadog’s role in the project.
Development of the FOCUS specification is progressing quickly. Version 1.0 was released in June 2024, and all major public clouds quickly announced their support. FOCUS 1.1 was released in November 2024. In 2025, the FOCUS project plans to release new versions of the specification that provide deeper support for SaaS costs and give FOCUS users even broader visibility into their overall cloud spending.
By normalizing cost and usage data, FOCUS allows for comprehensive cloud cost analysis that can help you launch and mature a FinOps practice. The FinOps framework defines organizational capabilities that are essential components of a successful FinOps practice, and FOCUS is intentionally designed to help you attain these capabilities. Some examples of FinOps capabilities enabled by FOCUS include:
To illustrate some common applications of the FOCUS standard and help you get started using it, the FinOps Foundation maintains a library of use cases. Each use case includes context that describes the need or problem it addresses, identifies the FOCUS columns that contain the relevant data, and provides a SQL query you can use to retrieve that data.
To accelerate your FinOps evolution, you can use this library of use cases to attain capabilities such as data ingestion, budgeting, and rate optimization. The library also includes use cases that help you create cost reports to keep your stakeholders informed. You’ll also find use cases that enable you to see how much of your cloud spending is covered by discounts or reservations.
As part of Datadog’s engagement with the FOCUS project, Senior FinOps Analyst Deeja Cruz has contributed several use cases, including:
By bringing cost and usage data from all providers into a common format, the FOCUS standard provides an efficient way to explore and understand the complete picture of your costs. FOCUS’s goals align with those of Datadog, namely, to unify data from disparate sources and offer a single point of visibility for efficient monitoring. In this section, we’ll look at some specifics about how Datadog is using the FOCUS specification and engaging with the FOCUS project to help build a standard that benefits everyone’s cloud cost monitoring.
Like our customers, Datadog uses public cloud services extensively. We have a critical need to understand our CSP and SaaS costs in detail so that we can allocate, forecast, and optimize our costs continually. For this, we rely on Cloud Cost Management (CCM). CCM’s Multisource Querying feature allows us to analyze multi-cloud costs by using tags based on FOCUS data, and the out-of-the-box FOCUS dashboard makes it easy to visualize costs and share cost data with stakeholders throughout the organization.
We understand that our customers need to see the complete cost of running their services, including the costs of CSPs and SaaS providers like Datadog. Datadog Costs (now in preview) gives you daily cost data for each Datadog service you’re using. Your costs are automatically tagged, so you can easily break them down to see how much of your Datadog spending is attributable to any team or service during any billing period of interest. The screenshot below shows the Software Catalog page detailing Datadog costs for a single service.
Similarly, Datadog’s Custom Costs feature helps you understand your spending on other SaaS providers. You can upload FOCUS-formatted cost and usage datasets, then explore your SaaS costs in CCM and use Multisource Querying to analyze costs from all your CSPs and SaaS providers. You can also use Custom Costs to track the costs of your private clouds and custom applications, which helps ensure that you don’t have gaps in your cost visibility.
Besides being a consumer and provider of cost and usage data, Datadog remains an active partner in the FOCUS project by helping to define the specification and encourage its adoption. Datadog Staff Engineer Christopher Harris is a member of the FOCUS steering committee, working to shape and execute the vision of the FOCUS standard. Christopher has also served as a project maintainer since the specification’s initial v0.5 release. In this role, he leads the project’s release logistics by delivering key priorities with each new version of the specification.
Deeja Cruz (whose work on FOCUS use cases we saw earlier in this post) is a FOCUS project contributor, collaborating with other contributors to deliver code for each version of the specification. Deeja’s input helps realize the potential of the FOCUS standard and enables new functionality, including expanded support for SaaS costs planned for upcoming versions of the FOCUS specification.
Understanding the costs of your multi-cloud environment—including SaaS costs—is essential for maximizing the value of your cloud spending. Datadog is actively investing in the FOCUS standard and surfacing data from your FOCUS-compliant cost and usage datasets so that you can analyze all your costs alongside your infrastructure, performance, and security data.
To learn more about how to use your FOCUS data in Datadog, see the documentation on CCM, Multisource Querying, and Datadog Costs. If you’re not already using Datadog, you can start today with a free 14-day trial.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。