We have a term we like to use when we meet CFOs who have just gotten their biggest AWS bill ever: bill shock.
Bill shock is when finance suddenly rings the alarm that the bill is “too high” and gets everyone scrambling to explain what they’re spending money on. It often happens when the bill reaches a new milestone (the first million, ten million, or hundred million) or growth trajectory (it doubled in a quarter!?).
The problem with bill shock is that it can be highly disruptive.
Engineers are pulled off their roadmaps to investigate costs. Optimization projects are kicked off. Innovation slows as teams become hesitant to spend at the same rapid clip as before.
Then, once a significant amount of money has been saved, the innovation resumes – until next time.
We call this: the vicious cycle of cloud cost billing.
However, the problem is that CFOs often lack context. They see a large number, without visibility into the business initiatives driving it.
With more granularity and context, CFOs can be less reactive, ask better questions, and cause less disruption. Here are five questions a CFO should ask themselves when evaluating their organization’s cloud cost.
5 Questions A CFO Should Ask When Evaluating Cloud Spend
1. Is the cost really too high?
Understandably, a large AWS bill will provoke a feeling of sticker shock for a CFO who wants to make sure cloud spend is under control. But sometimes, upon further examination, the CFO may find that an AWS bill of that size is actually normal for a business at their company’s level.
The best way to put cloud cost into perspective is unit cost. To start, pick a metric that represents your business, like cost per customer, user, API call, message sent — whatever aligns with the growth of your business. Partner with engineering to track unit cost over time. This will give you a shared understanding of spend in context, help engineering prioritize optimization only when it’s impactful, and even make it easier to predict how cost will change as you grow.
2. Which costs are fixed, and which scale up when we add a new customer or as users interact with our products?
If you are at an earlier stage company, or maybe just the earlier stages of a newly launched product, your unit costs will naturally be high. You’ve built a product with only a few customers using it.
Work with your engineering team to understand which costs are fixed, which will scale up with each customer added, and how the economics of those costs may improve over time. This will help you control spend as you grow while creating shared goals.
3. What is our cost per customer? How does that cost differ by segment, geography, package purchased, etc.??
Similarly, it’s important to know your average cost per customer. For many companies, it’s also crucial to know the cost of your individual customers and how your margins differ for each one. It’s not uncommon that companies we work with are surprised to find they’re actually losing money on a few of their customers, who might be power users or have an unusually high amount of data.
Once you get to cost per customer, you can start breaking that into segments, giving you visibility into profitability of each.
For example, the way customers utilize your features can vary significantly. Perhaps you work at a social media app that markets to all age ranges, from college students to older generations. Your customers will have a completely different way of interacting with your platform and will therefore impact your costs differently. In this case, the solution to your problem may be to focus your marketing efforts on a particular demographic and spend less effort catering to others.
Similarly, if you are a B2B company and your EMEA segment profitability pales in comparison to APAC, you’ll want to investigate why and figure out how to correct it. It could be something unexpected. Maybe EMEA’s customer success team is phenomenal at driving feature adoption compared to APAC, driving up both your customer satisfaction and cost. You’ll want to consider how you could reduce cost or adjust pricing to continue driving that great customer satisfaction and profitability.
4. Which features are driving the increases in spend, and are they worth it?
Before you can make any adjustments, you have to understand which features are the primary reasons behind the cost increases.
Often, new features are well worth the higher price tag. If new upgrades mean your platform is now twice as fast, or you’ve just added a whole new section with additional features, you likely don’t want to slash spending and undo these improvements.
However, if the feature your customers hardly ever use is driving 50% of your cost, you might want to reconsider whether to sunset it or turn it off, except for the few who use it.
5. What is the opportunity cost of optimization?
Optimization isn’t free. It’s important to consider lost time, effort, money, and the features themselves before making a major change based on cloud cost alone.
Have conversations with your engineering leadership about the tradeoffs that will be made before you start demanding cost cuts. Together you can make the decision that’s best for your business.
Not Sure How To Answer These Questions? CloudZero Has The Answers
Even for the most talented CFO, cloud bills aren’t easy to itemize unless your company has a way of identifying and tracking individual costs and the returns you get on those investments. CloudZero allows you to allocate your spend and gain visibility into the opaque black box that is your cloud bill.
From greater visibility comes a greater ability to guide the company in directions that make sound financial sense.
With the in-depth cost intelligence provided by CloudZero, your company’s CFO can have an open line of communication with engineering about the features being used, the costs of those features, and whether there may be room for improvement.
Don’t start arbitrarily slashing your spending just to arrive at a lower AWS bill. 
to understand which factors truly affect your costs and revenue.
The Cloud Cost Playbook
The step-by-step guide to cost maturity
