A Complete Introductory Guide to AWS Cost Allocation Tags
AWS Cost Allocation Tags are key to understanding what you're spending on AWS services. Learn about this powerful tool and how to adopt it.
AWS Cost Allocation Tags are key to understanding what you're spending on AWS services. Learn about this powerful tool and how to adopt it.
AWS has been the single biggest change in how teams build applications in the last 15 years. Unfortunately, there's a catch when it comes to AWS: that money bit. AWS wants as much of my money as they can take. At many companies cloud computing costs comprise significant operational expenses every month. For many of these companies, AWS is the second-biggest line item in the budget after salaries. That's not necessarily a bad thing. After all, if you're a software company, you're going to spend money on the hardware that runs your software. The problem comes when teams can’t say what they are spending so much money on. Fortunately, AWS provides AWS cost allocation tags to collect information about what you're paying AWS.
In this post, we'll talk about what tags are and how you can use them to peer into how you're spending money with AWS. We've talked extensively about how tags are one of the first steps in AWS Cost Optimization and knowing where you're spending with tags is a stepping stone to creating an informed FinOps practice. Because we want this post to be valuable to anybody using AWS, we’ll focus on what you can accomplish with AWS native tools.
Cost allocation tags are tags that you define and apply to AWS resources
Cost allocation tags are tags that you define and apply to AWS resources. That's obviously a simplistic definition, but it's an important starting point to understand how to use this tool. The key phrase in that definition is that you define the tags. While AWS does apply some default tags to every resource you spin up, the real strength of these tags are defining your own. Think about it: You don't think about your services as "This is an EC instance attached to a S3 bucket powered by an RDS backend." Instead, you think of each service you run as the billing service or the account management service. AWS tags allow you to define a tag like "billing_service" or “team” or “cost center” and then apply that to as many AWS resources as needed.
You're able to apply each tag to more than one resource, and you're able to apply up to 50 tags to each resource. At the end of each billing period, AWS generates a comma-separated value document. If you download this document, you'll find a list of your tags and the costs each tag incurred. From there, you can import that information to whatever reporting system you use.
To create a tag, you'll want to use the AWS Tag Editor in the AWS Management console. You can create up to a total of 500 tags for your environment and apply up to 50 to any individual resource. You can't start a tag with the word user or aws, because those are reserved in the AWS system. But other than that, the sky is the limit. In order to create a tag, you'll need to be signed in with an account that has the ResourceGroupsandTagEditorFullAccess permission. If your account lacks permissions to create new tags, you can open the IAM console and add the policy for the user in question by manually adding the following JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"resource-groups:*",
"cloudformation:DescribeStacks",
"cloudformation:ListStackResources",
"tag:GetResources",
"tag:TagResources",
"tag:UntagResources",
"tag:getTagKeys",
"tag:getTagValues",
"resource-explorer:*"
],
"Resource": "*"
}
]
}
From there, you can add or delete tags manually directly through the console.
Once you've created some tags, your next step is to add them to a resource or two. You'll do this right through the same Tag Editor console. While tags work for a variety of resources, they won't work for every AWS resource type. If you're looking to tag your resources, you'll want to check out the extensive matrix that highlights which resources support cost allocation tags. The good news is many of the most common AWS applications support tags. For example:
It's likely that if you've built a fairly standard set of applications on top of AWS, the tools you use support cost tagging.
In addition to the permissions needed to create tags, you will also need permissions for the service to which you're adding tags. There isn't one specific IAM permission to call out here like there is with creating tags. Each resource type will have its own specific permission that controls whether or not a user account may apply tags to it. If you're unsure about which permission you'll need, the best approach is to consult the documentation for the resource you're trying to tag.
If you spin up a resource that itself utilizes underlying AWS resources, you'll have to tag each of those resources manually.
One important thing to understand about resource tagging is that it's a pretty manual process. If you spin up a resource that itself utilizes underlying AWS resources, you'll have to tag each of those resources manually. For instance, if you're using an AWS resource that makes use of an underlying dedicated EC2 instance, you'll need to identify that EC2 instance and tag it using the same tags as the parent resource. This is the only way to know the complete set of cost details for that parent resource at reporting time.
Sometimes, you might want to backdate the application of tags. If you've been running a service for a while but only just created a tag, it'd be nice to see that tag in previous months' billing reports. Unfortunately, you can't do this. AWS doesn't support it. Tags only apply to billing reports going forward from the date that they're added to a resource.
If you’re using a tool like AWS CloudFormation, you can create a template that will automatically add cost allocation tags to resources when you provision them on AWS. This is highly recommended. Automatically tagging resources means that you don’t forget to tag resources when you provision a new service. That’s especially valuable if you delegate resource creation to entire teams; you don’t want to rely on every single person remembering to take this important step.
Alternatively, you can enforce the necessity for tagging new resources using AWS Service Control Policies. While this won’t automate the tagging of new resources, it is an important safeguard. CloudFormation templates apply to all new services created using a template, but control policies apply to all new services, regardless of how you create them. That means that no matter who creates a service and no matter how they do it, it won’t start up without the appropriate tags applied.
Once you've created a tag, you need to activate that tag before AWS will report on it. To activate a tag, you need to sign in to the AWS billing console, then navigate to the Cost Allocation Tags page. From there, you can choose which tags to activate. Once you do, it can take up to 24 hours before those tags will appear in your billing summary information. After you've activated a tag, you won't need to do any further maintenance on it. AWS will report on the tag forever.
Once you've tagged some resources and used them, you'll be able to review your cost allocation report in the AWS billing console. As we noted before, there are a few caveats: You can't see tags for months (or weeks or days) before the tag was added to the resource. You can't apply cost allocation tags to every resource. There are a few other caveats, too: For instance, services like premium support can't be tagged, so they won't show up in cost allocation reports. The same is true for one-time costs like EC2 Reserved Instance setup fees. So, a cost allocation report won't give you every single billing detail for your environment. But it will give you insights into how much you're paying for the resources you're using on AWS.
Allocation tags in AWS aren't a silver bullet. As we've noted, there are quite a few caveats to using them effectively. But, if you're running a software stack on AWS, they're a huge first step to understanding how much you're paying and for what. When you have that information, it gets a lot easier to start optimizing your spending and creating unit metrics that are related to your teams cost efficiency. The goal with your AWS deployment should be to maximize the return on your investment, and you can't do that until you know just what you're investing in.
