# Home Some advice for your cloud tagging policy ## About this guide A solid tag strategy is crucial for your infrastructure and its evolution and should not be left-behind. You will be able to improve : * Infrastructure operations * Cost tracking and optimization * Monitoring and reliability * Regulatory compliance The purpose of this guide is to provide insights on the creation and management of a tagging policy in an organization. *This guide is still being written. Any comments (FR/EN) :* {% embed url="" %} *Written by* [*Vincent Collard*](https://vincoll.io) # Why care about tagging In Organizations **without a clear tag policy**, naming is left to everyone's goodwill, and **inconsistencies** quickly result. Your cloud infrastructure will be a mess, preventing you to operate it efficiently, when it comes to paying the **bill** you will be **unable to detect abnormalities**. At first the tags will allow you to simply name your resources. This is level 0.\ Then it will become handy to find your resources, then to classify them. Their interest should grow and go beyond the purely infra part to be more transversal. > Below a citation of the great : [Resource naming and tagging decision guide](< https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/resource-tagging/>) from Microsoft Azure ![](/files/-MAL8hQSD_guOKRKHG0w) * **Resource management:** Your IT teams will need to quickly locate resources associated with specific workloads, environments, ownership groups, or other important information. Organizing resources is critical to assigning organizational roles and access permissions for resource management. * **Cost management and optimization:** Making business groups aware of cloud resource consumption requires IT to understand the resources and workloads each team is using. The following topics are supported by cost-related tags: * **Operations management:** Visibility for the operations management team regarding business commitments and SLAs is an important aspect of ongoing operations. To be well-managed, tagging for mission criticality tagging is a requirement. * **Security:** Classification of data and security impact is a vital data point for the team, when breaches or other security issues arise. To operate securely, tagging for data classification is required. * **Governance and regulatory compliance:** Maintaining consistency across resources helps identify deviation from agreed-upon policies. This governance foundation article demonstrates how one of the patterns below can help when deploying governance practices. Similar patterns are available to evaluate regulatory compliance using tags. * **Automation:** In addition to making resources easier for IT to manage, a proper organizational scheme allows you to take advantage of automation as part of resource creation, operational monitoring, and the creation of DevOps processes. * **Workload optimization:** Tagging can help identify patterns and resolve broad issues. Tag can also help identify the assets required to support a single workload. Tagging all assets associated with each workload enables deeper analysis of your mission-critical workloads to make sound architectural decisions. # First things first ## Your goal: Coherence The design of a tag strategy, like any other **standardization, requires coherence**.The name of your **keys**, the value of your **tags**, your **APIs**. **Everything must** be done intelligently to **make sense**. If you already have some kind of convention, you will have to migrate it to your new standard. It is difficult for users to deal with two rival standards. ## Tagging is achieve through automation **Tagging requires rigor**, despite the fact that it is a **repetitive and boring task**. Fortunately for us computers excel in this area. **Tagging should not** be apply by a **human**, **but through automation.** This means that your **infrastructure provisioning** processes **need to be automated.** ## Multi Cloud Tagging If you are on a **multi-cloud strategy**, your providers may have **different tag constrains**. You'll have to establish a **compatibility between your providers**. Some cloud don't accept capital letters tag keys, others don't accept dots... Some limitation are listed in [Resources/Cloud Tag Limitation](/resources/cloud-tag-limitation). Even if they are often *n* **separate teams** managing *n* clouds, **don't silo** your teams in charge of your standardization. **Otherwise** you **risk** getting **duplicate tags between your suppliers**, it's silly, **inconsistent,** and your internal infra teams won't adhere to a **wobbly standard.** ## Involve the Finance department The more you get into the cloud, the more money you'll spend. Sooner or later you will discover the role of the Comptroller. And they will rightly want to know how and for whom these resources are allocated. As an IT person, you don't have the vision of how the company is financially structured. Your tags should allow you to break down the cost of the infrastructure in your organization. So ask the finance department, the way they run the business to design the best possible categorization in order to facilitate the work of the FinOps team. # Prepare your policy Remember: Coherence is key ## Achieving Coherence: Create your own policy :notebook: lorem ispsum # Key & Value ### 1. Case {% hint style="info" %} :point\_right: I do recommend: **lowercase** {% endhint %} #### lowercase Lower case is the safest and simplest strategy. No providers restricts the use of lowercase letters. However the legibility of compound names can be poor. One solution is to add word separators. In this case, to maintain consistency, you will have to use this separator on each of your compound words, even the simplest ones. #### Camel case (**PascalCase || dromedaryCase)** Some provider like GCP does not allow any uppercase in key or values. #### UPPERCASE No. Do NOT use full upercase. #### **About** acronyms You must also choose whether or not to keep acronyms in uppercase. If you choose to accept uppercase acronyms, their use with CamelCase may be illegible as is the case in lowercase. Adding a separator in addition to upper case to handle uppercase acronyms is unmanageable. | **lowercase** | lower + sep | Pascal Case | dromedary Case | | -------------------- | ------------------------ | -------------------- | -------------------- | | env | env | Env | env | | nodepool | node\_pool | NodePool | nodePool | | autoshutdownschedule | auto\_shutdown\_schedule | AutoShutdownSchedule | autoShutdownSchedule | | awsaccount | aws\_account | AWSAccount | AWSAccount | ### 2. Separators I distinguish 4 types of separators : **Compound words** nodepoo **Word separator** aks-pzkvig13g1-14517300-1 **Scope separator** **Norm separator** {% hint style="info" %} :point\_right: I do prefer : * Compound words : **\_ (underscore)** > JSON compliance * Words separator : **- (dash)** > Simple * Scope separator : **. (dot)** > Follow DNS principles * Norm separator : **/ (slash)** > Clear separator, parsing is simple > {% endhint %} {% hint style="warning" %} Your choice must be made taking into account the tagging constraints imposed by your providers. {% endhint %} space / - \_ . ### 3. Language {% hint style="info" %} :point\_right: I do recommend for a non-native English org : **English** {% endhint %} If English is not the official language of your organization, you must choose between your current language and the standard that is English. English has the advantage of not having accented characters. Despite the existence of UTF8, the handling of these non-ASCII characters can be a source of encoding problems. #### Avoid Misspelling If you have chosen English as your tagging language: pay attention to the very close spelling between your language and English. For example (French vs English) : | FR | EN | | ------------- | ----------- | | ressource | resource | | environnement | environment | ### 4. Complete names or abbreviation {% hint style="info" %} :point\_right: I do recommend : * For the few widely adopted, long and unambiguous name (eg: env, bu): **abbreviation** * Others : **complete names** {% endhint %} The abbreviation of the tag names must serve a practical purpose. * Long names are prone to typos * It's easier to request keys with short names eg : env vs environnement * Useful if char length is limited # Naming & Conventions # Tags # Basic Tags | Type | Tag | Description | | ---------- | ---------------------------------------------------------------------------- | ----------- | | Compliance |

compliance

dataresidency

| | | Gestion |

owner

managedby

provider

beneficiary

consumer

| | | Biling |

bu

costcenter

| | # Extra Tags ### Identify your App | Tag | Description | Example | | ----------- | ----------- | ------- | | app | | | | app\_svc | | | | squad, team | | | ### Security | Tag | Description | Example | | ---------- | ------------------ | --------------- | | exposition | | public, private | | encryption | encryption at rest | | ### Reliability | Tag | Description | Example | | ----------- | ----------- | -------------- | | criticality | | c0, c1, c2, cx | ### Billing | Tag | Description | Example | | ---------------- | ----------- | ------- | | bu | | | | costcenter | | | | accounting\_code | | | ### Run | Tag | Description | Example | | ----------- | ---------------------------------------------------------------------- | ------------------------------------------------- | | schedule | Know whether a machine is meant to be turned off on a regular schedule | 6pm-6am, weekends off, business hours only, 10pm+ | | managed\_by | On duty team | | | | | | ### Compliance | Tag | Description | | --- | ------------------ | | | HIPAA-1, PCI, GDPR | owner provider beneficiary consumer # Others Team Tags # Publish your policy To Do # Create an API/Library To Do # Adoption With intelligence comes trust # Enforce your policy To Do # Edit your policy To Do # References convention Existing international conventions are references to be used for your strategies. ## International conventions ### Time * [Representation of dates and times ISO 8601 ](https://en.wikipedia.org/wiki/ISO_8601) ### Localization **Region** * [International Civil Aviation Organization (ICAO) region](https://en.wikipedia.org/wiki/ICAO_airport_code) **Country** * [Country subdivision code](https://en.wikipedia.org/wiki/ISO_3166-2) (ISO 3166) * [**United Nations Code for Trade and Transport Locations (**UN/LOCODE)](https://en.wikipedia.org/wiki/UN/LOCODE) * [International Civil Aviation Organization (ICAO) ](https://en.wikipedia.org/wiki/ICAO_airport_code)country * [Mobile Country Code](https://en.wikipedia.org/wiki/Mobile_country_code) **City** * [International Air Transport Association (IATA) airport code](https://en.wikipedia.org/wiki/IATA_airport_code) * [International Civil Aviation Organization (ICAO) ](https://en.wikipedia.org/wiki/ICAO_airport_code)airport # Others guides #### Cloud & Providers * Azure * [Resource naming and tagging decision guide](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/resource-tagging/) * [Recommended naming and tagging conventions](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging) * AWS * [Tagging AWS resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) * [Tagging Best Practices](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf) * Datadog * [Best practices for tagging your infrastructure and applications](https://www.datadoghq.com/blog/tagging-best-practices/) * [The power of tagged metrics](https://www.datadoghq.com/blog/the-power-of-tagged-metrics/) #### Style Guide * Google * [Google JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml) # Cloud Tag Limitation The different providers have limitations on the key or value of the tags. If you use two clouds make sure your policy is valid for each of them. ### Clouds * AWS * [Tagging Your AWS Config Resources](https://docs.aws.amazon.com/config/latest/developerguide/tagging.html) * [Tagging AWS resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) * Azure * [Naming rules and restrictions for Azure resources](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules) * [Use tags to organize your Azure resources and management hierarchy](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources#limitations) * GCP * [Labeling resources](https://cloud.google.com/compute/docs/labeling-resources) ### Providers * Datadog * [Defining Tags](https://docs.datadoghq.com/tagging/#defining-tags) # About # FAQ ## Do I need a tag policy ? Yes # Things not to do environement\_str = INTÉGRATION