Gestion de la politique de tagging automatisée

Comme pour la refacturation il y a, là aussi, des choix à faire afin d’assurer que tous les composants soient correctement taggés sans que cela requiert un effort sur-humain. On pensera entre autre aux points suivants :

Détection tags manquants

Définir les valeurs par défaut (si possible en fonction du composant en question, des composants associés, de l’application associée…) ainsi que les tags obligatoires pour ensuite mettre un alerting en place afin de détecter les tags manquants.

Destruction de ressources

Définir un processus pour la destruction des composants non conformes.

BU par défaut

Définir un processus pour le rattachement ou non à une BU transverse lorsqu’elle n’est pas précisée (afin par exemple que cela apparaisse clairement dans les KPIs et sachant que cette valeur devra tendre vers 0).

Applications owners et BU

Créer un tableau de correspondance des applications avec leurs owners et leur BU d’origine, pour faciliter l’automatisation du tagging (on n’a par exemple plus qu’à renseigner l’ID de l’application et le reste est complété automatiquement).

Typologie et rôle applicatif

Créer de même un tableau des typologies de services et du rôle applicatif joué (par exemple la création d’une base RDS sera automatiquement taggée “database”).

VPCs et environnements

Créer un tableau de correspondance des VPCs et des types d’environnement sachant qu’ils sont normalement distincts (ex : un composant créé sur le VPC de développement sera automatiquement taggé “Dev”).

Développement

Pour tout cela on peut coder ses propres scripts ou réutiliser des scripts déjà écrits (à venir dans cette section) mais il est bien entendu possible d'utiliser les outils des fournisseurs ou des CMP du marché.

Exemple de scripts open source pour le tagging dans AWS : Graffiti Monkey.