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 assigned 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!).

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 else’s 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.

2. 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. 

3. 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!

4. 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.

5. 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. However, 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-cloud 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.