Multi-cloud Tagging Best Practices

Why is tagging important?

As organizations scale their cloud environment, there’s a wide variety of infrastructure services, assets, and resources on which stakeholders across the organization will want to analyze, measure, and report. 

Most organizations will have several different ways they want to report their cost, usage, performance, availability, and security, and these needs will change over time. For example, finance may want a monthly breakdown of costs by product line or shared environment; operations may need a usage breakdown by project or team; and engineering may want a performance breakdown by application role. Having multiple ways to organize information is pivotal to enabling users with different needs to manage and make effective use of their cloud infrastructure. 

The challenge for most organizations becomes how to define, structure, and allocate resources in a way that allows for streamlined reporting on the backend. This is where (proper) tagging strategies come in. One trick to keep tagging strategies in check when you’re first starting out? Focus on consistency. Misspellings, new conventions, or capitalizations can all cause tagging organization to go awry and can contribute to new variations of an existing tag structure—ultimately increasing the difficulty in which one can report on via tags down the road. 

Tagging parameters

Tag categories can be grouped based on cost, usage, security, or automation, just to name a few. For example, Business tags could be Cost Center, LOB (Line of Business), Business Unit, Usage tags can be along the lines of Environment, Function, or Project, and Security tags could be Compliance, Public, Confidential. 

An advanced use case for tags is that they can be leveraged to Allow/Deny access to certain resources. As an example, the InfoSec team can design a security policy to allow Nancy, who is an SRE, access to certain instances tagged as “Production” but deny John, who is an Account Executive access to those resources

Each cloud provider has a slightly different approach to tagging, see the table below for a quick reference guide for multi-cloud tag parameters.
 

CloudHealth tagging best practices

Here are 10 multicloud tagging best practices we recommend customers who are working to build out an organized and thoughtful approach to tagging:

1. Choose a standardized case sensitive format, as this helps to maintain the tagging architecture across different hyperscalers
2. Maximum of 50 tags per resource
3. Maximum of 63 unicode characters each, for the key and the value
4. Each tag can only have one value
5. Plan for known restrictions for every cloud you are using or may use in the future
6. Use tags to support the ability to easily manage resource access control, cost tracking, automation, and organization
7. Sometimes more is more, especially when starting out. Apply more tags now in case they may be needed later (AWS, Azure, and GCP support at least 50 tags per resource)
8. Aim to implement a consistent standard across all cloud providers
9. Even though the Tag or Label Key case sensitivity may differ from CSP to CSP, AWS, Azure, and GCP all have case sensitive Values and it maybe beneficial to enforce a standardization, such as ensuring all values are in camel case (ThisIsAnExampleOfCamelCase).
10. You can leverage CloudHealth to tag resources that may otherwise be not supported as a taggable resource by the CSP. CloudHealth tags help you overcome these limitations and tag more resources. In addition, you can leverage both CloudHealth tags and cloud-provider tags when building CloudHealth Perspectives, which gives you greater flexibility in organizing your cloud infrastructure
     

Orchestration tools for automating tagging

Leveraging cloud native tools such as AWS CloudFormation or Config rules, Azure Resource Manager, or GCP Deployment Manager can help manage your cloud environments. You can also use native controls such as AWS Tag Editor or AWS Config rules if AWS is your CSP, Azure’s Resource Management tool if Microsoft Azure is your CSP, or Cloud Console and Cloud APIs if you’re using GCP.

In addition to cloud native tools, third party tools such as Terraform, Chef, and Puppet can also be leveraged for configuration, management, automation, and governance of your cloud infrastructure. One of our customers since 2015, Yelp, Inc leverages CloudHealth for their AWS cost visibility and optimization, and operational excellence. 

Using industry best practices and tooling such as Terraform, source control management, and AWS Lambda, Yelp minimizes the burden of asset tagging and allocation for developers and  the team keeps over 95% of allocated assets in their perspectives. Yelp’s hierarchical perspectives offer varying granularity: from technical categorization of the workloads being performed to human readable projects, teams, and cost centers. 

You can find more information in the recorded CloudLIVE session here and their open source Terraform provider for CloudHealth here.

Maintaining tagging hygiene is crucial as your organization scales it’s cloud footprint and the number of CSPs in use. It’s important to take your time and develop a plan before you start implementing tags to ensure you’re tagging resources in a way that will actually allow you to report on them down the road. Think about what kind of questions you want to answer (e.g. How much money is my Dev team spending on their Azure test environment?) and create tagging practices that will answer those questions. 

In my next blog on multicloud tagging best practices, I’ll walk through tagging strategies your organization should implement on day 1, as well as practices your team should be implementing for long-term scalability and success.  
 

table {
margin-bottom: 15px;
}
table td {
padding: 5px 10px;
}
table.second th {
padding: 5px;
font-size: .9rem;
}
table.second td {
font-size: .8rem;
}