AWS Cost Allocation: A Guide To Allocating Cloud Spend

Two major attractions of the cloud are the on-demand availability of services and the ability to deploy resources at the click of a button. But these alluring features also present the biggest challenges when it comes to cloud cost allocation.

Because cloud infrastructure is so flexible and scalable, cloud sprawl — the uncontrolled proliferation of an organization’s cloud instances or cloud presence — is almost inevitable.

Take Amazon Web Services (AWS), for example, which offers hundreds of products/services, each with their own on-demand pricing model. If you have tens or hundreds of engineers deploying instances of AWS products without a guiding policy or visibility into how their decisions impact operating costs, you could end up with considerable cloud costs at the end of each billing cycle. Even worse, it may be difficult to see how each team or department contributed to the cloud spend.

Understanding where your cloud spend is going in terms of cost per product, service, customer, or any other unit of interest is crucial for understanding how you can grow your margins. You should be able to answer questions like:

• How much does it cost to build and deliver a product feature?
• Which product (or services) have higher margins or lower margins?
• Which team or department is incurring the most cloud spend and why?

There are ways you can effectively allocate cloud cost so that each team, department, or unit is held accountable for the cloud resources they use. In this article, we’ll cover some best practices you can implement to increase cost visibility and manage cloud cost allocation.

Don’t have a clear understanding of your cloud spend? Sign up for a demo to see how CloudZero gives you complete visibility into your unit costs.

Cloud Cost Allocation: 3 Best Practices

1. Establish a cost structure using accounts.

On its own, your cloud infrastructure is just that — a piece of infrastructure. To start accounting for your cloud spend at a unit level, you have to put it into business context, which you can do by linking the resources you use to key business metrics.

One way to achieve this is with account segmentation — using multiple accounts to establish cloud cost structure.

Some years ago, all AWS resources owned by an organization had to be managed in one account. As resources increased, it became incredibly difficult to monitor the use of those resources. Today, Amazon allows (and encourages) the use of separate accounts as a best practice for keeping costs and resources streamlined.

We recommend creating separate accounts for each product, environment, and/or team. Segmenting accounts in this way improves visibility into your cloud costs so you can easily pinpoint how each environment, product, team, or feature is contributing to your total cloud spend.

2. Use tagging to connect key business metrics.

Another way to add business context to your cloud costs is by tagging, or categorizing your cloud resources. Tags are the main vehicle for imparting business logic onto cloud resources. Amazon introduced tags to AWS in 2010 and the function has become even more robust since then.

The tagging function allows you to define keys and values which can be used to categorize, filter, and sort resources. You can tag resources based on the environment they are being used, the team or department that is using the resource, or the feature the resource supports.

A combination of tagging and account segmentation gives improved visibility into cloud costs.

The following steps are important for implementing an effective tagging strategy:

Define compulsory cost allocation tags.

Tagging only works well if your team is using a global tagging policy across AWS accounts and across multi-cloud environments.

At a minimum, you need to understand three things about every single resource that's deployed into your environment:

1. The purpose or function of the resource. It's not enough to say that a resource is a database. Instead, identify the service that is using the data in the database. That is, what service does the resource support?
2. The owner of the resource. If something goes wrong with the resource, what team or department should be responsible for it?
3. The environment in which the resource is used. Is the resource a production system, QA system, or other system?

Each resource should have cost allocation tags that provide information about these three things, at the very least.

Plan for containerized workloads.

Containerization offers a lot of benefits, such as reduced overhead, greater efficiencies, and more consistent operations. One big downside is cost visibility. Make sure you utilize whatever tagging constructs your containerization platform provides (e.g. labels for Kubernetes). Not only should you ensure workloads are “tagged” within the containers, but these tags or values should align with the compulsory AWS tags described above. This will enable you to not only understand your spend within the containers, but will also let you more easily combine it with your non-container spend for greater business alignment.

Create a corporate tagging policy.

Ensuring that tags are created consistently in the same format and with the same keys and values is critical for effective tagging. One reason for doing so is that AWS tags are case-sensitive. The same tag name in uppercase and lowercase letters will be read as distinct tags. For example, "devops" is a different tag from "DevOps" in AWS. This is why your policy should include clear rules for adding new tags.

A global tag template is also important if you work in a multi-cloud environment because, although all cloud platforms allow tags (or labels), there is no uniformity between platforms.

For example, whereas AWS tags are case-sensitive, only lowercase characters can be used on the Google Cloud platform, and case-sensitivity is mixed on Microsoft Azure. Similar variations exist for key and value lengths and the use of special characters.

The solution is to use the lowest common denominators across platforms:

• Lowercase letters
• Maximum key length of 63 characters (if you use Google Cloud) or 128 characters if you use AWS
• Maximum value length of 63 characters (if you use Google Cloud) or 256 characters if you use AWS or Azure
• Letters, numbers, and the special characters +, -, =, ., _, :, and @

Publicize and enforce the tagging policy.

Once you have defined the required tags that must be added to any resource, it's important to get all engineers and developers on board with the tagging policy. Explain why it's important to use these tags and how they help you understand cloud spend. Give your team some time to adjust to the new rules before enforcing the policy.

You can use automation to enforce those tags by automatically quarantining or removing untagged resources after a specified period. This way, developers and engineers are reminded to adhere to the policy and best practices at all times.

3. Establish a shared understanding and responsibility for cost.

Beyond tagging and implementing structures through accounts, having a shared understanding and responsibility for cost is important. Organizations that successfully manage their AWS investment usually have some type of metric — budget or a unit cost perhaps — to gauge performance, but there's a clear expectation that everyone is responsible for costs.

Like any other operational metric performance, such as security, for example, each team should be required to meet cost objectives when building systems.

Gain Cloud Cost Intelligence With CloudZero

Like many businesses, you may have several untagged or non-uniformly tagged resources spread across multiple accounts on AWS. How do you impart structure and organization in such an environment in the least resource-intensive way?

CloudZero is a cloud cost intelligence platform that delivers relevant cost data to engineering teams about their products. CloudZero has built a mechanism that takes existing metadata about your organization's infrastructure — this could be tags or accounts — and applies machine learning to build a context map based on that metadata. It also uncovers untagged resources, which could make up a significant percentage of the infrastructure, and builds them into the context map.

The context map is essentially a three-tiered hierarchy of your resources categorized into cost groups — products, teams, and features. In less than an hour, you can immediately see where your cloud spend is going, without performing time-consuming manual tagging activities.

When new resources are added, the machine learning system relies on the improved context map to automatically place those resources in the right cost buckets.

CloudZero also uses that context map as a guide to perform other functions such as:

• Sending context-specific notifications to specific teams: An example is the anomaly detection feature, which employs machine learning to automatically detect and send alerts on anomalies to the responsible teams via Slack.
• Making unit cost calculations: Unit cost calculations can roll up appropriately to products, customers, or whatever unit cost calculations are of interest to you.

As a result, you’ll spend less time digging to understand your costs and more time making informed decisions to control your costs based on the rich data that CloudZero provides. By combining machine learning automation with human intelligence, CloudZero brings immediate visibility into your AWS environment and keeps your infrastructure streamlined at all times going forward.

To see CloudZero in action, .