#01. Is tagging the way to go for cost allocation?

To answer this question, let's make the cost allocation guideline clear. Every organization should use the account hierarchy structure recommended by cloud providers as the primary method for cost allocation. After that, they can add tags to specify cost allocation based on different dimensions such as application version, resource owner, and usage purpose. To understand why, lets consider how the allocation through account hierarchy works.

TL;DR

• Use the account hierarchy structures recommended by cloud providers as the primary method to allocate your cloud costs. Implement clear naming conventions for these hierarchies. This approach should effectively allocate the majority of cloud expenses.
• Add a few common tags or labels to further refine the granularity of cost allocation.

Allocating Cloud Resources Through Account Hierarchy Structures

Each cloud provider has its own way of structuring cloud resources. For example AWS use the structure of organisational units (OUs) that contains different accounts. Each account in turn contains various resources and services.

The same structure is used in GCP, with difference in terminology, where accounts are projects, and OUs can be substituted for folders (which can be nested).

Finally, we see the same pattern as well in Azure, but with one major difference: Resource Groups, which could be used as an extra layer of grouping resources belonging to a specific workload together.

To allocate costs using account hierarchy: Separate cloud resources for different business purposes into distinct accounts (or projects/subscriptions). Create a hierarchy that groups resources by business purpose.

Here's how this works in practice:

1. Application workload: In DevOps, applications typically have different environments (e.g., development, staging, and production). Create an account/subscription/project for each environment. This separates development costs (dev + staging) from production costs. It also facilitates showback and chargeback—you can quickly identify internal product development costs for showback, while charging back production costs directly to clients (e.g., for an e-commerce application).
2. Legacy Application: For legacy systems running in VMs (i.e., multiple VMs, DBs, and networking configurations in the same account), we recommend:
   1. Separating each application workload (i.e., environment) into an account, even for legacy systems.
   2. For temporary applications slated for decommissioning with no further development, place all resources in the same account. Use resource groups (in Azure) or tags to split environments.
3. Microservices: When developing applications with multiple microservices, some services may be shared across applications. In this case:
   1. Move all shared services into a separate application with multiple accounts for different environments (e.g., sharedservices-dev, sharedservices-staging, and sharedservices-prod).
   2. Use shared cost principles (covered in a separate article) to allocate these expenses.
   3. Allocate remaining non-shared services to their respective accounts as discussed previously.

Enforce Account Naming Conventions

When using the account structure hierarchy, it's crucial to adhere to a specific naming convention. This practice is essential for two main reasons:

1. Readable description of resources (e.g., Accounts) that includes all key information.
2. Consistency and Standardisation.
3. Easier tracking and filtering of resources across regions, business units, and even public cloud providers for easier governance
4. Many tools, dashboards, and utilities can automatically interpret these naming conventions to map costs to business entities and streamline showback processes.

There is no single standard for the naming conventions. However, consider these principle when creating it (reference):

• Clarity: The name should convey the purpose and scope of the account clearly.
• Consistency: Follow a standardized structure across all accounts.
• Scalability: Allow for easy expansion as your organization grows.
• Uniqueness: Ensure each account has a distinct name.

Add Cost Allocation Granularity with Tagging

When creating showback or chargeback reports, we may need to add extra dimensions of cost visibility. For instance, in an application consisting of microservices, the service owner might want to see or compare the cost of each service. Using a tag like service: xyz would facilitate this.

Tags consist of a key-value pair, defined by the resource owner according to a tagging dictionary. Acting as keywords, tags provide additional information and context about resources within the cloud environment. They enable organizations to categorize resources by criteria such as cost center, purpose, owner, environment, or other relevant factors.

Before implementing tags, organizations should define a clear tagging strategy (read it in this article). This strategy serves as a set of guidelines for which tags to use and for what purpose.

Summary

Cost allocation works at best when you start with the correct cost allocation hierarchy structure and then compliment its granularity with a well defined tagging strategy.

Thanks for reading! Share if you found it helpful. Have questions or suggestions for future topics? We'd love to hear from you!