On a day-to-day basis, both engineering and product management in software companies involves constant trade-offs. Everyone has a long backlog of tasks and needs to make decisions about what to prioritize on a daily, weekly, and monthly basis. Figuring out what to tackle first, what to put off for later, and what to say no to is critical both to managing daily workloads as well as to creating product roadmaps that reflect what customers want.

This month, I made the decision to join CloudZero as their new chief revenue officer — a choice I’m incredibly excited about. In the past week, a number of colleagues have asked me to share why I joined the company. After answering the question a few times, I decided to take a minute to collect my thoughts and explain why this incredible company is the next step in my career.

It’s safe to say that cost per tenant (also known as cost per customer) on AWS has been a challenging metric to obtain. Until now, your best bet has usually been to either make a best guess or build some sort of homegrown system. As of November 4, 2020, when you google “cost per tenant,” you get a few things at the top of the page. The first is a couple of blogs by AWS, where they describe an extraordinarily complex system, which you can build yourself.

Do you know how much it costs to operate your software per customer, at each pricing tier? The past six months have been highly unusual to say the least. For some companies, the disruption and shift to work from home meant 100x in usage almost overnight; for others usage completely collapsed in the same time period. These sharp swings in utilization have been disruptive to cloud unit economics. Both scenarios are risky and require extreme elasticity from the technical infrastructure.

If you’re a SaaS business — especially B2B — you know that your profitability can vary significantly from customer to customer. We all have a sense of our “expensive customers,” who use the product heavily and push things to the limit. That also means there are more profitable customers. Who are they? And how do they use the product?

At CloudZero, we talk to leadership teams at SaaS and companies every day. When it comes to individual customer profitability, the vast majority of them fall into two camps: they’re either taking their best guess — or they have no idea. Typically only the largest companies - those with the resources to dedicate a 5-10 person engineering team to calculating cost - have this level of insight. And you can be sure they yield that knowledge to their competitive advantage!

Every decision that an engineer makes in the cloud impacts cost. Yet we know that engineers aren’t cost experts, and many worry that asking them to care about cloud cost will slow them down and distract them from delivering customer value. Top cloud-native companies dedicate entire teams of engineers to build custom tools to measure unit cost and deliver cloud cost to engineering teams. But I’m guessing you don’t have eight engineers you can spare to build internal cost tools?

If you are looking to account for your container costs and understand how your AWS Kubernetes or EKS cluster spend maps onto your workloads, this guide was made for you! In this post we will walk through the steps to get up and running with CloudZero and Amazon Container Insights fast. CloudZero has integrated with Amazon CloudWatch Container Insights for its strength as a secure and automated solution for sharing container metrics within AWS.

Here at CloudZero, we’ve made some updates to our dashboard that we’re excited to share with you! I actually prefer this original definition. When you hear the word dashboard, if you’re not thinking about software, you’re probably picturing the place in a car where you have various dials and readouts for safe operation of the vehicle. But did you know what the term dashboard predates cars?

One of the mistakes organizations make related to Kubernetes costs is addressing them primarily after-the-fact, once the application is running successfully. There are certainly changes that can be made to improve efficiency once the application is running, but cost-control measures are best considered at the beginning, not middle or end, of the application lifecycle.