How to investigate a cost anomaly in 3 steps

Your teammates are enjoying their holidays, while you’re greeted by an unexpectedly high cloud bill at the end of the month and finance breathing down your neck. 

What ended up costing more than expected? 

In a recent survey, engineers said that cloud cost issues caused disruptions to their work that lasted from a few hours per week (41%) to an entire sprint or more (11%).

But it doesn’t have to be that way.

If you use Kubernetes, here’s how you can investigate any cloud cost anomalies in three simple steps.

Step 1: Analyze your cloud bill for the last month

Cloud bill analysis is painful. Cloud providers aren’t making it easier when they charge you based on various service metrics, with cost items presented on bills that are long and hard to unpack.

To make sense of your usage and costs, look into various areas in your provider console. You can then group and report on costs by certain attributes – for example, by region or service. 

A manual cloud bill analysis is time-consuming, especially if you have to analyze more than one team using the same cloud service.

You can make your life easier here by using a third-party cost monitoring solution that gives you all the insights you need in one place (for example, the CAST AI platform has a free monitoring suite). Not to mention real-time cost data that none of the major cloud providers offer!

Step 2: Check your daily cloud cost to identify any spike

Let’s say that you have a cost monitoring tool on board. Take a look at a daily cost report outlining how much your team spends each day. A single glance may be enough to identify outliers or cost spikes in your usage or expenses.

Having this report handy every day of the month also helps to measure your burn rate. 

Also, you can check whether your current spending is compatible with your monthly budget by extrapolating your daily expenses into a monthly bill.

Step 3: Explore historical cost allocation data for anomalies

Spotted a cost item that looks higher than it should? It’s time to investigate the culprit. This is where historical cost allocation comes in.

This report is your point of departure for asking the following questions and checking specific cloud cost metrics:

1. Total cluster cost report – What is your projected monthly spend compared to last month’s spend? What is the difference between this and the previous month?
2. Allocation by workload – Are there any idle workloads that aren’t doing anything apart from burning your money?
3. Allocation by namespace – What was the distribution between the namespaces in terms of dollar spend?

By the end of this process, you’ll have the answer. You’ll know what happened last month that drove your costs up – whether it was a service left running over the weekend or a team that picked a pricy virtual machine.

By avoiding constant distraction by cost issues, you can keep your engineers happy and productive if you have access to all of these reports.

Cost monitoring is important, but it only gives you cost insights; it doesn’t reduce your cloud bill. 

The easiest way to win the real-time cost optimization game is by combining cost monitoring with optimization, which takes care of things like removing idle resources and picking VM types automatically.

I hope this helps!

Cheers,

Allen

Found this email useful? Forward it to your friends and colleagues who need more Kubernetes best practices in their lives!