SaveOn.cloud

Your cloud bill needs to be broken down in a way that is meaningful to your organization.

This article talks about what a meaningful cost break-down looks like, why it is important, and how to define this for your organization using the concept of Cost Centers.

This article will not talk about the technical implementation of attributing (labeling, et al) costs; that will be covered in a future article.

Our Starting Point

Cloud platforms itemize their bill by product.

This quickly becomes insufficient for cost management as use of the cloud platform increases.

An example we will build on is the following:

The key element missing from this break-down is business relevance. We cannot expect the cloud provider to know this; we have to build this into how we use the platform.

Before we can establish a method for adding business relevance to our cost breaking down it is important to understand why we are doing it. How will organization and cost-optimization efforts benefit?

Complexity Increases

If we are hosting two or more services the cloud provider bill is no longer a sufficient cost break-down.

We need to break the bill down into meaningful groups. When we do this we link cost of the resources consumed to the business value they provide.

We will understand what our individual services costs to host. This understanding is key both in 1) preventing costs from getting out of control and 2) facilitating cost-optimization exercises.

Consider, for example, where we have two products we are hosting: Waffle Iron and Shirt Press.

Separating the cloud expense by product would look like the following:

This gives a better picture of what value the cloud expense brings to the organization.

It’s Not Perfect

In reality, our break-down will not be a clean split.

We probably have resources whose purpose is to support both Waffle Iron and Shirt Press. They’re shared.

In that case, we need an additional group to allocate costs that are shared between the two services.

In this situation, the following example would be more realistic:

At larger scale, we might find we need multiple ‘shared’ groupings so that every resource has a clear home.

Value of Break-Down

Having this break-down supports decision making and cost saving efforts such as the following:

• Cost transparency can uncover lessons that can be shared between teams to help reduce costs. For example, maybe Shirt Press handles more users, data, and load than Waffle Iron does, and yet it uses significantly less Compute Engine. If true, this would be worthwhile to explore with the teams to understand why there is a discrepancy in cost.
• When planning for next year’s budget, this break-down can enable the product managers of the distinct services to provide more accurate estimates.
• Perhaps Waffle Iron is a legacy system that needs to be re-factored. Having hard costs data about cost to maintain the system is important in developing a business case for the replacement project.
• In seeking to make the biggest impact on cost reductions, it is important to know where money is going so we can prioritize cost-saving efforts.

Now that we see how this break-down will be used, how do we define a meaningful break-down and grouping of costs for our organization? We do that by identifying cost centers.

Cost Centers

A Cost Center is a logical grouping of cost. A dictionary is:

A department or other unit within an organization to which costs may be charged for accounting purposes.

The first step in breaking costs down is to identify cost centers to attribute costs to. Cost centers will be where we assign resources or groups of resources for cost assignment. With good cost center definition we will be able to provide meaningful break-down of our cloud bill.

A Cost Center could encompass the costs of a business unit, department, product, service, or a major component that is a shared service.

Critical considerations for cloud cost center definition are as follows:

• One person should be identified as the owner of a cost center, and every cost center should have an owner. This person should have a full perspective on the resources consumed as well as the business value of the service.
• A catalog of Cost Centers must be maintained and made available to the organization.
• The purpose or scope of each cost center should be defined.

The generic ‘cost center’ is recommend for these groupings as opposed to more specific entity term such as ‘function’, ‘department’, or ‘product’. Many of our cost centers will map to these entities, but they will map to a variety of entity types not just one.

At larger scale, we may need to use business-unit groupings of cost centers, where each business-unit has its own catalog of cost centers.

Don’t Over-Engineer

Get started with defining the cost centers we currently need to map our current (or immanent) costs to. Don’t try to plan too far ahead, or for use-cases that haven’t materialized yet.

Collaborate

Collaboration is critical in this exercise. Do not define cost centers in a vacuum. Doing so wastes a valuable opportunity to start instilling a culture of cost-consciousness and cloud efficiency within our organization. This is an important part of this exercise.

We should include technical, product, finance, procurement, and accounting teams in the definition of cost centers.

It is important to educate these teams on what we are trying to accomplish, and why.

An organization may already have a mature cost center concept, but it may need some extending to make it suitable for classifying cloud costs. We will need to work with our accounting team so that a consistent company-wide language can be used.

A good way to collaborate is to provide an early draft a cost center catalog and share it widely. Also include a write-up about what we’re trying to accomplish. Perhaps sharing this article will help.

Allowing others to critique a draft is easier than asking them to create something from scratch. We are more likely to receive their input and engagement. If we don’t have the business and organizational perspective to propose this on our own own we must bring in an ally to help get the definition started.

As we make this useful for the broader organization we will see better engagement and support in the effort of reducing cloud expenses.

Cost Center Catalog

A catalog should be maintained of defined and approved cost centers. An example would be as follows:

Closing up

Once we have a catalog of cost centers define we have what we need to start assigning cloud costs. We’re on our way of building a strong foundation for cost management and for discovering cost saving opportunities.

The next step in cost optimization will be creating a Cloud Infrastructure Labeling Strategy based on our cost-center definition, and then assigning resources costs to our newly defined cost centers. This is done through labeling, or tagging, depending on your platform, and will be described in a future article.