Common Tagging Strategies To Help Identify and Manage AWS Resources and Costs

Common Tagging Strategies

In this article we will go over some of the most common tagging strategies to help you in identifying & managing your AWS resources & costs.

 

Tagging Strategies

There are 4 main tagging strategies to go with:

 

Resource organization

You can use tags for the sake of organizing your AWS resources in the AWS Management Console. It’s possible to configure tags for displaying them with resources, then start searching and filtering by tag. Using the AWS Resource Groups service, you will get the chance to start creating groups of AWS resources according to 1 or more tags or just portions of tags. You are additionally capable of creating groups according to how much they occur in an AWS CloudFormation stack. With Resource Groups and Tag Editor, you will be able to start consolidating and viewing data for apps which are made up of various resources, services as well as Regions in 1 place.

 

Cost allocation

AWS Cost Explorer and detailed billing reports will allow you to begin breaking down AWS costs using each tag. Mainly, organizations utilize business tags like “project”, “cost center” or “business unit”, or “customer” for the sake of associating AWS costs with traditional cost-allocation dimensions. However, a cost allocation report is capable of containing whichever tag. This will allow you to associate costs with security of technical dimensions, like particular environments, apps or compliance programs. Below you can check out a partial cost allocation report as an example.

A couple of services, allow you to utilize an AWS-generated “createdBy” tag for the purposes of cost allocation, in order to aid account for resources which may otherwise remain uncategorized. The “createdBy” tag can merely be used by supported resources and services. It has a value including data associated with particular API or console events.

 

Access control

Tag-based conditions are good with IAM policies, because they allow you to put constrains on IAM permissions according to specific tags or tag values. For instance, IAM user or role permissions are capable of having conditions that put limitations on EC2 API calls to be in particular environments like test, production or development according to their tags. This exact strategy may be utilized for the sake of limiting API calls for particular VPC networks. Tag-based, resource-level IAM permissions are supported according to service. Upon utilizing tag-based conditions for access control, you must ensure that you set and restrict the people capable of modifying those tags.

 

Automation

Resource or service-specific tags are generally utilized for the sake of filtering resources when automation activities are taking place. Automation tags are utilized for opting in or out of automated tasks or for identifying particular versions of resources to get them archived, updated, or deleted. For instance, you are capable of running automated “start” or “stop” scripts which can turn off development environments while nonbusiness hours occur for the sake of lowering costs. In this case, EC2 instance tags will be the simplest and best way for identifying instances and opt out of such an action. As for scripts which help in finding and deleting out-of-date, rolling or stale EBS snapshots, an additional dimension of search criteria can be added by the use of snapshot tags.

 

 

Examples of some common Tagging Strategies

We should take a tour around a couple of genuine real-world tagging strategies. These are adjusted from genuine organizations that tend to utilize AWS tags for arranging their resources for different reasons. Even though they might not be the same as your case, they’ll still provide you with knowledge about how you could be able to tag your resources in AWS.

First Example of Tagging Strategies: Service-Based

The most common pattern used for the sake of tagging resources is according to service and environment. For instance, let’s say we have an organization which includes 2 services: cart and search, as well as 2 environments: prod and dev. This organization may end up setting such tags:

Key                 Value

service           cart or search

contact          Engineer maintaining this resource

env                  prod or dev

 

In the case that those 2 services both share one same RDS instance, then the database is capable of being tagged as: “service=cart|search” for showing that this particular resource serves both cart and search services.  Also, the architecture may somehow look as follows:

In case you select an AWS tagging strategy similar to this one above, you must keep in mind the way your tags are going to change as time goes by. For instance, let’s say you added a new service which shares the exact RDS instance, now you should start updating the database’s tags for the sake of making it contain the new service’s name. Because of this, a few teams would rather opt to go with a just one tag for showing that a resource might get utilized by every single service, such as: service=common.

Such service-based tagging strategies will be mostly a fine starting point in case of needing to acknowledge what services affect your AWS costs the most. Your business team is capable of utilizing such tags for the sake of checking the amount they’re paying for every single service or environment, then ask for help from an appropriate contact in case they have any particular questions.

 

Second Example of tagging strategies: Account Segmented Environments

Now for the second example let’s check out this account-segmented tagging strategy. Even though AWS’s IAM permissions provide you with the capability to assign access to roles, teams granularly and users, a couple of organizations and companies might be in need to dive even deeper.

A platform engineer at an organization stated that whenever you have heterogeneous logical environments and you have collocated resources across those environments, it will become accidently possible to utilize different resources coming from another environment in case of not taking all necessary precautions to provision those resources and design network/IAM policies.  

Such an example shows how the organization should designate business unit and team tags for every single resource, and keeping their environments in separate AWS accounts.

By doing so, they will be able to start generating reports in every environment for checking their resource costs of marketing unit, “mktg”, compared to that of the data warehousing unit, “data”. In case the team starts utilizing this specific strategy for account-segmented tagging, they must rely on a master account for viewing resource usage in their whole organization.

 

Third Example of tagging Strategies: Compliance

AWS cost allocation tags are capable of aiding organizations manage and maintain governance or compliance in the business. Such tags may be utilized for limiting access or for running additional security checks on some of your selected resources.

In the following, a company tags resources including user data using “user-data=true” in order to audit them consistently while making sure that they undergo the required standards. Every resource includes both a “contact” and an “env” tag for showing the team member who is responsible and making sure that a person is n charge of keeping them updated.

The use of a compliance tagging strategy will not prevent you from also utilizing different strategies. A good advantage of AWS tags is the fact that they allow you to easily segment your AWS resources in countless effective ways.

These are the most common tagging strategies for your AWS use cases.

All the organizations which use AWS at scale, are required to build a tagging strategy which works for them the best. Take into consideration the AWS tagging strategies and examples mentioned above, while taking into account the goals of your organization.

As soon as you make up your mind on choosing a specific AWS tagging strategy which suits you, you must start developing a plan to add and maintain your AWS cost allocation tags.