Whatever your cloud or virtualization platform of choice, you can implement tags on your resources in order to easily apply configuration changes or search by group.
As multi-cloud environments continue to become more and more popular and your virtual servers, storage, and associated components sprawl across various providers, efficient governance becomes even more critical.
By implementing a cloud resource tagging policy, you lay the groundwork to consistently apply automated or manual actions relating to allocation, reporting, chargeback, compliance, security, patching, software installation, and even decommissioning or scaling resources when required.
Tags are small bits of metadata you add to your cloud resources. Without a global cloud tag policy and consistent name conventions, they will be largely useless, as various versions of tags will make complete reporting or automation actions impossible (think “dev” vs “development” or “7days” vs “7Days”.
Tap your Cloud Services or Cloud Governance staff to work through a tag definition document and overall tagging policy that lays out the exact spelling, capitalization, and format for each relevant tag, and lays guidelines for the creation of any new tags.
Tags are generally set up with pairs using a key, or the tag category, and value, or description. For example, you might set up a tag for the department that is consuming a cloud service. The department is the key, while the values would be “engineering,” “development,” or “marketing.”
These values should be consistent across all cloud platforms and providers. Even if you don’t have management systems that can read and act upon tags from multiple providers, it will set you up for the future (and keep things adhering to best practices throughout all environments).
What should you tag? Think about what you usually report or actions you often wish to pursue in bulk across your various cloud resources. Here are some ideas on tag keys to get you started:
When tagging in a VMware virtualized environment, you should only tag from one management node at a time to avoid duplicates or overlap. It may take some time for tags to replicate across remote objects. Try to assign tags to local objects from the management node where the tag was created. When first creating your tag hierarchy, remember that you cannot change from “Many tags per object” to “One tag per object”, but you can go from one to many.
You can in theory create thousands of tags in vSphere, but users have reported performance problems once many tags are used, so tag wisely. vSphere tags may use letters, spaces, numbers, dashes, and underscores.
Within Azure there is a key and value tag limit of 15 for each resource, and you can only tag resources that are recognized by Azure Resource Manager. You can use a JSON string for ARM automation features if you start to run out of tags.
The length of the key is limited to 512 characters (you should not create tags longer than a tweet for any platform — keep them short and sweet!) and the length of the value is limited to 256 characters.
Azure tags are not case sensitive, but with our above best practices in mind, you should still treat them as if they are. Only letters and numbers are allowed, no special characters or symbols.
Tags are a key component of any cloud automation and governance strategy, especially for large-scale environments. Once you have implemented consistent tags across your resources, you can start using them with native and third party automation tools for a variety of purposes, including:
Cloud resource tags are a useful tool unique to your organizational needs and reporting goals. Placing them on resources immediately upon provisioning makes your life simpler down the road, so be creative and thorough when tagging. However, they can come with their own set of performance considerations. They can also lead to “tag sprawl” — yet another thing to keep track of and document, so you should also be judicious and thoughtful in your use of resource tags.