Note: It’s More Than Tagging or Labelling
Providing relevant, timely insights through classification and allocation of Fully Loaded Cost is a key enabler for Cloud Cost Management. This is often discussed under the singular banner of a Tagging or Labelling Strategy.
Tagging and Labelling is a very important, but not the only component.
Utilising the Resource Hierarchy as well as Resource Types in combination with Tagging and Labelling leads to richest and most complete outcomes for Cloud Cost Allocation.
It is really about applying all of the metadata structures to achieve the objectives. And this is also how FinOps as a body of knowledge talks about Tags.
Below we summarise Top 10 Guidelines for a Cloud Cost Allocation Structure:
#1 – Use All Structures
#2 – Apply System Thinking
#3 – Collaborate Across Teams and Clouds
#4 – Formulate Your Questions
#5 – Define Global Standards
#6 – Keep It as Simple as you Can, as Complicated as you Must
#7 – Define Your Materiality Limit
#8 - Use Tools & Automation
#9 – Be Cognisant of Data Silo’s
#10 – Stay Alert and Agile
#1 - Use All Structures
The following four levels or hierarchies are generally available to organise your Cloud Cost Allocation:
1. Organisational Units or Folders
2. Accounts, Subscriptions, Resource Groups and Projects
3. Tags or Labels
4. Services (Compute, Storage etc.)
You can use organisational units or folders (OUs) to group accounts together to administer as a single unit. You can create multiple OUs within a single organisation, and you can create OUs within other OUs. The same applies to accounts. Tagging typically is applied across those structures, to both the structures and the Services which in itself form a cost category.
#2 - Apply System Thinking
A potentially confusing statement as we do not mean ‘technical systems’ but rather refer to the end-to-end process.
Systems Thinking is a holistic approach that focuses on the way that a system's constituent parts interrelate and how systems work over time and within the context of larger systems.
The premises of System Thinking is that If you get the process right, then the results will take care of themselves; the how is more important than the goal. If you optimise each part, goal achievement will improve. Apply atomic habits, be proactive, strive for excellence, be cognisant of feedback.
A good example of end-to-end system is depicted well by Marco Meinardi in “Implementing a Tagging Strategy for Cloud IaaS and PaaS”, published 12 December 2019:
#3 – Collaborate Across Teams and Clouds
The cloud metadata structures are used by different groups to achieve different objectives. In a multi-cloud environment, this spans teams that work in different clouds.
To achieve a coherent and optimised outcome, it is recommended to assign your meta data structures across your teams. It is also recommended that you ensure consistency can be applied across the different cloud platforms.
Collaborating on the meta data design will bring teams together and foster a collaborative culture which is critical to effective Cloud Cost Management.
#4 - Formulate Your Questions
The whole point behind creating a Cost Allocation Structure is to be able to answer key questions about how the entity uses the cloud. It is important to define those questions, and to do it early in the process.
Collating the possible questions from the different stakeholders helps you understand their needs and the metadata structures that are required. It will also help in creating a common taxonomy that will help formulate a common language, which is another critical enabler for Cloud Cost Management.
Questions like:
1. Who is the responsible budget holder?
2. Is this a Project or Business as Usual cost?
3. How are cost in areas of responsibility behaving?
4. What are cost by application?
5. What cost behaviour am I expecting?
6. What services am I using?
7. What is the relative cost per service type?
8. What is cost per unit of consumption?
9. What is cost per unit of consumption vs. list?
10. Where can I save cost?
11. What cost is untagged and why?
12. Is cost within budget?
13. Will cost stay within budget (what is forecast)?
#5 - Define Global Standards
Define and publish global standards to be used. And make sure this is owned and governed (did we mention system thinking?). And apply this to both for keys and values.
For instance, “never use capitals” and for “environments” use “prod, pre-prod, qa, dev, test, sbx”.
Try to keep the key terms focused on your business, its structure and the terminology in use. You may also want to look at similar standards that are already used for other tools and environments.
Here are some of common examples:
- Cost centre
- Product
- Project
- Application
- Service
- Employee
- Environment
- Role
#6 - Keep Tt As Simple as You Can, As Complex as You Must
A metadata strategy can be overwhelming, especially when you have a complex infrastructure. It is generally recommended that you start with three to five obvious areas whose costs you want to understand.
However, in the end it is a question of stakeholder requirements, organisational requirements, perceived value or benefits enabled and ability.
Ability in this sense is expressed in terms of what cloud environments enable, the capacity and capability of your teams, the tools you have deployed to enable creation as well as control and correction.
We are a strong believer that every requirement will expose its own solution. Being demanding while at the same time being open to accepting trade-offs has the potential of pushing your team and organisation ability to a new level.
#7 – Define Your Materiality Limit
Agreeing to what level you want to achieve allocation, your materiality limit in financial terms, may be a useful approach. You may want to do this both in terms of absolute values and in terms of % of total spend.
When developing our strategy, be cognisant of the type of services you are using. Be wary of focusing only on a set of resource tags needed for your compute instances.
Understand your usage patterns and how that impacts your requirements: how to address the common challenges of shared resource cost allocation, what to do with shared RIs, do you have containers and how does that impact your needs and what you can and cannot do?
At the same time, also be aware that if you have 98% covered, then that is probably sufficient. Be wary of substantially increasing your ongoing management cost by striving to 100% coverage. Agreeing to what level you want to achieve allocation, your materiality limit in financial terms, may be a useful approach.
#8 - Use Tools & Automation
Ensuring complete and accurate metadata is critical.
The cloud providers make a number of tools available that make this easier and build in. Make sure you use these tools to the maximum extent possible.
Also be aware of the cloud providers development paths as all – with AWS leading – are investing in enabling Cloud Cost Management.
At the same time, when you build your own automation, make sure that the requirements of metadata are covered.
If you uncover tagging challenges, for instance through incorrect tags or material untagged usage, consider building and deploying automation to correct these findings in the form of a tag janitor.
And last but not least, look at policy deployment to ensure compliance. For instance, a ‘tag or delete’ policy has been proven to be very effective.
#9 – Be Cognisant of Data Silo’s
We have talked to a number of tool providers. Some of them address the metadata challenge at source, others through creating separate data silos within their tool solutions.
Be aware of those data silos, the access you have to the details and your ability to migrate the data back into your own single repository somewhere in the future.
#10 – Stay Alert and Agile
Cloud providers make new metadata structures available, new services provide new challenges, cloud provider and third-party tools are rapidly developing and the body of FinOps knowledge and understanding is increasing. And the $ value of your cloud spend will continue to increase, the number of clouds you use may increase, and your maturing understanding will throw up new requirements.
Make sure you stay alert and agile to be able to capitalise on the opportunities and respond to the requirements. Accept change as the only constant.
.jpg)
