Tagging Amazon resources is a valuable tool that establishes a system for managing an AWS environment. Tagging allows resources to be categorized by subjects that will make them easily identifiable for those working within the environment. Organizing your cloud expenses into types and categories, by means of a consistent tagging policy, allows you to track, analyze and conserve cloud costs. This process should be continuously performed throughout multi-cloud deployments, making cross cloud cost allocation simple to perform.
Although a system exists to organize cloud resources, it is not always utilized effectively. As a result,
resources go untagged when they have no associated policies. More times than not, this is due to an automation error, as can be seen below where AWS provides CLI with the tools necessary to tag resources that are provisioned programmatically. Making effective use of cloud tags starts by ensuring that every resource that is created (manually or automatically) is tagged based on business policies.
In addition, as you can see in the resources table, there are some `untaggable` resources, such as load balancers and DataTransfer. One way to understand the cost of such `untaggable` resources is by applying business rules to the distribution of costs. For example, one rule could be that DataTransfer costs will be allocated to different groups in proportion to each group’s EC2 consumption:
How-To Use AWS’ CLI or API Tools to Tag Resources: ec2-create-tags
AWS enables you to tag an AWS resource using a CLI or API command. The example command below adds (or overwrites) two tags for an AMI and an instance.
One of the tags solely contains a key (webserver) with no value (we set the value to an empty string). The other tag consists of a key (stack) and value (Production).
PROMPT> ec2-create-tags ami-1a2b3c4d i-7d3e5a2f –tag webserver –tag “stack=Production”
TAG image ami-1a2b3c4d webserver
TAG image ami-1a2b3c4d stack Production
TAG instance i-7d3e5a2f webserver
TAG instance i-7d3e5a2f stack Production
Each resource can have a maximum of 10 tags. when tagging a resource, you have the option to give each tag two names, the first being the ‘key’ and the second, the ‘optional value.’ Neglecting to identify both or even one of these tag names will cause cost allocation issues. Both are explained in the following example scenarios:
- If an EC2 instance goes untagged, you have no way of attributing it to a business unit. Let’s say you have 3 business units: Marketing, R&D and Production. If 70 out of 100 of your EC2 instances were tagged, that leaves you with 30% of your instance costs unallocated
- The second scenario deals with the ‘value’ tag. For example, when tagging an EC2 instance, you will sometimes want to tag it with a subcategory in order to track usage and costs that are shared across different teams or projects.
Let’s go back to our 3 business units example, only now, each unit has a second optional value called ‘Project1’ for DataTransfer allocation.
10 Instances: Marketing_Project1
60 Instances: R&D_Project1
30 Instances: Production
Let’s say the CIO, or CFO, wants to apply the business rule that allocates DataTransfer costs in proportion to the EC2 usage breakdown. If 30 instances do not have the ‘Project1’ tag, 30% of the instances will not be attributed to ‘Project1’ or allocated at all in the DataTranfer cost.
Inconsistency in resource tagging can also be generated by each tag’s specific name. For example, if different business units tag their resources using variations of the same name, such as,”biz_unit” and “BUSINESSUNIT”, it is impossible to perform proper cost allocations according to actual business units. In order to fix that, these resources need to be identified and should be tagged retroactively – whether this is done via AWS or the third party vendor’s system depends on whether the instance was terminated or not.
EC2 Reservations in Cost Allocation
In AWS, a Reserved Instance (RI) cannot be effectively tagged and therefore not attributed to the appropriate business unit from which it was ordered. The reservation is applied to any matching instance irrespective of accounts or tags. The cost impact of a reservation is comprised of the initial upfront cost along with the savings it generates. Therefore, the business unit which orders the reservation should be attributed this cost and savings.
An interesting scenario arises regarding what to do with RIs in case they are unused. Two potential cases exist:
- The first case is that business unit A orders the reservation and then decides not to use it, meanwhile the RI is being applied to matching instances for business unit B. Who should get the the cost savings and what should the default policy be? In this case, the corporation is not losing money, however cost allocation is not being divided effectively.
- In the second case, the RI is unused and not applied at all. The RI could be reassigned or modified to match instances from another group, but is not, and therefore the corporation loses money. If the RI has been ordered, unused and is not being applied, then the corporation has paid for it, however, it is not gaining the associated savings.