This content was provided as a Professional Contribution through the FinOps Certified Professional program.
Unit Economics Playbook: Calculate the Unit Cost
Summary: Use Unit Economics to bridge the gap between technical consumption and business metrics (e.g., cost per ticket sold or cost per API call). Establish a prerequisite of strict cost allocation (tagging) before defining a business metric that represents actual value rather than simple top-line revenue. Once defined, FinOps Practitioners can automate the calculation—such as using serverless functions to divide cloud billing data by database transaction counts—and surface this ratio on near-real-time dashboards. Unit metrics help engineering and business owners can quickly distinguish between a legitimate spike driven by customer growth versus a costly architecture anomaly that requires remediation.
Calculating technology unit costs enables engineering to better align its initiatives and investments with business value. Use the following guidance to learn practical steps for defining metrics, automating tracking, and investigating anomalies. Here are high-level principles to keep in mind before proceeding:
- Focus on Business Alignment: Puts the focus on business. Everything else is just noise. For example, if the cloud unit cost increased without a tangible value for the business, such as meeting SLAs or performance, then such resources should be reverted (i.e., removed or shut down).
- Measuring Business Performance: Calculate the business cost of developing a service, or as little as a feature of that service.
- Benchmarking Performance of Teams: Unit cost could be used as a constant metric to measure how teams are performing and areas that need to be improved.
- Alert to Anomalies: Differentiate between business demand spikes vs cloud resource misuse. A simple value changing quickly could be a first indicator of a serious anomaly. Was it that due to a “Black Friday sales” or “an engineer forgot a cluster of databases running over the weekend.”
Steps to Calculate the Unit Costs
(1) Define the scope and granularity of the unit.
As mentioned before, understanding the motivation of why we want to measure the unit costs will help us to define the scope of the unit. The scope of the unit cost could be:
- a set of tagged resources used to develop a feature
- The total cost of an account/subscription/project that allocates costs of application environment (dev, staging or prod environments)
- All the costs associated with a given application (multiple accounts)
NOTE: Cost allocation is a required prerequisite to calculate the unit cost. Without allocating or attributing costs of resource to their respective teams, applications or even application features, we will not be able to calculate the unit costs.
(2) Define the business metric of measurement.
For example, are these resources running a business operation part of a purchase order of an item in an ECommerce system? Are they running an ELT job for analytics of business needs? Whichever the case we define, this value these resource provide will be our business metric.
NOTE: Do not use revenue as a business metric of measurement, because some costs might not yield revenue but still provide a business value. For example, a freemium subscription might not yield revenue for a trial period of time, while the number of customers / subscriptions might be a more suitable indicator of business growth.
● For the total cost of ownership of public-facing application for an airline booking system, the metric could be the price per ticket (seat) per mile traveled.
● For calculating the unit cost of a small feature in business application providing users with notification when an action is done (e.g., sending an email when user is created), the metric could be cost per email sent.
● For a company providing a SaaS platform to provide a certain service, the unit cost could be the total cloud cost of a subscription.
(3) Automate and show the unit cost.
Unit costs will only make sense if they are delivered as a live metric calculated at near real-time. Rely on automations to calculate the metric and display the results as a showback dashboard to help teams take accountability for their costs, and use gamification to motivate them to elevate the business value by lowering the production unit cost.
(4) React to the unit cost changes.
Now that we have a clear showback of the unit cost, we have to monitor it to see if remains the same, increases or decreases.
If the unit remains constant or decrease, this is a good sign. However, if it increases, then the business owner / service owner has to ask about the reasons. Was it due to an added business value, or was it a misuse of cloud resources? Either ways, it is good to consider the governance of resources accordingly to push the unit cost down.
- Define the three to five services attributing up to 80% of the unit costs (e.g., storage, compute, databases, etc.)
- Tweak the governance specifically on non-production environments to align to a business value (e.g., change the class, family, or specifications of resources to less-expensive versions if they don’t bring an added business value)
- Improve iteratively and include more services as the maturity of FinOps improves
A Practical Guide to Calculate Unit Costs
As an example, let us calculate the unit cost of the public-facing application that books tickets for seats in a cinema.
The Business Owner / Service Owner: Accountable
The Lead Engineer: Consulted
(1) Define the scope and granularity of the unit.
In this case, it could be the total cost of the application, including the dev/staging environments for development.
(2) Define the business metric of measurement.
In this case, it could be the total number of tickets sold per month.
The Business Owner / Service Owner: Accountable
The Lead Engineer: Consulted
Finance and Leadership: Informed
(3) Automate and showback the unit cost.
Assuming we are using AWS services, to calculate the unit cost in near real-time, we could create a simple serverless application using simple cloud functions (e.g., lambdas) to retrieve:
- A function that reads the total cost of the application using aws ce get-cost-and-usage CLI Command, or similar AWS API calls.
- A function to retrieve the total number of tickets sold from a given customers database.
- An orchestration service (e.g., step functions) that will read both values from the functions above and divide them: i.e., total cost per month / number of tickets. This step function will run at regular intervals (e.g., 15 minutes) using a cron job to keep track of the latest updates.
- Visualization of the value in a dashboard (e.g., Power BI Dashboard), and give access of this dashboard to the relevant personas (e.g., the DevOps team)
(4) React to the unit cost changes.
Now the service owner and the engineering team(s) should monitor the changes on daily and watch out for spikes/ anomalies or permanent increase in the unit cost.
If that is the case, the desired outcome is to use the FinOps Capability (Policy & Governance) to improve the alignment of resources to the business value it provides.
