In my previous article, I have described things to consider while preparing tags. Here, I share a few resource tags which are worth using in the cloud. Before immediately jumping into picking all the tags, get to know your cloud provider limitations. Also do not forget that tags should help you, and not to be unexpected burden.
Cost
Depending on cloud provider, you may have additional mechanisms to manage and redistribute the costs. However, cost center resource tag comes really handy for cost’s purpose. Also it allows achieving really granular level of costs divisions. You may need more that one cost related tag. It comes to how your organization manages the costs currently.
Ownership tags
This tag allows you to achieve better manageability over your cloud landscape. With this label, it will be easier to find person responsible for particular resource or a decision maker. Please note, that not always this may be the same person. You need to rely on your organization structure, and identity how many owners you need. You may consider:
Business Owner – responsible for general business competences, and in most cases this will be a single point of contact to make a decision or doing sign off.
Technical Owner – this is person who is technically responsible for resources or solution. Probably the one who will be implementing changes approved by business owner.
Anyway, as I mentioned earlier, everything comes to how complex your organization model is. It may occur that you need just one resource tag for an owner, or even more than two.
Automation tags
Describing your environment with the code, gives you a great simplification and acceleration of a deployment. However, you need to think also about further operations. The maintenance of your cloud landscape should benefit from automation as well. Here the tags can help in identification of resources for which some actions must be triggered. One of examples can be to define power plan for automatic shutdown and start of the virtual machines. Another can be expiration or end of life dates for your resources. Depending on your operation needs, you can define specific resource tags and values that allows you to define triggers for your functions.
Security tags
Large cloud environments have plenty of resources. It is demanding to manage all security aspects of them. Especially to remember all the individual regulations and measures that are applicable. Therefore, to ease the task you can create a set of tags to mark security identifiers for your resources. We can divide resource tags into a few exemplary groups:
Regulations
When you process company data in the cloud, there are different regulations you must adhere to. It may be GDPR, HIPAA, GxP or any other compliancy requirements . It may be helpful to tag the resources, to improve verification if you applied proper security measures for your resources.
Data classification or categorization
In organizations you may see different levels of data classifications, which determine the measures that you need to apply to secure them. The tags can be helpful from at least two reasons. First one is to enforce or automate actions that needs to be applied per different categories. Secondly, such tag may improve the verification if you implemented proper controls in your environment.
Visibility tags
This group of resource tag is for improvement of services’ visibility. This can aid later in reporting, cost management or automation. However, it is worth to point that sometimes, you have quite limited number of characters per resource name. Or sometimes you may not want to write an essay long resource name, just to describe all the details. It may not be wise or maintenance friendly. Therefore, the tags can improve your general understanding of what is the purpose of particular resource. Here are a few examples of resource tags that you can use:
Environment type
There are different designation of resources in the cloud. This can influence the level of security and controls for your resources. You can distinguish various types of environment e.g. production, acceptance, test, pre-test, development. It is up to you organization how many environment types are considered for tag value. You can add this in the name of resource, but sometimes that tag can be simpler.
Configuration
There may be a special setup of the service or any dependencies on other services. This may be crucial to know, especially while proceeding with maintenance on the environment.
Summary
While determining the tags, use helpful principle the less is better in this case.
| TAG | explanation |
| Power plan | Providing information when to shut down the system, when to start |
| Decommission / End of life | A date when certain service becomes obsolete |
| Technical Owner | Person technically responsible for the solution, |
| Business Owner | Person responsible for decision making for the solution |
| Maintenance windows | When the downtimes are allowed |
| Data classification | What types of data are processed |
| Compliance | Which regulations the service must comply with e.g GDPR, GxP, HIPAA etc. |
| Environment type | Provide the stage of environment whether it is production, acceptance, test, development, sandbox etc. |
| Accessibility | To determine who is the receiver of service whether it is internal, external or partners, or a combination to properly apply access level |
| Configuration | Any special service setup, which may have crucial impact during improperly handled maintenance e.g. cluster setup. |
| Cost Center | The cost identifier of business unit or department for the purpose of proper redistribution of the costs. |
Remember, that for the tags to work the information you provide must be consistent. Also note, that in public cloud environment you should be cautious. Ensure that values for the tags are verified and agreed with proper departments before applied in the cloud directly.
