Evaluate Your Cloud Cost Assessment Results

No matter where you are in your cloud cost journey, this report will help you analyze your results and see where you can improve.

Throughout your journey, understanding unit cost will ultimately be your end goal and should be your guide as you become more mature when it comes to measuring and thinking about cloud spend.

1. Which Of The Following Best Describes Your Cost Optimization Progress?

If you answered: We pay our cloud bill but have little to no idea what, why, and how we’re spending

Optimizing your cloud cost can be overwhelming — and when you’re just getting started, it can be difficult to know where to begin. 

A good place to start is establishing basic cost visibility, so you can understand where your cloud spend is going. 

For example, instead of simply viewing the amount spent on services like Amazon EC2 or S3 —  start looking at how much product features cost or which development teams are responsible for driving which costs. Your objective here is to understand your costs beyond one large number, not to achieve everything at once. We recommend you start by picking a single dimension — like product features or teams — and work toward organizing your spend in one way before you move onto others.

Here are a few ways you can start to organize and allocate your spend.

Tagging

Tagging is one of the primary methods to organize and allocate cloud cost — and is a good place to start. However, it’s not a silver bullet and can often be a barrier to achieve visibility, until you’re able to channel some resources at getting everything tagged. 

These resources can help with tagging:

Segmentation of accounts

Another way you can get visibility is working on segmentation of different accounts. This will help you understand which teams are building what. 

Now that you have some basic visibility you can move onto other priorities, like starting to eliminate waste.

If you answered: We have some cost insight and are actively working on eliminating waste (or are choosing to ignore it for now)

There are many ways to approach cloud cost waste. One way to view it is in two categories: low hanging-fruit and architectural waste. 

Low hanging fruit is simple cost optimization wins that you can employ without having to rebuild your software. These include things like switching off extra CloudTrails or optimizing NAT Gateway.

On the other hand, architectural waste is inefficiencies that are built into how your software is architected — and thus will likely require more thought, effort, and planning in order to fix them.  

a bit more thought, effort, and planning. However, they may have more impact in the long run as you look to efficiently scale your business.

We recommend you start with the low hanging fruit, by performing a cost assessment (or request a free one here).

Then, once you’ve made some quick wins, move on to an assessment of your architecture — you can look to the FinOps community for help, work with a cost intelligence team, or work with your cloud provider for assistance.

The important part when it comes to architectural waste is that you treat it like any other kind of technical debt — there will always be tradeoffs between new innovation and optimization. Sometimes it may make sense to keep the inefficient architecture while you churn out new features and other times it may make sense to take some engineering resources to address it. 

Either way, waste assessment and optimization should become an ongoing discussion. In doing so, you will begin to build trust with those teams and that’s the beginning of an effective, emerging FinOps practice/program.

Here are some cost optimization resources you may find helpful:

If you answered: We have employed basic cost optimization best practices and are currently working on connecting engineering activity to costs.

At this point, you likely have stopped spiraling costs and may have a solid understanding of where and how cloud spend is organized across your various teams, projects, products, and features. As a cost leader, you may also have new teams and/or projects looking for your advice.

Now is an opportunity to start looking at all of your systems and start to think about what your costs are as they relate to the gross margins of your company (e.g., cost per product, cost per feature, cost per team, etc.) and use that to prioritize what cost decisions to make next.

You can also spend time with finance to understand the revenue associated with these products and features. 

Use this insight to think about how you can work with your engineering teams that own those existing features to make improvements. Or you may decide it doesn’t make sense to make certain improvements because although you may see waste, it may not be worth the opportunity cost. But, you will have the data to back this up and be able to decide your best course of action.

You can keep these possible improvements in mind to use as a strategic weapon in the future (e.g., if you ever have margin pressure, you want to roll out cheaper prices, etc.). 

Helpful resources:

If you answered: We have employed the basics, connected engineering activity to cost, and now engineers can see the cost impact of their work. We are now trying to connect customer activity to costs.

This stage is all about empowering engineering teams to make informed cost-aware engineering decisions without you (the cost leader). Here, you will become more of a consultant and be able to scale your activities by enabling engineers to see the efficiency of their software (i.e., the cost impact of their work).

Engineers work best in a culture of autonomy — and when given the right data, they make decisions in the best interest of the business. That means you need to put cost into perspective so they can take action.

One way to do this is by setting budgets based on dimensions (like product features) and giving engineers cost visibility around the dimensions you set. This can be useful to control costs while developing a new product.

Another way to do this is by tracking engineering activies against unit cost metrics (e.g., average cost of X feature per customer onboarded). If your business is growing, costs should go up. So just telling engineers to “spend less” isn’t exactly useful. Having visibility into your unit costs gives you the insight you need to ensure cost is scaling in a healthy way as your business grows. 

Helpful resources:

If you answered: We have eliminated most of the waste in our environment and are now focusing on unit economics.

Congrats! You’re far along in your cloud cost journey. However, cloud cost management and optimization is not a one-time event. 

You will continue to use unit economics (e.g., cost per customer, cost per product, cost per feature, etc.) as your guide to improving your systems and increasing company profitability.

At this point, you will also want to continue to think about how you can empower the rest of your business and feed cost data to the other teams in your organization. You are no longer simply thinking about cost-cutting, but rather how you can a build profitable business.

2. Have You Employed Any Of The Following Traditional Cost Optimization Techniques Yet?

Amazon Savings Plans

This flexible pricing model offers lower prices than On-Demand pricing on AWS. You need to commit to a particular usage plan (charged on a $/hour basis) for a one or three-year term. 

Learn more about the different types of AWS Savings Plans here.   

Spot Instances

These specialized instances enable users to take advantage of AWS idle capacity and save up to 90% compared to using On-Demand Instances. However, Spot Instances have several significant limitations. Among them are prices, availability, and regions that apply. 

Find out more in our complete Spot Instances guide, including proven tips on when to use them.         

Reserved Instances

You can get a billing discount on AWS On-Demand Instances if you commit to using them for a longer time — one or three years. If you expect a predictable amount of usage on AWS, using Reserved Instances can help lower your cost per hour on AWS compared to using On-Demand Instances. Both options use the same compute configuration and options. 

Learn more about AWS Reserved Instances in this in-depth guide.     

On-Demand Instances

If your workload is irregular or short-term, these types of instances are ideal. You can launch, hibernate, reboot, or terminate On-Demand Instances at any time. In addition, you can purchase them quickly and without a long-term contract when you need extra computing power to support bursts of cloud activity. 

You pay for their computing capacity per second they are in use. Once your workload tapers off, you can terminate this instance type to save money.     

Learn more about when to use On-Demand Instances here.

Rightsizing Instances

Sizing AWS instances involves aligning their type and size with a workload’s performance and capacity requirements at the lowest cost. AWS rightsizing is an ongoing cost-optimization best practice for most companies since their computing needs change as they grow. 

As long as you do it properly, you can adjust your AWS resources based on your needs to prevent under- or over-provisioning resources, which leads to performance throttling and resource wastage, respectively. 

Learn more about AWS rightsizing best practices here.   

Cost Anomaly Alerts

Keeping track of and allocating costs accurately becomes nearly impossible as companies grow and migrate more infrastructure to the public cloud. The aim of cost anomaly alerts is to provide the people who oversee a company’s AWS infrastructure with timely notifications of potential cost overruns. 

Explore how cost anomaly detection and alerting works in AWS here. We’ve included a solution that is more accurate, timelier, and less noisy than AWS. Or, learn how to enable AWS billing alerts step-by-step. 

3. If Someone Were To Start An EC2 Instance That Does Nothing And Then Forgets About It, How Long Until It Gets Turned Off?

Once you launch an EC2 instance, it does not terminate until you end it. This can become quite costly as AWS bills EC2 instances per hour, whether they are active or idle. Additionally, with AWS Auto Scaling, instances can also continue to scale until you stop or limit them.

If you’re a small startup, you can probably terminate an instance in a week or less. For large enterprises, though, terminating an EC2 instance within a year (if ever) are likely more true — resulting in unnecessary wasted spend. 

While there’s no right or wrong answer to how long you keep your instances running, asking yourself this question can help you start thinking about your processes and whether they need improvement.

Smaller companies can address this by simply reminding engineers to check this on a daily basis. For larger organizations, or as you begin to scale and your infrastructure becomes more complex, governance policies and automation will be a better solution to this problem.

Here are some resources that can help with governance and automation:

4. What State Is Your Cloud Tagging In?

Tagging offers a number of challenges to cost visibility. To name just a few:

Yet, tagging doesn’t need to act as a barrier to cost insight. 

For smaller companies with relatively fresh infrastructure, it can be a lot less daunting to create a tagging policy or go back and edit tags where needed. If this is you, you should look to create a tagging policy as soon as possible.

However, larger companies can have near “nightmare-like” complexity and would have to take a different approach to go back and tag things properly to gain visibility. The truth is, though, at this scale, a tagging policy likely isn’t going to solve all your problems. You might want to start looking to a third-party.      

Tagging can often feel like a losing proposition. At some point, you’ll likely outgrow it — and when you do, you will need a system that can move faster than your software development lifecycle. When this becomes the case, you’ll be better off using a platform that doesn’t rely on tagging to provide you with accurate, comprehensive, and actionable cost intelligence.

We call this CloudZero Dimensions. Here’s how you can break through the tag barrier with Dimensions — and discover a better way to organize cloud spend.

Helpful tagging and cost allocation resources:

5. What Cost Tools Do You Currently Use?

Cloud cost tools help you manage costs and identify cost optimization opportunities — and can even help you unlock unit economic and unit cost metrics.

Yet, most traditional cloud cost management tools are manual, clunky, and inaccurate — and don’t provide the cost insight you need to make informed decisions that will ensure profitability for your business.

Many companies rely on AWS’ native cost tools. Yet, these are often insufficient. For example, they fail to organize costs into meaningful business metrics important for understanding unit economics, such as cost per customer, cost per team, cost per project, or cost per feature. 

If you do not have this kind of cost visibility, you may have trouble making important decisions, such as how to price your products to cover your COGS. 

Traditional cloud cost management tools like CloudHealth and CloudTrail also rely heavily on tagging, do not generate cost reports in a language both finance and engineering can understand, and have difficulty accurately tracking costs in some environments, such as containerized environments, untagged and shared resources, as well as Kubernetes.  

This is where a cloud cost intelligence platform can help. CloudZero meets you where you are in your tagging strategy — providing immediate visibility whether your tags are perfect, or a total mess. This means you’ll no longer have to rely on tagging as a means of gaining cost visibility — all the while gaining insight into important unit cost metrics (like cost per customer or cost per feature) that will help your business make informed decisions to increase profitability.    

Helpful resources:

6. Measuring All Of These Metrics Are Important. Which Do You Currently Measure Today?

Here’s why each of these metrics are important to continuously measure and follow:

Unit cost (cost per transaction, message, order, etc.)

While building stable, high-quality products is important for success, it’s equally as important that those products are economically viable. Unit cost is a great way to track how costs are trending in the context of your business.

This varies based on your company, but can include cost per customer, feature, product, transaction, message, order — or whatever other metrics meaningfully align to your business model. It’s important to understand the unit metrics that matter to you most and how they align to your cloud costs so your team can make engineering decisions that ensure profitability.

Cost of products, features, and dev teams

Cost of products, features, and dev teams help show how much you spend on supporting various cost centers in your organization. 

Cost per customer

Cost per customer represents how much you spend to support each of your customers. With this insight, you’ll know who your most expensive or least profitable customers are so that you can review your pricing with them — or decide if you need to change your pricing model.  

In addition, you can learn what resources, tools, and features they use the most or least, which will help you optimize your platform accordingly.

Cost of goods sold (COGS)

Cost of goods sold (COGS) is a measure of how much your SaaS company spends on serving its customers. The following are examples of SaaS COGS:

The higher your COGS, the lower your profit margin will likely be, so it’s important to keep this metric as low as possible. 

It’s common for SaaS companies to over-report their costs of goods sold because they are unsure of what metrics they should include. Others confuse operating expenses (OPEX) with the cost of goods sold (COGS), which has negative implications that could reduce their share price. 

Finding ways to reduce your COGS is often one of the most effective ways to improve profit margins and potentially lower prices.

Learn more about calculating SaaS COGS here.   

Gross margin

Gross margin is the difference between a SaaS company’s revenue from subscriptions sales compared to the direct costs of developing, distributing, running, and supporting that software (COGS). 

Profit margin differs from gross margin in that gross margin indicates the amount an organization must spend on each additional unit of goods or services to increase revenue. In contrast, profit margin simply compares expenses and revenues

Learn how to calculate SaaS gross margin here.

7. What Level Of Cost Visibility Does Your Engineering Team Have?

Every engineering decision is a buying decision. With cultural trends like “you build it, you run it” and “shift left” increasingly becoming the norm, it makes sense to treat cost as a first-class metric — rather than an afterthought. 

When engineers know how much things costs and can see the cost impact of their work, they can make better decisions that result in more cost-effective software and increased profitability.

Therefore, your organization should look to encourage visibility and provide engineering with asolution that shows them how their activities affect costs. 

Helpful resources:

8. What Level Of Cost Visibility Does Your Finance Team Have?

Finance and engineering often speak a different “language” when it comes to cloud spend. Engineering wants to know how product features affect costs, but finance is more interested in cost per customer and gross margin.

To make sure finance has the cost insight they need to make informed decisions, you should look to put cost into a context they understand and care about. If you’re defining costs to finance in a way that requires deep technical knowledge, you likely won’t be as effective as you can be. 

Using a solution, like CloudZero, can help teams connects technical decisions to business KPIs through unit economics that will help finance uncover cost metrics they care about (like cost per customer, gross margin, etc.).

See why finance teams love CloudZero here.

9. How Often Do Your Engineering And Finance Teams Collaborate And Report On Cost?

When there is a disconnect between engineering and finance, trying to figure out where your cloud spend is going can be frustrating. Ultimately, your teams should collaborate on cost as often as possible so you can create a real-time feedback loop.

To do this, you should look to establish a single source of truth that gives engineering and finance the cost metrics they need to make informed decisions. These can include COGS, cost per product, cost per feature, cost per customer, or any other cost metrics your organization deems ​​crucial to its cost visibility.

Check out these five tactical ways to align finance and engineering.

10. Do You Feel You Can Effectively Plan, Budget, And Forecast Your Cloud Budget?

You are not alone if budgeting and forecasting your cloud spend is a challenge. Cloud-native technologies like microservices, containers, Kubernetes, shared costs, multi-tenant infrastructure, and untaggable resources all make it difficult to properly allocate spend and thus be able to effectively forecast your costs.

If you’re having trouble planning or budgeting, it’s likely a good sign that you have not allocated spend in these so-called “danger zones”.

Additionally, not being able to properly forecast may be a symptom of an engineering team that is highly volatile in what they’re building. For example, you should be able to understand how much of your spend is driven by cost anomalies and mistakes. 

These issues can all be addressed through proper cost allocation and effective cost visibility. These resources can help:

11. Do You Have Cost Visibility Into The Following?

Kubernetes, containerized costs, shared costs, and multi-tenants costs all present challenges to organizations trying to make sense of their cloud spend. 

Traditionally, all of these areas are difficult to allocate and align to business metrics you care about. Ultimately, your cost visibility will decrease if you’re not able to fully allocate these costs.

Here’s a deeper look at how to address each:

Containerized and Kubernetes costs

Containerized apps and Kubernetes can mask key cost metrics. Due to the complexity of these systems, which integrate cost, storage, networking, data transfer, monitoring tools, etc., it is difficult to track the constantly changing data as it moves through the system and assign various cost metrics to their correct sources accurately. 

Here are some helpful resources if you’re struggling with allocating Kubernetes costs:

Shared and Multi-tenant costs

Customers of a multi-tenancy architecture share cloud resources and utilize economies of scale to reduce cost per tenant. Yet, the cost data such environments generate rarely reveal which tenants, where, and how they utilized the cloud service. Many cost tools struggle to de-aggregate cost data and map it to the proper cost center or unit cost. 

Even so, it is never too soon to measure your costs per tenant, such as how much you spend on enterprise customers versus small businesses. Without this visibility, it is also challenging to know which tenants access your services, how often, and when, so you can prioritize your cloud resources accordingly to improve tenants’ experience. 

Here are some helpful resources if you’re struggling with allocating shared and/or multi-tenant costs:  

Untagged and untaggable costs

In some cases, it’s impossible to tag resources successfully, at least if you use a traditional cloud cost management tool. Microservices are one example. 

Using a cost intelligence platform such as CloudZero, you can go beyond AWS Cost and Usage reports, over-reliance on messy tags, and traditional cost management by using a cost solution that acts as an observability tool to correlate infrastructure costs. 

Here are also some additional resources you may find helpful when it comes to tagging and cost allocation: