3 Metrics Your FinOps Team Needs to Measure Cloud Spend

Despite its millions of rows of data, a typical cloud bill does a simple thing — it shows how much you spent last month on cloud. However, you need a specific set of metrics to answer meaningful questions about what it’s really costing to run cloud, and to understand what direction these costs are headed.

Since we last wrote about the importance of having a true cost metric for understanding AWS spend, we have seen the demand for these capabilities increase for all public clouds as FinOps practices mature industry wide. The cloud vendors — particularly Azure — have made this more straightforward by improving the granularity of their billing exports. In today’s multi-cloud world, Apptio is focused on providing you a single true cost metric and a range of metrics that can be used together to answer the varied questions of myriad stakeholders. In this post, we will review three types of cost metric that can help you answer most of these questions and explore how this is supported by the recent IBM Cloudability launch of Cost List for Azure.

An underappreciated aspect of the FinOps Inform phase

To bring financial accountability to the variable, consumption-based, spend model of public cloud, FinOps practices are built around three phases beginning with the Inform phase. While informing stakeholder centers on getting “visibility and allocation” of cloud costs with a heavy focus on how to map the millions of billing lines to business groups, it’s crucial not to lose sight of the need to accurately measure the underlying charges in ways meaningful to the business. Consider that AWS has at least 14 standard cost columns in each customer’s CUR file. So when measuring the cost of a fleet of virtual machines (VMs), a managed database, or any other cloud resources, what are the best metrics to use, and is there a standard approach across clouds?

Three ways to measure cloud costs

1. Invoiced Cost

Let’s start with perhaps the most obvious way of measuring cost: what you were charged by the cloud vendor in that month’s invoice. This should factor in any custom pricing agreements that were applied — something that isn’t always represented in billing exports — and will be impacted by commitments such as Reserved Instances (RIs) and Savings Plans(SPs) that have been paid upfront. For example, a VM that is covered by upfront RIs for the entire month will have an invoice cost of $0. Conversely, a large upfront commitment purchase at the end of the month will lead to a large invoice cost even though almost none of it has been consumed yet.

While from a cash-flow perspective — and for your IT finance team — this view on cost is important, for most scenarios, it wouldn’t be described as measuring the true cost of running cloud. For that reason, this metric wouldn’t typically be used for a showback or chargeback. Cloudability maps the invoice cost from each cloud vendor’s detailed billing export and makes it available via the Cost (Total) metric.

2. Consumed Cost

The next natural task is to calculate the cost of cloud consumed over a specific period of time — often a month — or for a set of cloud resources. While this would also typically factor in custom pricing agreements (unless not passed on to end users), the key difference is the handling of commitments.

To get this cost, it’s necessary to map the full cost of consumed commitments to where and when the consumption happened. For example, suppose a VM drew down on a particular RI (or multiple RIs and SPs, for that matter) during the month. In that case, the full cost of the VM includes the exact amount of the commitment(s) it consumed and any on-demand charges for hours during which the VM wasn’t covered.

When calculating this metric, we also need to disregard spikes associated with the large upfront cash payments of commitments. While important from a cash perspective, these charges represent future usage.

This metric not only gives a far more accurate picture of underlying cost trends but can also be used widely for showback or chargeback purposes. We could say this is a true cost metric. Cloudability makes this available across multiple commitment constructs and cloud vendors via the Cost (Amortized) metric.

3. List Cost

With different types of discounts and commitments continuously affecting the rates paid for cloud usage — a single VM can have many different hourly rates applied during a billing period — it can be handy to surface an “unadulterated” or list cost metric. Doing so allows delivery teams and engineers — who often can’t influence discounts or commitment coverage — to have consistency in cloud pricing, which helps with financial planning and measures the impact of their efficiency initiatives. This metric also enables the FinOps team or Cloud Center of Excellence (CCoE) to quantify different cost savings across the organization.

Cloudability is able to calculate this metric using a combination of data present in the detailed billing exports and API-based price sheets.

Apptio is excited to announce support for the Cost (List) metric for Azure Compute and Azure Database services (full support is already provided for AWS services; stay tuned for additional Azure service support). Customers with monitored Azure spend can use this metric today throughout Cloudability.

Combining metrics to surface exact cost savings

Since Cost (List) gives you an “original cost” and Cost (Amortized) gives you your effective — or true cost — of running cloud, the difference between these metrics can be used to quantify the exact savings realized due to commitments and Spot Instances. Depending on your situation, the delta may also include savings from custom pricing agreements (see table below to identify when adjusted metrics are required to capture such agreements).

The dashboard above demonstrates how cost list and cost amortized can be used together in a chart or table to achieve this visibility. The dashboard also leverages a Cloudability Business Metric called “Realized Savings”, which is defined by the customer and can be used as a standalone metric throughout the platform. Crucially, all of these metrics can be used with any reporting dimension, which means the savings can be associated with usage at the team, application, or individual resource level.

A handy multi-cloud cost metric summary

While Cloudability gives you the flexibility to choose a metric for the job at hand, it can be helpful to understand how these metrics represent the underlying charges, especially since there are differences in how the vendors handle the various commitment types within their billing. The following table summarizes how usage covered by commitments and commitment sign-up charges impact the key metrics.

* Indicates that custom pricing agreements are reflected

Some notable items:

• Azure billing exports always reflect custom pricing agreements directly and in the local currency. The Cloudability custom pricing module can surface “adjusted” metrics to get the same result with AWS data.
• It can be surprising that AWS uses the full on-demand cost for usage covered by Savings Plans. This is offset by additional “negation” lines within the exports.
• Cloudability represents Cost (List) as $0 for sign-up charges. This is to avoid doubling up charges as the commitments get drawn down.

Consistently measure costs across cloud providers

Our goal is to give you a set of metrics that work across cloud providers to surface what’s being paid every month — as with Cost (Total) — and a consistent means for measuring the true cost of running cloud. The Cost (Amortized) and Cost (List) metrics provide this consistency and support CCOE efforts to quantify savings. Stay tuned over the coming months as we make some exciting announcements focused on measuring Google Cloud costs, and learn more about how Cloudability can help you measure the true cost of your cloud investments.