AWS Tags: 3 Simple Rules for Cost Management

First rule of AWS tags: Tag across reportable dimensions.

Tags work as a key-value pair.  The key is the “how” you want to report the data, the value is the “what” you want to report on.  The keys ultimately become the columns or dimensions by which you’ll want to break down your AWS cost reports.  Be sure to use reportable dimensions for the keys (like Environment or Product) for the keys that are meaningful for your organization and logically group the parts of your business or platform.

Second rule of AWS tags: Tag systematically using a consistent nomenclature

Reporting by AWS tags  is like any other kind of reporting; if it’s garbage in, you’ll get garbage out.  It’s important to stay consistent with both the keys and values you use to denote different types of spending.  Some of the more advanced users of tags will settle on a “required” list of 5 tags that all taggable resources should use.  If you use an automated process to deploy AWS resources, you can work it into your workflow to require those tags.  Whether you programmatically tag or do it manually, be sure to narrow in on what tag keys are the most important and be consistent about applying them across your infrastructure.

(Don’t sweat misspellings of keys though; Cloudability’s tag mapping lets you combine multiple keys into one dimension if you come across 5 spellings of a tough one like “envirnoment”…. )

Third rule of AWS tags: Use tags that will answer questions

Here are a few example keys for AWS tags and the types of questions they answer for you:

1. Cost center: what resources are affecting your your bottom line?
2. Business Unit: what group/department/division of your organization does this spending fall under?
3. Service: you may want to track costs of multi-functional projects or services shared across departments, like a logging service or a analytics service.
4. Product: how much is each of my profit centers costing to operate?
5. Tier: which part of my app is driving AWS costs— web, app, db, backend, hadoop, auto-scaling, etc?
6. Version: how do changes to my architecture impact total cost?
7. Environment: are we leaving things on or over-provisioning for our staging, test or dev environments?
8. Owner: which individual developer or team is responsible for this spending?

The big takeaway here is that before you can start getting good data out of your cost reports, you need to figure out what’s truly important to report on.  There are a lot of options and I recommend taking a less-is-more approach initially.  Determine which reports you need in order to make decisions that improve the efficiency of your spending, or simply getting the most valuable breakdown regarding where you costs are going.