Finance: Why Getting Answers From Engineering About Your AWS Bill Is So Difficult

It’s no secret that AWS bills are confusing.

But it’s particularly difficult for the team who actually writes the check to Amazon for hundreds of thousands or millions of dollars — yet has never personally seen what the inside of the AWS portal looks like (and probably never will).

If you’re in finance at a software-driven company, it’s not unlikely that the number on your bill keeps growing and your engineering leaders assure you it’s being invested in new features, more scalability, onboarding additional customers — or maybe some fancy new machine learning.

They’re probably right —but it still seems so opaque.

As a finance leader, you likely care about predictability —and metrics like COGS. You want to understand which segments of customers have the highest margins, which features cost you the most to run, and how much it’s going to cost you to invest in new functionality.

So, why is it so difficult for engineering to get you the metrics you need? Why does it feel like you’re speaking different languages?

To help finance and engineering teams understand each other a little better, we decided to explain the answer to this very question —in simple, non-technical terms, so that finance (or anyone outside of engineering) can understand.

It’s Not Engineering’s Fault That AWS Bills Are So Confusing

It’s not that your engineering team doesn’t want to help you make sense of your AWS bill. In fact, they likely would if they could. However, the way the billing data is made available to them doesn’t make it easy.

Before we dive in though, let’s start with a little background on how AWS works.

AWS offers hundreds of different “services,” A service can range from compute (think “renting space on a server”) or on-demand software that can be built into an app (like speech to text functionality). These are all available in the AWS console, where engineers can access everything they need to build the software they’re working on.

Every service has its own pricing model, which is (sort of) conveniently located on this webpage. If you would like to get a sense of what your team is up against, scroll down to services and click into any of the icons. Once you do, you’ll eventually get to something that looks like this:

And that’s just one snippet, of one subset, of one service. There are hundreds of these.

Every decision an engineer makes every day has a different cost associated with it —and there isn’t really an easy way to track it.

Then, the bill shows up — and it’s often quite literally millions of lines long and looks something like this. Many line items are worth fractions of a cent — and they’re all listed by service.

To help you understand exactly why this makes things so confusing, here’s a comparison:

This would be like if you owned a bakery and you could only view a complete list of every egg, cup of flour, and teaspoon of salt you used over the last month. Meanwhile, you have no way to tell what it cost you to bake a wedding cake or chocolate chip cookie —much less whether online orders have a higher average cost than in-store.

So How Do Engineering Teams Manage?

There are a few different ways engineering teams are currently dealing with this. A simple first step is that many teams start by creating a separate AWS account for each development team or product feature, which helps them separate out some of the costs.

Then, there are cost management and optimization tools. AWS offers a pretty good free tool called AWS Cost Explorer. There are also a number of other paid platforms.

Problem 1: Tagging is a pain.

The first problem is, these tools all rely on tagging. A tag is essentially just a label you apply to an AWS resource. Engineering teams must tag every resource in AWS in order to use any of these reporting tools.

They don’t have to manually tag every single thing because there are a number of ways to automate it, but it can still be a painful process —and most companies’ tagging is at least somewhat messy or inconsistent. Add in older products or technology that was acquired and this can turn into a nightmare.

AWS Cost Explorer

But it gets more complicated.

Problem 2: Shared resources make reporting on certain metrics impossible.

While tagging can be overcome with some time and effort, there are a few much harder problems to solve. The metrics that you care about as a finance person, like cost per customer, or cost per product feature, don’t always align with the line items on the bill.

For example, many resources, like databases, are shared across different product features and customers. If you have 100 customers sharing a single database, you can’t easily tag 1/100th of your database.

Another problem is the way that applications are architected today. We won’t bore you with technical details, but there are a number of ways to build software (you probably will hear terms like containers or multi-tenant architecture) that add a new layer of complication to the shared resources problem.

For example, if your company offers software that allows people to log in (like a SaaS platform or a social media application) your customers are all sharing resources, but it’s not clear from the billing data who utilized what.

These kinds of architectures have great benefits for scale, elasticity, and operational efficiency —but can seriously convolute your billing data.

Problem 3: Investigating issues is time-consuming and difficult.

The third major problem engineering teams are up against is that while they can report on cost (with enough tagging and data manipulation), it’s very hard to investigate it. Using existing tools, they can pull different slices of data to see a variety of dimensions, but there is no way to actually connect that cost with a cause.

This means that managing cost is a time-consuming and frustrating effort — that often requires whole teams of people to do it right.

Where Does This Leave Engineering Teams?

Hopefully this gives you a better understanding of why —when you ask questions like “why is the bill so high?”, it’s not always straightforward for them to answer.

So the next time your bill is 10% higher than you expected or it takes a while to get the billing metrics you need, you can have a little empathy (and impress them as you discuss the benefits and tradeoffs of multi-tenant architecture).

CloudZero Can Help

Fortunately, CloudZero can help engineering teams make sense of cloud cost, by connecting cost with your technical architecture —helping you measure unit cost, cost per customer, cost to run different product features, and more.

Schedule a demo today (and be sure to invite someone from engineering).

Author: Cody Slingerland

Cody Slingerland, a FinOps certified practitioner, is an avid content creator with over 10 years of experience creating content for SaaS and technology companies. Cody collaborates with internal team members and subject matter experts to create expert-written content on the CloudZero blog.