AWS tagging: Why you need it and how to do it

AWS tagging: Why you need it and how to do it

If you have ever inherited a tagging strategy or on boarded into a new team and faced adopting an existing AWS tagging strategy, you will be able to testify that there can be a chasm between the theory and the practice of cloud tagging.

This article offers to close that gap by laying the groundwork required to scaffold an effective tagging strategy.

What is AWS tagging?

AWS tags add meaningful data to resources. There are AWS-native tags added to resources by AWS; these you can’t edit. Then there are user-defined tags. A user-defined AWS tag is an assigned category or key, and an (optional) value to that key, as per the traditional key: value pair.

Most teams leverage user-defined tags, i.e., metadata, for cost analyses, though it can also simplify the resource management protocol in other ways. For example, tagging often goes beyond assisting with finance and settlement – by supporting AWS Cloud Cost Management to offering functionality in operations and resource monitoring also.

How do you effectively implement tagging in AWS?

Three factors play into a well-implemented AWS tagging strategy:

  1. Utility: tags are useful, pronounceable, and memorable
  2. Consistency: tags are correctly applied across all resources
  3. Relevance: tagging policies are reviewed to ensure that they are still fit for purpose

 

The strong scaffold relies on that last item: relevance. Relevant tagging policies are driven by teams who take the time to plan a coherent tagging strategy. We have long argued for the need for such teams, and implementing a coherent tagging strategy is a vital first step in ensuring their effectiveness.

Your tagging strategy begins when the stakeholders involved can provide a simple, yet persuasive, justification for each tag.

Armed with a relevant and practical tagging strategy, the next challenge is to ensure that it is applied consistently. This means that each tag must be assigned to every resource that applies. Note, this does not equate to “create hundreds of tags”; it means that the correct tags are applied to the relevant resource. 

And finally, utility. If you are part of the tagging strategy team, have a heart and think of all the people that will apply and pull information based on your tags. If you can say the tag name out loud, then it is easier to remember than a phrase that sounds random or is not readable. The more intuitive a tag feels, the better the outcome in terms of its consistent application and the ease of reporting.

And so, we cycle back round to that last item again: relevance. Creating a cloud tagging strategy is not a one-off exercise. Sure, that task should never be so large as the first time, but fine-tuning your tags in response to business needs is part of maintaining utility and relevance.

AWS tagging: the payoff

All this hard work provides a seriously useful payoff. Cloud architecture must be responsive to changing business needs, but to accommodate this, cloud teams tend to over-engineer to create reliable margins for error. And the end result of this caution is “bad sprawl”. 

Bad sprawl is that unused space, over-resourced compute instance, and forgotten storage. Tagging is the first step in applying a protocol to support good governance and an effective strategy to mitigate bad sprawl. Couchbase estimates that the excess spend by enterprises may account for 35% of cloud costs. This means that your AWS tagging protocol can provide a serious ROI.

When your management tools don't give teams access to the data they need, then cloud cost control, resource monitoring, and optimization attempts are all hampered. The ultimate outcome of data collection is the information it provides, and your task as the cloud tagging team is to ensure that you don’t suffer from the “garbage in, garbage out” issue. Good, clean data is essential for cloud management.

 

AWS tagging: part of a larger strategy

Tagging in and of itself will not control costs or manage resources. A tagging strategy is simply the data layer that supports your resource management. It must, therefore, be part of a larger strategy. This strategy will be supported by at least three layers:

Control Layer

There must be an approval process for approving new cloud builds and a review process to identify opportunities to decommission underutilized or inactive resources. This will be so much easier now that you have tags that identify the owner or team responsible for each resource!

Governance Layer

There must be a clearly-defined schedule to specify how often cloud resource usage must be reviewed. The team must also establish how system resources should be evaluated in terms of the value they provide.

Reporting Layer

The reporting layer consumes the data provided by tagging and other cloud monitoring solutions. Such reporting does not have to be restricted to describing the status quo; once the data pipeline is in place, it is possible to forecast and schedule routine forecasts of anticipated cloud spend projections. Comparing these to the actual cloud spend can reveal those unanticipated issues.

AWS tagging: Where Next?

 

If you are ready to get started with your tagging strategy, then we strongly recommend our deep dive into where teams commonly go wrong with their tagging strategies: 5 Issues With Cloud Tagging.

Perhaps you are familiar with the challenges, and you know the reality of AWS tagging is that, even with a well-planned and smoothly executed tagging strategy, there are still challenges at the reporting layer. Disclaimer, we have some good news, and that is: you do not have to remain in AWS to tag AWS!

Finout provides a tag abstraction layer in an intuitive, no-code, cloud cost control platform. Finout’s virtual tags feature empowers teams to grasp back cost control and mitigate those AWS tagging challenges.

 

Are you interested to learn more? Click here to book a time with our team!

 

Learn More

How FinOps helps make sense of cloud spending complexity

Discovering Finout's brand identity

5 Best Practices for Cloud Cost Management on Google Kubernetes Engine

The complete guide for Google Cloud pricing

DynamoDB Pricing: How to Optimize Usage and Reduce Costs

Introduction to Cost Management in Google Cloud

How to Manage Cloud Costs on GCP and GKE

AWS tagging: Why tagging is not enough

AWS tagging: Top 5 Cost Management Challenges

How FinOps Has Changed the Way Businesses Approach Cloud Computing

How Kubernetes Works and Why It’s So Complicated

Why Use Data warehouses in general and Snowflake specifically

We are announcing our $18.5M funding!

A Guide for APM Data Warehouses Tools

How to manage Snowflake costs

Managing DynamoDB Costs with Capacity Modes

Finout's Complete Guide to Kubernetes Cost Spot-Readiness

Finout's Complete Guide to Kubernetes Autoscaling

Do you need Kubernetes in AWS?

FinOps - What are your true cloud costs?

Guide - How to Save Money on your AWS Cloud

3 Native Tools to Utilize for AWS Cost Management

Finout's Complete Guide to Kubernetes Labels

Using FinOps for Resource-Level Cost Management on Kubernetes

How did Finout merge Kubernetes into AWS CUR

The main principles of FinOps

Why IT Showback is So Complicated | Difference Between Showback And Chargeback

An Intro to Amazon DynamoDB Pricing: Challenges and Best Practices | Finout

Kubernetes Cost Monitoring And Observability Tools Of 2022

This is why Finout is important to Sustainability

Join the FinOps Revolution

"Whether you’re a part of a team with an established FinOps practice, or are building up the discipline, everyone can relate to the challenges of mapping cloud utilization cost to their drivers one-to-one." – FinOps Foundation