The Unit Economics Working Group is proud to introduce this practical guide about cloud unit economics. Our mission with this project is to create common ground, identify standards, and build a better understanding of what cloud unit economics are and how they can be leveraged by your organizations as part of a greater FinOps strategy.
The cloud’s ability to scale resources up and down to align with current demand requirements, often referred to as elasticity, is simultaneously both one of the key benefits of cloud computing and its greatest liability.
This elasticity and the cloud’s inherent variable cost structures (that made the emergence of FinOps inevitable) have created new financial and operational challenges that require the creation of systems and processes to measure the variable costs and usage metrics associated with these dynamic infrastructure changes. This document focuses on Cloud Unit Economics as one such system that can bring a number of solutions.
Cloud Unit Economics is the specific application of the broader concept of unit economics to the cloud computing domain. Below you will find an introduction to its practical application and a methodology to quantify the associated cost and usage metrics of elasticity.
This document also covers how the application of unit economics can enable cloud-driven organizations to build more efficient systems and ultimately provide a common language to align both business and engineering leaders.
One of the most important concepts in FinOps is unit economics…
– Chapter 1: What is FinOps, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
The FinOps Foundation define six principles that serve as guidance for the FinOps professional. Why do they specifically call out unit economics? What makes it such an important concept?
In short, it’s because Cloud Unit Economics directly supports each principle. Just like the FinOps practice as a whole, Cloud Unit Economics is not a goal in and of itself, but rather a powerful system for achieving the maximum return on your cloud investment in pursuit of the six principles of FinOps.
Cloud Unit Economics can be defined as a system of profit maximization based on objective measurements of how well your organization is performing against, not only its FinOps goals, but as a business in the market. Cloud Unit Economics achieves these noble goals by leveraging the measurement of marginal cost (a.k.a., unit cost metrics) specific to the development and delivery of cloud-based software and marginal revenue (a.k.a., unit revenue metrics).
By calculating the difference between marginal cost and marginal revenue, you can determine where your cloud operations break even and begin to generate a profit — an important concept in economics overall and one of the most effective ways to make data-driven business decisions regarding your cloud investment.
This document was written mostly with commercial SaaS and cloud-driven commercial organizations in mind. But, Cloud Unit Economics can be applied to other types of organizations. While most companies measure their success in revenue or profit, a public sector organization (e.g., federal, state, or local government) or nonprofit does not. Instead, value is typically measured in terms of the success (or failure) of the delivery of civic goods or services.
In addition, the value may be derived through the accurate forecasting of overall spending to maximize the use of budgeted resources. If you want to apply Cloud Unit Economics to a non-profit or a public sector entity, simply replace the words profit or revenue with value.
Cloud unit economics can unlock the following benefits:
Quantify the cloud’s role in your financial performance. Cloud Unit Economics is an effective tool for a company’s management, investors, and employees to understand its financial performance.
Forecast profitability. Based on a unit cost analysis, unit economics shows how profitable a business is or how soon it will achieve profitability, and what factors are affecting its margins.
Build a plan for cloud cost optimization. Cloud Unit Economics allows companies to understand whether their product is overpriced or undervalued. This can help them identify what should be optimized, and how.
Evaluate a product’s future potential. Relying on Cloud Unit Economics, businesses can better understand what products and features customers are using, making it easier to make changes to product roadmap and engineering priorities.
Drive more responsible use of cloud resources by end users. Cloud Unit Economics can be used to measure the impact of end-user behavior on cloud costs, and to drive more cost-conscious behavior. If the end users are internal (employees), unit economics can spotlight opportunities for improved usage, such as not retaining too many copies of files, etc. If the end users are external (customers), unit economics can spotlight areas where usage may need to be shaped/governed via throttling, incentives to change behavior, etc.
Ultimately, by quantifying the cost to produce or the cost to serve, cloud engineers can articulate their contribution to gross profit margin due to the architectural, development, and operating choices they make. Product teams will have key data points to support pricing decisions, and the business will be able to forecast cloud costs better even though cloud resource consumption is variable.
Cloud Unit Economics also supports a broader set of metrics used to evaluate the profitability of products and customers. These include:
Cloud Unit Economics is a key way to communicate both the cost and the value of everything an organization is doing in the cloud. As such, it depends on key interactions across all other FinOps domains, and understanding their definitions is important. We recommend reviewing the following Capabilities before proceeding with the rest of the playbook.
To get the most value and understanding from this playbook, review relevant Unit Economics and general FinOps terms before proceeding. Important terms will also be linked to definitions throughout the playbook.
Measuring Unit Economics for Cloud IT is as important as it is complex. The ability to understand current costs, and to predict what future costs will be and should be, is directly tied to an organization’s Unit Economics capabilities.
More specifically, Unit Economics capabilities are critical to understanding:
Complexity stems from many sources, including variable cost models, shared resources, on-demand provisioning, and disparate/siloed data sets. But organizations that effectively address this complex problem space will be rewarded with insights that will empower them to maximize the business advantage they obtain in the cloud.
One of the goals of this document is to help you learn how you might put Cloud Unit Economics to work for your organization. One of the most important details to determine upfront as part of your Cloud Unit Economics journey is what key metric best serves your business needs.
Consider using the following examples to kick start that journey and to give you a taste of what is possible:
Cloud Unit Economics is a universally useful system, but there’s no one-size-fits-all approach to metrics. The right metrics are a product of what you do, who you serve, how big you are, and any other defining factors about your business.
Another way to look at cost to produce is managing and tracking costs of non-production costs.
And Cost to serve is once the promotion to production begins.
Cloud Unit Economics metrics provide a common language that enables Engineering, Finance and Business stakeholders to understand and discuss cloud spend in a meaningful way. They translate the esoteric language of the cloud bill into units of business value that resonate with stakeholder groups.
In so doing, they become the fuel that powers the inter-departmental collaboration required for FinOps to succeed. Conversations about absolute spend can move to focusing on the amount of business value achieved per unit of cloud spend:
By tying cloud spend to business value, Cloud Unit Economics metrics provide insights that enable stakeholder groups to make informed decisions about how best to use the cloud to maximize business advantage. In an organization with mature Cloud Unit Economics capabilities, these measurements should function as primary drivers for business decisions, increasing the value of FinOps to the organization.
Cloud Unit Economics metrics also enable organizations to benchmark the performance of internal teams and the organization as a whole, when compared to industry competitors. They make it easier to identify areas for improvement and to establish efficiency targets:
Additional motivations to practice Cloud Unit Economics in FinOps include:
Examples of Cloud Unit Economics by measurement categories include:
|BUSINESS (Sales based on the way products are sold)||FINANCIAL (Service component value indicator)||TECHNICAL (Sum of FinOps tactics and engineering choices at infra value layer)|
|Cost per weekly active user||Cost variance reductions||Cost per core hour|
|Cost per million transactions||Spend risk reductions||Cost per GB of RAM|
|Cost per million in revenue|
Unit Economics should be discussed at the very beginning of the FinOps Journey; it will provide a stronger link with several stakeholders, especially at the business level when the only information they receive is a big cloud bill (and potentially growing month on month).
As the “How to Get Started” chapter explains, there are different stages during the adoption until it’s fully mature, nevertheless the discussions about defining the key metric(s) should begin as soon as the stakeholders are engaged.
Identifying the key metric(s) must be a priority and to be done as early as possible to allow the building of a prototype of how to collect and represent the outcome, but also will allow engineers to enable integration between the different systems to capture the data in a consistent and recurrent way, and give business stakeholders a clear view of what is contained and represented.
Once the key metric(s) are defined and tested, it’s time to start a journey of evolving them, by creating a systematic way to collect and process the information, and by enriching the core metric(s) with additional information (e.g performance, location, date/time, behavior).
The metric(s) should not be static, and should evolve according to business objectives, additional insights gained during time or any other reason that would bring clearer visibility about unit economics; this could imply changing the definition of the key metric(s), creating new ones, or even stop tracking.
Delaying this workstream has some additional downsizes, such as potential loss of revenue margin due to higher cloud-related costs, hide real cost of running a system in cloud, demotivation of the teams (e.g. business teams don’t understand the costs, engineers won’t be seeing a direct impact on cost reductions, finance teams will see an invoice getting bigger and bigger).
Oftentimes, Unit Economics starts with sales and marketing to better understand cost per customer, cost of customer acquisition or cost of customer retention, using profit and loss numbers like revenue, COGS, or expenses as part of the Unit Economics calculations. Cloud Unit Economics uses cloud infrastructure unit cost as part of the value measurement calculation.
Building a sustainable Cloud Unit Economics practice starts with a strong unit cost model. Seek out people in your organization who are already thinking about or doing it at some level, even if not in the area of cloud spend. Enlist their support to build momentum for this important work. Courage is required; don’t be afraid of publishing a draft version of a model that has deficiencies. Sharing work early and widely is important to obtaining the feedback necessary to improve future iterations.
Planning should start as early as possible to identify the metric or metrics needed to collect meaningful data. This may give direction to engineering teams on the necessary data points to be collected later. Collecting and processing the data should happen as customers start onboarding a system.
In the beginning, the most important thing is to get started! With your first unit cost metric identified and the data necessary to calculate it flowing, be prepared to learn a few new things about your system and its use. Preparing the data and sharing those insights can be a powerful way to build support and encourage your organization to more broadly incorporate unit cost metrics into your cloud operations.
With your first metric under your belt, use the Cloud Unit Economics maturity model as a guide to planning your next steps and achieving more impactful use and adoption.
The path you take will ultimately be dependent on the architecture of your organization. During the crawl phase of adopting Cloud Unit Economics, it is best to start with metrics that can be supported by existing data sources such as logs, data warehouses, or APM platforms.
Cost per-customer (or cost-per-tenant) is a common goal that can typically be applied to most organizations and is often a good metric to start with. Using the maturity model as a guide, you could achieve cost-per-customer using the following process:
Depending on the complexity of the application, this may also be done in multiple phases, where some cloud costs are handled initially as “direct” and others “shared.”
This could include things like Datadog, ServiceNow, or PagerDuty or BYOL (Bring Your Own License) like Windows or SQL Server which are run on cloud infrastructure. Once you start bringing in SaaS tools or Licenses, you may need to work with the team responsible for that product to understand the KPIs they care about and how they quantify time spent such as the SAM or ITAM team.
This is bringing in costs like labor or even on-premise costs that support a particular product or service. The run phase is typically when a firm starts collecting more than one metric for various parts of a complex system getting more granular over time.
Above is courtesy of Lucas Paratore, FinOps Pro Essay, and Cloud FinOps, Fuller & Storment, 2022.
In other situations, engineering might play a more central role in your FinOps organization, and you can leverage engineering time to produce the necessary metrics. This might be where organizations start their journey, or it might be where you ultimately end up. Regardless of the resources you have at your disposal, start small and focus on clear metrics that will be tangible to all stakeholders.
Through all of this, the centralized function of FinOps should be apparent: the FinOps team should be responsible for maintaining the Cloud Unit Metrics repository and be capable of clearly articulating their business value. Without it, a company can end up with “one metric to rule them all” or a bunch of clashing metrics.
Unit Economics typically will fall into several categories that follow FinOps personas. If you aren’t familiar with FinOps personas involved with building and operating your practice, catch up on the personas page.
|Executives||Product Owner||Engineering and Operations||Finance/Procurement||FinOps|
|INPUT||A CTO/ CIO / CFO should own the initiative of Unit Economics and determine scope as it relates to coverage of Products||VP of Product / Product Owners should collaborate with Finance to determine key product metrics||VP Engineer collaborate with Product Owners define input requirements for metrics to best determine how to collect metric data from systems||Finance should collaborates with Product Owners to determine key product metrics||FinOps should be aware of executive scope and identify gaps in cost allocation alignment to strategy|
|OUTPUT||Actioning on business decisions as a result of cost metric data||Define frequency of reviewing unit cost and determine benchmark thresholds||Support solutioning automation and identify blockers to outputting metrics||Actioning on business decisions as a result of cost metric data||Integrate cost allocation with cost metrics|
NOTE: This table is best viewed on a wide viewport, like a desktop or tablet.
It is important to clearly define what is being measured. For example, let’s say you are storing customer data so you decide to measure the cost-per-GB. Then, one of your engineers figures out a new way to further compress the data, cutting your storage needs by about 30 percent.
In this scenario, your cost-per-GB does not change even though your storage costs have decreased. Instead, it would be more meaningful to measure something like a cost-per-stored-item (whatever that may be). Using a cost-per-stored-item as a unit of measure in this same scenario would show a 30 percent reduction because you are storing the same amount of data with fewer GBs of storage.
Collaborating with all of the necessary organizational stakeholders to first determine what drives business value is essential to getting this part right.
Defining and agreeing on the type of costs to report (e.g.: include or not discounts, negotiated rates, optimizations, shared costs, support, any other operational related cost)
Once you’ve decided what to measure, it is imperative that you clearly delineate what financial inputs make up your unit costs.
Is your organization receiving an enterprise discount? Do you have a private pricing agreement with one of your vendors? Are you receiving bulk discounts on licensing costs? Do you amortize upfront payments for commitments? Regardless of which stage your organization is at in the crawl-walk-run cycle, it is important to consider these types of questions when measuring and reporting your unit costs.
Expecting perfection when starting out is a huge barrier to success. Don’t let perfect be the enemy of good. Most often, a single metric can provide better information than a “peanut butter spread” allocation methodology for a product or service. A single metric based on usage is always better than taking total cloud spend and dividing it by a KPI like total number of customers. The unit metric has the ability to provide more nuanced information, like which customer is driving the most spend based on usage. A single metric may not be perfect, but it is a great place to start on your journey toward Cost-per-X. Integrate by observing your first unit metric and making an informed decision about whether there is a need for another metric.
The law of diminishing returns for investing in new metrics can happen quickly. Again, good enough is oftentimes substantially easier to achieve than perfection. Some firms may need several metrics to get to a solid Cost-Per-X while another firm might need only one. Overcomplicating at the beginning will prevent you from starting and getting a return on investment for your efforts quickly.
As part of one of the Working Group’s sprint deliverables, we created a slideshow, or pitch deck, that helps FinOps practitioners define cloud unit economics in a brief format and build the case for it within their organization. It’s open for all to use and the latest version can be found here.
Our WG hopes that by the time you read this, you have a better understanding of Cloud Unit Economics. It’s the start of a longer journey toward the practical application of unit economics best practices and building a methodology to quantify the associated cost and usage metrics of elasticity.
There’s still much more to improve throughout this document as we socialize it with the rest of the community. Get in touch on our Slack channel to:
The FinOps Foundation extends a huge thank you to the members of this Working Group that broke ground on this documentation:
Lastly, a big thank you to the FinOps Foundation support team for helping us bring our work to life: Ashley Hromatko (Staff Sponsor), Samantha White (Program Management), Tom Sharpe (Design), and Andrew Nhem (Content).