Cloud cost analyses provide insights into where budgets are being spent and whether resources are being utilized efficiently; however, it is difficult to produce a meaningful cloud cost analysis when the cost of resources being used by the same workloads, departments, etc. is distributed across hundreds of line items.
If you’ve been in a position in which it is virtually impossible to extract meaningful data from a cloud cost analysis, you’ve probably thought how much easier it would be if every user tagged resources in the same way. You might have even proposed a global tagging policy in the past, but, due to issues such as misspellings, random capitalization, non-standard abbreviations, and the erratic use of special characters to identify one user’s resources from another’s, the idea has never really worked.
The situation is further complicated when tagging formats used in your on-premises infrastructure don’t match those of your Cloud Service Provider, or when your business operates in a multi-cloud environment, where different Cloud Service Providers apply different rules to how tags can be used—or apply some rules to some resources and other rules to other resources. For example, AWS allows you to tag EC2 instances with any character, but doesn’t allow the same flexibility for other resources.
How tagging rules differ in different cloud environments
Other than EC2 instances, AWS allows you to use letters, numbers, and spaces, and the characters +, -, =, ., _, :, /, and @ in tags, but it’s important to be aware that letters are case sensitive. If two resources are separately tagged “Env” and “env”, each will appear as different line items on a cloud cost analysis. Similarly, resources with misspelt tags, random capitalization and non-standard abbreviations (i.e. “Envir”/”envir”) and special characters (i.e. “envir@1”) will also appears as different line items.
By comparison, Azure only allows alphanumeric characters—which are not case sensitive, so costs for resources tagged “Env” and “env” would be combined in the same line item on a cloud cost analysis. Unfortunately, you can’t use spaces or special characters, and it is important to be aware that—unlike AWS—tags applied to resource groups in Azure are not inherited by the resources within the group. If you don´t tag each resource individually, you will have one very large cost allocated to a blank line.
In Google Cloud, “labels” (Google Cloud uses the term “tags” in network traffic monitoring) are always applied as key/value pairs – i.e. “environment :production”. Only lowercase letters, numbers, underscores and dashes can be used in keys and values; and, although you can apply labels at the time of deploying a VM instance, labels for other resources have to be added retrospectively. So the likelihood is businesses operating in Google Cloud have a lot of untagged resources in their inventories.
Developing and enforcing a global tagging policy
Regardless of whether your business operates in a single cloud, hybrid cloud, or multi-cloud environment, tagging every resource is recommended—not only to make it easier to extract data from a cloud cost analysis, but also for easier IAM management, cost optimization, compliance, and other areas of cloud governance. How you develop your global tagging policy will depend on which cloud(s) you are using and the rules they apply to formats, resources, and value lengths.
Even when everybody is on board with the global tagging policy, it is important to have guardrails in place to ensure all resources are tagged—and tagged correctly. Even with the best will in the world, it is possible for human error to creep into the deployment process, or for users to forget to tag resources if they can’t be tagged at the point of deployment, and the best way to enforce a global tagging policy is to take advantage of cloud management platforms with policy-driven automation capabilities.
Policy-driven automation enables you to configure the platform with allowable tags (i.e. ones that conform to the global tagging policy) and actions to take when the policy is violated. The policies and actions will vary according to what cloud(s) are being used, but examples could include:
- Prevent the deployment of resources on AWS if tags are missing. If tags are misspelled or include capital letters, initiate a Lambda function to correct the misspelling.
- If a resource deployed on Azure is untagged after a day, notify the resource owner. If a resource deployed on Azure is untagged after two days, stop the resource.
- You can employ similar prevent/stop policies to resources deployed on Google Cloud, or, if a non-conforming value is used, initiate an approval workflow.
Make your cloud cost analysis meaningful again—easily
Extracting meaningful data from a cloud cost analysis in which line items are widely distributed can be time-consuming and—due to the potential for human error—you are not guaranteed the data you extract will be accurate. Policy-driven automation can address the issues that prevent global tagging policies being effective.
If you want to learn more about policy-driven automation read our eBook: 6 Policy Types for Governing Your AWS Environment.
