Lorsque l’on déploie des ressources Azure, le tagging passe souvent au second plan. Les tags sont oubliés, partiels ou appliqués différemment selon les équipes, ce qui complique rapidement le suivi des coûts, la lisibilité et la gouvernance de la plateforme.
L’objectif de ce tutoriel est de montrer comment mettre en place un mécanisme simple pour appliquer automatiquement des tags standardisés dès la création des ressources, sans ajouter de contraintes aux déploiements existants.
Nous allons, pour cela, utiliser une Azure Function car cela permet de gérer l’évolutivité et la complexité des scénarios souvent présents au sein d’une plateforme d’intégration. Mais s’il ne s’agit que d’un besoin simple, le meilleur moyen pour l’adresser reste les Azure Policies qui permettent d’agir sur les ressources au moment de leur création (voir ce tutoriel).
Sans règles claires, les tags finissent vite par perdre leur utilité : noms différents pour un même concept, valeurs incohérentes ou informations manquantes selon les déploiements. Définir un socle commun permet d’avoir des ressources lisibles et exploitables, quel que soit l’outil ou l’équipe à l’origine du déploiement.
Ce tableau illustre un exemple de tags simples et largement suffisants pour démarrer :
| Nom du tag | Signification | Exemple de valeur |
| application | Application ou service porté par la ressource | catalog-api |
| environment | Environnement d’exécution | dev |
| owner | Équipe ou responsable de la ressource | azure-team |
Ces tags servent de base commune. Ils peuvent ensuite être enrichis ou adaptés en fonction des contraintes de gouvernance ou des usages internes. Cela ne remet pas en cause le mécanisme présenté dans ce tutoriel.
Le principe est volontairement simple : on calcule et applique automatiquement les tags au moment du déploiement, sans dépendre des pratiques des équipes ou des outils utilisés. Une fois en place, le mécanisme fonctionne de manière transparente et ne nécessite aucune action manuelle.
À chaque création de ressource Azure, un événement est émis. Cet événement déclenche un traitement centralisé qui génère les tags attendus et les applique immédiatement à la ressource concernée. Le déploiement peut ainsi rester focalisé sur l’infrastructure, tandis que le tagging est géré de façon systématique et homogène.
Un schéma unique permet d’illustrer cette chaîne de traitement :
Le mécanisme repose sur trois éléments :
Aucune logique n’est embarquée dans les templates de déploiement.
Le tagging est centralisé et automatique.
La fonction est déclenchée à chaque événement de création de ressource.
Son rôle est de :
Déclaration de la Function
Ce code définit une fonction déclenchée par Event Grid :
[Function("AutoTag")]
public async Task Run([EventGridTrigger] string eventGridEvent)
{
AzureResourceEvent resourceEvent =
JsonConvert.DeserializeObject<AzureResourceEvent>(eventGridEvent);
string resourceUri = resourceEvent.Data.ResourceUri;
_logger.LogInformation("Tagging resource {ResourceUri}", resourceUri);
string accessToken = await GetAccessTokenAsync();
await ApplyTagsAsync(resourceUri, accessToken);
}
Cette méthode ne fait qu’une chose : orchestrer le tagging.
Récupération du token Azure
La Function utilise l’identité managée pour appeler l’API Azure :
private async Task<string> GetAccessTokenAsync()
{
TokenRequestContext context =
new TokenRequestContext(
new[] { "https://management.azure.com/.default" });
AccessToken token = await _credential.GetTokenAsync(context);
return token.Token;
}
Ici, on n’utilise aucun secret, ni aucune clé : l’identité managée doit simplement avoir le rôle Contributor (ou équivalent) sur le périmètre ciblé.
Application des tags sur la ressource
C’est ici que les tags sont définis et appliqués :
private async Task ApplyTagsAsync(string resourceUri, string accessToken)
{
Dictionary<string, string> tags = new Dictionary<string, string>
{
{ "application", "demo-app" },
{ "environment", "dev" },
{ "owner", "cloud-team" }
};
var payload = new
{
tags = tags
};
string url = $"https://management.azure.com{resourceUri}?api-version=2022-09-01";
HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Patch, url);
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
request.Content = new StringContent(
JsonConvert.SerializeObject(payload),
Encoding.UTF8,
"application/json"
);
HttpResponseMessage response = await _httpClient.SendAsync(request);
response.EnsureSuccessStatusCode();
}
À ce stade, le code assure que :
Modèles de données Event Grid
Ces classes servent uniquement à lire l’événement :
public class AzureResourceEvent
{
public AzureResourceEventData Data { get; set; }
}
public class AzureResourceEventData
{
public string ResourceUri { get; set; }
}
Le System Topic permet de recevoir les événements liés aux ressources Azure :
{
"type": "Microsoft.EventGrid/systemTopics",
"apiVersion": "2022-06-15",
"name": "resource-events",
"location": "global",
"properties": {
"source": "/subscriptions/<subscription-id>",
"topicType": "Microsoft.Resources.Subscriptions"
}
}
Résultat : Ce topic écoute toutes les créations de ressources dans la souscription.
Cette souscription relie Event Grid à la fonction :
{
"type": "Microsoft.EventGrid/systemTopics/eventSubscriptions",
"apiVersion": "2022-06-15",
"name": "resource-events/autotag-subscription",
"properties": {
"destination": {
"endpointType": "AzureFunction",
"properties": {
"resourceId": "<function-app-resource-id>",
"functionName": "AutoTag"
}
},
"filter": {
"includedEventTypes": [
"Microsoft.Resources.ResourceWriteSuccess"
]
}
}
}
Résultat : à chaque création ou mise à jour réussie d’une ressource, la fonction est systématiquement appelée.
Créer une ressource Azure simple (par exemple un compte de stockage).
Puis vérifier les tags directement sur le portail, ou dans votre pipeline de déploiement via un simple script : az resource show --ids <resource-id> --query tags
Les tags définis dans la Function doivent apparaître automatiquement.
Ce que ce mécanisme apporte immédiatement
Le mécanisme présenté dans ce tutoriel constitue une base volontairement simple, mais il peut être enrichi sans remettre en cause l’architecture.
Plusieurs évolutions sont possibles selon les besoins des équipes :
Ces évolutions permettent d’adapter progressivement le tagging automatique au niveau de maturité de la gouvernance Azure, tout en conservant un point d’entrée unique et maîtrisé.