Use resource tagging to optimize cloud costs
Although cloud resource tagging appears in the curriculum for cloud architect and engineer certifications, it’s easy to skip tagging when first-time cloud initiatives take flight. With increased pressure from corporate CFOs for better cost management practices in cloud, cloud teams depend on resource tags and metadata.
The data from resource tagging can provide more granular reporting as well as better cost allocation and optimization recommendations. Tagging that applies across cloud service providers is possible if you take the time to plan and document your resource tagging strategy. Follow these tagging best practices and automated options to support cloud cost management.
Create clear and consistent tag names
It’s critical to establish and enforce a clear and consistent approach to resource tag naming conventions, whether you’re tagging AWS, Azure or Google Cloud resources. Such an approach starts by creating tags that are descriptive and meaningful, contain relevant resource information and have meaningful names.
Effectively using resource tags requires following established naming conventions. Here’s an example of a cost center tag in AWS:
Key: CostCenter
Value: TT12345
The key shows a cost center of TT12345 that you can apply as a tag to other AWS resources to track costs associated with this specific cost center and support allocating expenses accurately across your organization.
You can also use tags to categorize resources based on the department that owns or manages them. Here’s an example of a cloud resource owned by an engineering department.
Key: Department
Value: Engineering
Identify resources that belong to your environment. Here’s an example of a production environment tag:
Key: Environment
Value: Production
Test and iterate your resource tagging conventions regularly. Resource tagging requires continuous learning. Buffer your resource tagging process with extra time for iteration from internal feedback.
Choose a standard tag format
Choose a standard tag format and stick to it across all your resource tags. Your options are camel case, such as CostCenter, or underscore, such as cost_center. Standardization extends to keys such as Environment, Owner and CostCenter, and managers must enforce the tagging standard. Straying from a set standard will only create problems later when your cloud cost optimization strategy doesn’t accurately intake and analyze cloud spending across your organization.
As you create a standardized tag format, try to avoid the following:
- Abbreviations. These can confuse users unless they are part of your documented resource tag standards that are common knowledge.
- Special characters and spaces. These can cause issues with some AWS services. It’s also a good rule to follow with other providers in general because it simplifies tagging.
- Irrelevant information. Tag values should provide only relevant information about the resource. For example, the only values for an Environment tag would map to your organization’s cloud environments, such as Production, Development and Testing.
However, as you expand into more complex cloud environments, hierarchical tagging provides additional context. Here’s an example of hierarchical tagging for a project named TT Article run by the engineering department in a production environment in the Search Cloud Computing organization.
department: engineering
environment: production
project: TT_Article
org: Search_Cloud_Computing
Compare provider vs in-house tagging systems
There’s a balancing act between depending on a provider’s tagging system versus a tagging system you define in-house. For example, AWS has its own tagging system built to support its wide range of cloud services. Following their system ensures your tagging works correctly and feeds the necessary data to your cost reporting and other tools. Depending on your organization’s requirements, there could be the option to create your own system and standards.
While developing a resource tagging system in-house gives your teams ultimate control, it comes with the additional workload of analyzing and creating resource tagging standards and implementing them in your cloud environment. Teams must document in-house tagging standards to train other cloud team members. There’s also the risk of going too granular, thus increasing complexity, which becomes harder to support and even skip over when deadlines grow tight.
Automate resource tagging
If you want to progressively move into automation, start small with one project. Then take those lessons learned to other cloud projects across your organization.
Automation options for resource tagging include the following:
- Use cloud services provider APIs and SDKs to interact with other services programmatically to create, update and delete resource tags.
- Implement tools such as AWS CloudFormation, Azure Resource Manager and Google Cloud Deployment Manager to define cloud resources and their configurations in code. You can include tags as part of your resource definitions.
- Automate resource tagging using Ansible, Chef or Puppet by integrating with provider APIs.
- Rely on a cloud management platform to automate cloud resource tagging.
- Implement serverless functions such as AWS Lambda, Azure Functions or Google Cloud Functions to trigger tagging based on a preset schedule.
- Schedule cron jobs on virtual machines or containers to periodically check and update resource tags.
- Write custom scripts in Python, Bash or PowerShell to interact with APIs and perform tagging operations.
Also consider automation for policy enforcement to save your cloud teams from human error in resource tagging. AWS has AWS Organizations and AWS Config, which can help automate tagging and enforce tagging policies. You can use Azure Policy and Azure Automation to automate tagging in Microsoft Azure. Google Cloud enables tag automation via a combination of Cloud Scheduler, Cloud Functions and Cloud Identity and Access Management policies.
Will Kelly is a technology writer, content strategist and marketer. He has written extensively about the cloud, DevOps and enterprise mobility for industry publications and corporate clients and worked on teams introducing DevOps and cloud computing into commercial and public sector enterprises.
