AWS Tagging: Best Practices for Cost Allocation

Amazon Web Services (AWS) is considered the pioneer in delivering flexible, scalable, and reliable cloud service solutions. Its pay-as-you-go model looks accessible and palatable to any organization with ambitions to scale—especially when compared to the more complex operating and licensing models of the past that are still popular in many industries.

That being said, the reality of the rate of growth and size of your AWS bill might still come as a shock. Although AWS offers discounts, resource options, and granular control of your spending — most organizations fail to utilize all three effectively. This results in wasted spend that likely only gets worse as your organization scales.

In this article, we’ll look at how you can begin to build transparency—and leverage it for control over your AWS budget—using a capability that many don’t take advantage of: cost allocation tags.

What are AWS Cost Allocation Tags?

AWS cost allocation tags are simply labels that you or AWS can assign to resources. These tags have a key and a value (e.g., department: engineering). Cost allocation tags are included in your bill so that you can see roll ups of the total cost of each group of like-items.

AWS Tagging Use Cases

Although billing and cost management is the obvious use case for tags, there are other important reasons to apply them to your resources. Let’s take a look at them all.

Cost Allocation

Cloud Financial Management (CFM) or FinOps is equivalent to the traditional process of allocating CapEx and OpEx by cost center environments deployed in data centers. But, cloud cost allocation is rather challenging when you are dealing with shared resources and untaggable costs in a transient cloud environment.

AWS Cost and Usage Reports (CUR) and AWS Cost Explorer let you break down and analyze AWS costs using tags. That means your cloud financial reports can also assess using traditional financial dimensions such as cost centers, projects, departments, applications, production stages, and business units often used for billing and cost management across your organization.

Tags in billing can also be linked to technical and security dimensions. So, you can use tags for application security, compliance, configuration and change management, and audit programs.

Operations Support

Cloud providers offer a queryable centralized inventory of all of your cloud services and computing assets, which is equivalent to a Configuration Management Database (CMDB) in a data center environment. In this context, Tags are useful in day-to-day support operations such as incident management, operating system patching, and backup and restoration processes in a cloud environment. Below are some examples:

Incidents

Enable level 1 support engineers to map business services and direct incident response workflows using tags.

Patches

Schedule patching by tagging EC2 instances as development, test, and production to create different patch groups.

Backups

Assign and organize your resources to a backup plan using tags as you grow to scale your restoration procedures.

Access Control

You can manage access to AWS resources using tag-based Identity and Access Management (IAM) policies. This is also known as Attribute-Based Access Control (ABAC); in this management style, tag condition keys act as the rule granting permission for your IAM users or roles. For example, you could grant all of your engineers read-only permission to view your production environment but allow only a core subgroup to make any changes to it.

Security Management

A comprehensive tagging strategy is all you need to organize and categorize high-risk EC2 instances that process sensitive and confidential data. An automated compliance and vulnerability check can thereafter identify and manage related threats in real-time to your tagged high-risk resources.

Achieving AWS Well-Architected Standards

The cost optimization pillar in the AWS Well-Architected framework highlights how important it is for you to configure appropriate services and resources using resource tagging. Many AWS services such as Amazon Macie, Amazon S3, etc., let you optimize your resource costs based on object and resource tags. For example, a storage system may be accessible to your entire engineering team with the exception of a few specific objects that are appended with a special tag.

Attributes Vs. Tags

All of your AWS resources have both tags and attributes. Attributes are designated by AWS and are immutable. Examples of attributes are the AWS Account ID that the resource belongs to, Region and the Availability Zone where your computing resource is hosted.

Tags are defined by users. Examples of tags include the Department or the Business Unit owning the application. Refer to tagging categories for more technical tags, tags for automation, business tags, and security tags.

If you are managing a CMDB, you may recognize that you already store similar attributes in your CMDB for your assets that are deployed on premises. In such occasions, AWS tags and attributes can be used to integrate data from AWS to your CMDB or vice versa.

Note that the Name of a resource is typically defined by default by AWS at the time of its creation, however it can be changed since it’s actually a tag and not a permanent attribute.

The following example depicts two ways you can differentiate EC2 instances, via its AWS-defined attributes, or using its user-defined tags.

Source: Amazon AWS Docs

Tags Vs. Cost Allocation Tags

Cost Allocation Tags are specifically for and applicable to billing and cost management. They are based on regular tags used to assign metadata to any of your AWS resources, however, AWS requires you to take the added step of designating each tag separately as a cost allocation tag. This extra step helps AWS by not having to index all of your tags within your billing records and limits the scope to the tags that you deem relevant.

There are two types of Allocation Tags.

User-defined Tags

The user has the freedom to create up to 50 tags for each resource as they see fit to designate dimensions ranging from cost centers to projects. Use AWS Tag Editor to define cost allocation tags, and then activate the specific tags in the Billing and Cost Management console

AWS-defined Tags

These tags are automatically created by AWS. You can identify AWS-defined Tags as they follow the key-value definition, aws:createdBy. They are appended at the time of the resource’s creation so that you can track who created them and when it was done. Use Cost Allocation Tags in the Billing and Cost Management Console on AWS Management Console to activate these tags.

You can view tags on cost allocation reports (as additional columns with applicable values in each row) after 24 hours of activation.

Below is an example of using both user-defined and AWS-defined tags as cost allocation tags to help organize its charge back to the right cost centers:

Source: AWS Docs

AWS Tagging Best Practices

Establish Naming Conventions

Define the source of the tag using a prefix

For example, aws:cloudformation:stack-name identifies AWS CloudFormation stack that created the resource, whereas, thecompany:cost-center identifies the internal cost centre code of “the company” that created the resource.

Remember that tag keys and values are case sensitive

For example, Department and department are two distinct tags. Standardizing the way you write tags is essential. Note that many AWS defined tags use all lowercase letters, hyphens as word spaces, and prefixes separated by a colon to define source service for the tag. (E.g. elasticbeanstalk:environment-name).

Use TagOption libraries in the AWS Service Catalogue to eliminate human errors when naming tags

TagOption libraries enable you to specify tags you require with their range of allowable values to AWS service offerings, products, or portfolios organized in the AWS Service Catalogue.

Tags are account specific

That means a tag you create in one account cannot pull into another account without being re-created. A best practice is to use standardized identifiers across all accounts to have a consistent view across your infrastructure.

Standardize your resource naming convention

It has been common in data center environments to use composite names as hostnames to encode information about the resource’s location, application and environment. For example:

• hostname: use1d-p-w-csp-web1
• use1: us-east-1 region (region/ physical location)
• d: D availability zone (availability zone)
• p: production (environment type)
• w: web-tier (role/ purpose)
• csp: customer service portal (application ID)
• web1: unique identifier

Since AWS allows 50 tags for each resource in addition to many AWS-assigned attributes, the naming of the same resource above can be greatly simplified and rely on tags and attributes to be distinguished. For example, the same host could use the following tags and attributes:

Attributes (designated by AWS)

• Region:us-east-1
• AZ ID:use1-az1

Tags

• Name: web1 (a simplified name)
• user:application:customer-service-portal (application name)
• user:environment:production (environment type)
• user-role:web (role/ purpose)

In this case, the name of the node is simply web1 which can be reused for many applications in various regions and availability zones since the attributes and the tags help us separate them. This new approach may face resistance from engineering teams that have migrated workload into public cloud from data centers and used to the legacy naming convention.

For more AWS resource naming recommendations, refer to Standardized Names for AWS Resources.

Automate Tagging

AWS offers tools such as CloudFormation templates that let you automatically generate tags upon resource creation. This ensures tags are proactively added whenever members of your organization spin up new resources while also saving time (and money) by reducing administrative overhead.

Alternatively, you can define IAM policies that define resource-level permissioning related to creating and deleting tags. The “aws: RequestTag” and “aws: TagKeys” condition keys enable you to specify conditions that enforce a key’s value nomenclature.

Yet another alternative is to leverage AWS Organizations and use a Service Control Policy (SCP) to establish a guardrail around users creating a new resource without applying the appropriate tag.

Propagate Tags Across Related Resources

When creating a CMDB, you propagate attributes across related configuration items for easier monitoring and management. Similarly, you should also propagate tags and tag values across related AWS resources to take optimal benefit of tags. For example, you could append the tags used for an EC2 to all of the EBS (storage volume) that are attached to it, a step that is often neglected in AWS environments that we observe. With this approach, when you see the bill for that EC2, you will be able to also combine the cost of the storage used by that host.

AWS CloudFormation templates create AWS resources in stacks or groups; you can configure the automation script to automatically set tag-values across all resources within the stack. Otherwise, you can copy tags from a like-resource linking to other relevant resources if you are not using CloudFormation templates (e.g., you can copy tags from EBS volumes to create tags for Snapshots).

Actively Govern Tag Application

Tag propagation/automation is excellent for the bulk of your more broad tagging categories, but it is not enough for a holistic tagging strategy. Niche or temporary resource usage may require unique tags not included in your templates; new accounts may get created without awareness, etc. It is important to proactively evaluate tags, key values, and account configurations to prevent your tagging convention from falling behind the use cases. Tools such as AWS Config rules, Resource Tagging API, custom scripts, Tag Editor, and Detailed Billing Reports can be used for tag governance.

Avoid Tag Sprawl

Currently, you can use up to 50 tags per resource with a few exceptions (S3 objects). Avoid over-tagging resources with dimensions that don’t serve a required purpose. The best practice is to include one data value per tag key. However, there are cases where you must combine multiple attributes to create compound tag-values (e.g., contact information).

Compound tag-value:

• thecompany:technical-contact = Lee Hans;[email protected];+6145689077

Single tag values:

• thecompany:technical-contact-name = Lee Hans
• thecompany:technical-contact-email = [email protected]
• thecompany:technical-contact-phone = +6145689077

Challenges and Exceptions

There are challenges with tagging. We are listing a couple of them to give you an indication of the types of constraints that you may face in your tagging governance processes:

• Some resources are shared across your environment so it would be difficult to allocate its cost without doing some separate math. For example, a Domain Name Service (DNS) service may be used across your entire environment regardless of whether it’s UAT or Production, making it difficult to allocate the right portion when you are isolating your production costs.
• Some services such as Auto Scaling Groups (ASG) and Elastic Container Services (ECS) are designed to add nodes during peak times and terminate them when no longer required by the application workload. They create new nodes that are named similarly which makes it hard to distinguish at a glance, so you would have to rely on a unique ID (which is an AWS attribute) to isolate the costs during your peak hours of usage.

Final Thoughts

Interested in more ways you can get ahead of your AWS spending? Read our article on AWS Organizations to see how cost allocation tags fit into a much larger framework for AWS resource management and financial transparency.