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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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
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.
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).
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.
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.
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:
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:
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.
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.
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).
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.
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).
Single tag values:
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:
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.