Learn more
AWS tagging: Why tagging is not enough

AWS tagging: Why tagging is not enough

The ugly truth about cloud tagging is that it is easy to implement poorly and then suffer from ineffective cloud cost management as a result. This article delves into why there is a gap between the theory behind resource tagging for effective AWS cloud cost management and the real-world experience of many teams.

Please be assured that a) you are not alone; what follows are common issues, and b) Finout has developed an effective solution to mitigate these issues (more on that later).

Why do we use AWS cloud tags?

AWS tags are labels that may be applied to resources such as EC2 instances, S3 buckets, etc. They are a simple way for teams to associate metadata with a resource. Each tag is comprised of a key:value pair, both of which are user-defined.

AWS resource tagging is the first step in your cloud cost management strategy. AWS allows you to set up tag policies and to tag by resource group and provides a tag editor. Setting up cost-related tags then informs your later analysis of your cloud costs. Once you are able to assign costs to applications, teams, and projects, then you can manage your AWS spending.

AWS Cost Explorer uses tags to reveal the breakdown of your AWS resource usage. And, of course, your cloud cost management platform, such as Finout, consumes these tags to perform both of these functions and much, much more.

AWS tags: beyond cloud cost control

Note that AWS tagging can be used beyond the realm of cost control to assist with important functions such as identifying:

  • Who / which team is responsible for an AWS resource?
  • Which of your services has alerting enabled?
  • Which of your AWS resources are unnecessary at low-load hours?
  • Which roles or team members should have access to a resource?

5 common AWS tagging gotchas

It sounds like a simple plan: set up your data collection, analyze the data, and change your strategies in response to the information provided. So, where does that go wrong? 

You may be familiar with the PEBCAK issue. PEBCAK stands for Problem Exists Between Chair and Keyboard. Sadly, the majority of AWS tagging challenges you will observe are human issues. AWS has left the tagging strategy entirely in our hands, and, with great power comes great responsibility. When that responsibility is not met, the following common issues are experienced by the DevOps and FinOps teams:

  1. No initial tagging strategy
  2. Poor buy-in
  3. Poorly-implemented tagging strategy
  4. The un-taggable
  5. Inherited AWS environment

#1 No initial tagging strategy

It is not uncommon for teams to be fairly experimental in their approach when they first dip their toe in the cloud. The issue is that such resources may remain active in your cloud environment, and no one wants to terminate them as they are unsure what they were set up for.

#2 Poor buy-in

After those baby steps and those first oblique AWS bills, the need for a tagging strategy becomes apparent, and a team is given responsibility for setting it up. However, everyone is busy, thank you very much, so even if the tagging strategy is developed, it is not enforced coherently – leaving many costs unassigned.

Without a solid FinOps philosophy connecting teams and empowering everyone to understand their place in cost control, it is hard to initiate the required level of buy-in.

#3 Poorly-implemented tagging strategy

Even if the tagging strategy is enforced, the outcome might not be what the designers anticipated. 

Perhaps someone has observed the issues that arose from #1 or #2 and assigns a tag cleanup team. However, the tagging cleanup team is not game for laboriously manually tagging those resources, so they do what devs do and assign tags using a script. This means that the outcome is only as good as the assumptions that were made to perform the assignations (which may not always be perfect!).

And the issues can be as simple as someone not realizing that AWS tags are case sensitive: ClientA, clienta, and clientA are three different entities in AWS. Perhaps someone, without even thinking about it, abbreviated environment to env. Variants can cause big problems.

And, just to add a touch of irony to the issue of variants and cost control: if such tags are also cost allocation tags, then all those variants must be activated in AWS. The more tags that are activated, the more it costs to store their data!

#4 The untaggable

Tagging teams almost certainly come up against the problem that certain resources in AWS just don’t align with the desired tagging policy. It might be that the costs associated with such resources need to be abstracted up a level or two. For example, it might be necessary to implement a cost allocation tag as general as “DAM-infrastructure” to collate global costs that arise from creating a Digital Asset Management solution. 

#5 The Inherited AWS environment

And then there is #5 that can suffer from any combination of 1–4: you inherited someone elses’ AWS environment. Whether this occurs due to churn or thanks to the acquisition, it can create some knotty problems.

Take a moment to consider those teams who are managing a merger, or acquisition. It’s hard enough managing one company’s tagging policy, let alone combining two entirely separate sets. From individuals to individual teams, there can be a vast gap in the differences in opinions about how to deploy and tag resources.

AWS Tagging: Best Practices

So, armed with the warnings, how do we ensure that your team implements a best practice approach to AWS tagging?

  1. Make it obvious what a tag’s purpose is

AWS recommends creating four categories of tag: technical, business, security, and automation. You may have your own favorite pillars. But, whatever you select, make sure the strategy is obvious to new users.

  1. Define the rules of usage

Note that the value component of the key:value pair is optional in AWS; is it optional in your ruleset? It must be clear which tags are mandatory and which are optional. AWS does have naming restrictions, so align your AWS tag naming convention with this. Establish whether “-” or “_” is allowed, or perhaps you will PascalCase or camelCase. 

  1. Keep it simple

AWS limits you to 50 tags per resource; try and limit yourself further. Remember what it's like to be the new brain on the team and cater to the lowest common denominator. But, in balance to that, if in doubt, tag!

  1. Automate it

Amazon provides a resource tagging API. This enables you to govern and implement tags at scale. More automation means less human error: providing you with higher quality and more maintainable tags.

  1. Review it

Implementing your initial tagging strategy is only half of the challenge. Keeping tags relevant and updated is the other half. You will probably find that high-level concepts such as 'purpose' and 'cost center' are consistent. But, the technology you apply and projects that are active may have a higher turnover, so you will need to review the tagging policy. 

Thinking beyond AWS

Now all teams work in a pure AWS arena. Some teams face the challenge of managing multi-clouds tags to reveal the cost of customers across AWS, K8s, Snowflake, GCP, and beyond! 

And, having started this article with the challenges, we want to finish with the good news. You do not have to remain in AWS to tag AWS!

Finout provides an abstraction layer with our no-code, cloud cost control platform. Here at Finout, we take cloud cost control very seriously. It is our mission to simplify your cloud cost management: which is why we are pleased to announce our new virtual tags feature. Virtual tags act to empower FinOps teams to grasp back cost control and mitigate your AWS tagging challenges.

Are you interested to learn more? Sign up today to learn more

Learn More

7 Ways to Improve Your Cloud ROI

AWS Recommendations for EC2 Cost Reduction

How FinOps can help cyber security vendors rein in cloud costs

Cloud Economics: Cost of Cloud Services Explained

What is FinOps

How to Choose a Payment Option for EC2 Reserved Instances (RIs)

How FinOps takes cloud cost management to the next level

4 Cloud Cost Management Questions that FinOps Answers

Finout's guide to understanding multiple cloud bills complexity

How to Use AWS Cost and Usage (CUR) Report

What is AWS Cost Usage Report (CUR)?

How Unit Economics help SaaS companies optimize their cloud spend

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: Top 5 Cost Management Challenges

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

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

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