Navigating Your Multi-Cloud Tagging Strategy
Many companies are embracing multi-cloud strategies and in doing so need to be very purposeful in creating global tagging strategies that will work across all clouds. All cloud providers are not created equal when it comes to tagging and have different limitations. It is important that your global tagging policy does not violate any of the limitations of any of the cloud providers that you use today or will possibly use.
Whether you’re starting your tagging strategy from scratch or “retrofitting” your current cloud infrastructure, here’s how your organization can tackle the challenge: Design your tagging strategy using the lowest common denominator approach. In other words, design it to accommodate the various and distinct limitations of each major cloud provider. This lowest common denominator approach will ensure that you don’t end up with a fragmented tagging strategy. Fragmentation of your strategy is a sure fire way to reduce its usefulness and longevity.
DivvyCloud recommends the following tagging strategy design to accommodate all major cloud providers:
- Maximum Key Length (driven by GCP): 63 Characters
- Maximum Value Length (driven by GCP): 63 Characters
- Maximum # of Tags Per Resource (driven by Azure): 15 Tags
- Case Sensitive
- Keys and values can only contain lowercase letters, numeric characters, underscores, and dashes. International characters are allowed.
- Label keys must start with a lowercase letter and international characters are allowed.
- Label keys cannot be empty
- Tag names can’t contain these characters: <, >, %, &, \, ?, /, @
- AWS-generated tag names and values are automatically assigned the aws: prefix, which you cannot assign. User-defined tag names have the prefix user: in the Cost Allocation Report.
- Use each key only once for each resource. If you attempt to use the same key twice on the same resource, your request will be rejected.
- You cannot tag a resource at the same time you create it. Tagging requires a separate action after the resource is created.
- You cannot backdate the application of a tag. This means that tags only start appearing on your cost allocation report after you apply them, and do not appear on earlier reports.
- Tags applied to the resource group are not inherited by the resources in that resource group.
- Tags can’t be applied to classic resources such as Cloud Services.
Keep in mind, all of the providers are regularly expanding their tagging support, but best to plan for today and expand later when able to.
Now on to a few different strategies based on where you are today in your global tagging strategy journey.
How to Create and Deploy an Effective Tag Strategy
Starting from scratch: When launching your tagging strategy as part of the provisioning process, ensure that your tags represent all the needs of your organization. This will take planning and collaboration across several departments – from finance to operations to each of the business units that use the cloud as part of their workflow – and it’s best to put in a lot of effort before deployment. If your organization doesn’t address all the tags needed at launch, it means a lot of work will be needed after deployment. In general, more tags are better than fewer tags, just as long as the tags are standardized and well-documented to eliminate input mistakes and redundancy. Once your strategy is fully fleshed out, it’s best to implement it with as much automation as possible to eliminate human error and potential gaps.
Retrofitting your existing cloud infrastructure: When dealing with a messier implementation scenario, such as adding tags to an existing cloud infrastructure, there is no easy button. Take a phased approach. Establish your policy and begin to implement it first within the IT departments. Once you have full compliance here then move on to developers and engineers in business units or who sit outside of central IT. Start in all cases on applying this policy to all net new resources and build this muscle memory. Establish the value of tagging with all the parties involved. Demonstrate the benefits to everyone in the organization – up and down the company hierarchy. Once you have buy-in then begin to move through legacy environments and update tags. Do so on some type of incremental basis that limits the period and frequency of disruption to the people who will have to inform or execute this effort.
Developing and implementing a strong tagging strategy works best when your organization is starting with a clean slate. That way, tags can be implemented, standardized, and enforced as part of the provisioning process. Starting from scratch also lets administrators fine-tune the tagging process moving forward: New and updated tags can be added cleanly and seamlessly as new code bases are deployed.
Unfortunately, few organizations have the luxury of starting their efforts with a blank canvas. Instead, most tagging strategies are implemented as a “uh oh, we need to address this” measure — a necessary reaction to an increasingly complex and diverse cloud infrastructure. Perhaps the company has grown quickly or moved more critical resources to the cloud over the years. Maybe the cloud provider has made additional resources available for tagging. In other scenarios, organizations may have implemented effective tagging strategies already, but a merger or acquisition requires getting an inherited infrastructure up to speed.
With an effective tagging strategy, any organization can achieve a greater sense of clarity and structure within a multi-cloud infrastructure. Your tagging strategy can start simply and seamlessly and over time, it can mature and grow in complexity as your business evolves and scales. All you need is a solid tagging foundation, an understanding of best practices, and an inspired first step.
If you’re interested in learning more about effective tagging strategies, download our new white paper – Take Control: Multi-Cloud Tagging Strategies for the Win.