Cloud technologies have changed software development and deployment by removing the burden of infrastructure operations. Nowadays, you don’t have to build your own data centers and maintain them by installing operating systems and security patches. Instead, you can provision and consume the cloud providers’ resources and deploy your applications on their infrastructure. At the end of the month, cloud providers send a bill based on your resource consumption. It should be simple, yes?
Yet, when you check your monthly bill and see what you have consumed in terms of cloud services, does your bill reveal what you have actually used for your business operations? This article will focus on the fundamental gap between what you’re paying for and what you’re actually interested in.
Your Cloud Bill: Its Lack of Clarity
Cloud bills are similar to electricity bills in that they are both sent by a service provider and you pay a monthly bill based on your consumption. The problem with your cloud bill is that they bill you for the Unit of Economics that mattered to them and not to you.
Cloud bills are usually itemized based on the services offered by the cloud provider. For instance, if you use AWS, you will see the following items on your bill:
Costs for data services, such as Snowflake, based on Snowflake credits
Costs for database services, such as Amazon RDS or DynamoDB, based on the size of your database engines
While multiple companies run on the same cloud provider, no two companies apply identical Units of Economics. In other words, each company needs to work with its own business models, including revenues and costs based on specific units. These units can be essential entities that create value for the company. While running on a cloud provider, units are also dependent on cloud resources and the bill. That’s why you need to understand the relationship between your company’s Unit of Economics and cloud bills to improve scalability and growth.
Hidden Costs vs. What You Actually Need
When using a cloud provider, you deploy your applications and consume cloud services according to your business operations.
Consider DB-services, a database company offering clients fast and scalable databases as a service. When DB-services have a new customer, they need to create new disks on the cloud to save the database files and VMs for running database servers. If a client wants larger database tables, DB-services need to switch to larger disks and VMs. They also need to add new instances for new customers or delete the previous ones as customers churn.
Notice that all actions in this example, and that you take in the cloud, are directly related to the business operations. But, these do not correlate well with charges related to consuming hours, data volumes, or data storage credits – as you can’t reflect these back to the business operations.
There are two critical points to understand when it comes to your cloud bill. First, the billing unit is not the same as the Unit of Economics that you actually apply to your business. Like electricity, which is billed according to kilowatt-hour (kWh), your cloud bill shows the unit costs according to metrics that matter to the cloud providers themselves. Second, billing statements are not granular enough to allow you to genuinely understand the fees associated with supporting your application/s.
For instance, you use:
Amazon EC2 instances as computation nodes for pods in your Kubernetes cluster
Elasticsearch for indexing customer reviews
Snowflake for querying your data lakes
Amazon RDS, or any other database service, to run queries
Amazon S3 for storing your files and folders
Yet, your services do not map directly to these resources – reducing your cost observability. Fortunately, there are ways to calculate what you consume using the information in your cloud bill. The simplest method is tagging the resources based on their projects, owners, and other metadata. However, if you use a dynamic orchestrator like Kubernetes, it is not feasible to tag every single Kubernetes resource in the cluster. We discussed the challenges of Kubernetes cost monitoring and our solutions more deeply in previous articles.
From a business perspective, you have to focus on what you are consuming in the cloud to calculate and manage your unit costs. In addition, running a company on a cloud provider is a long-term commitment, which means managing cloud bills plays a significant role in your revenue stream, such as calculating annual recurring revenue (ARR).
Finout: The Cost Observability Platform
Allocating the cost of the items on your cloud bill is a highly complex task, whether you’re doing it manually, in spreadsheets, or with AWS Cost and Usage Reports. It requires consolidating all the available data from your cloud provider(s) into one mega bill. It doesn’t make sense to use the unit costs created by the cloud provider – their Unit of Economics. Instead, you’ll need to create your own Unit of Economics and make it meaningful for your business operations.
Finout offers a cloud-native cost observability platform to solve all the problems related to the hidden costs in your cloud bills. We focus on making your cloud bills easier to understand:
We present all costs from multiple cloud providers and platforms in a single place
There is no coding required with SDKs, APIs, or installation of agents for integration
We offer out-of-the-box calculations, from absolute cost to cost per customer
Finout integrates data from cloud centers and business data from observability platforms to correlate and analyze your costs. It reveals what is hidden in your cloud bills and helps you calculate cost per customer, feature, or business unit, and helps you reduce cost.
Join the FinOps revolution by signing up for our free trial today. Interested to learn more about how to manage AWS cloud costs? Check out our previous article.
"Whether you’re a part of a team with an established FinOps practice, or are building up the discipline, everyone can relate to the challenges of mapping cloud utilization cost to their drivers one-to-one." – FinOps Foundation