Étiquettes d'allocation des coûts : une norme d'étiquetage qui survit à l'export de facturation

Objectif

Répondre à « combien coûte le service X par mois, par environnement, par équipe » à partir de l'export de facturation du fournisseur, sans tableur manuel.

Prérequis

Une infrastructure définie en code pour la grande majorité des ressources ; un accord sur qui possède le reporting de coûts ; un accès à la console de facturation du compte payeur.

Étapes

1. Choisir un petit ensemble de clés obligatoires, typiquement service, environment, owner (l'équipe, pas une personne) et cost-center, plus une clé optionnelle component. Écrire les valeurs autorisées ; le texte libre fait échouer tout regroupement.
2. Fixer les règles d'orthographe. Le guide d'étiquetage d'AWS (cité) indique que les clés et valeurs d'étiquette sont sensibles à la casse, si bien que Environment=Prod et environment=prod forment deux catégories distinctes ; la documentation Azure (citée) traite les noms d'étiquette comme insensibles à la casse pour les opérations, mais les valeurs comme sensibles à la casse. Normaliser en minuscules partout, pour les clés comme pour les valeurs.
3. Activer les clés pour la facturation. Le guide de facturation AWS (cité) explique que les étiquettes définies par l'utilisateur et celles générées par AWS doivent chacune être activées séparément avant d'apparaître dans Cost Explorer ou le rapport d'allocation des coûts, que dans une organisation seul le compte de gestion a accès au gestionnaire d'étiquettes d'allocation des coûts, et que les étiquettes peuvent mettre jusqu'à 24 heures à apparaître dans la console de facturation. Le remplissage rétroactif des étiquettes pour des périodes passées est documenté comme une procédure distincte, donc activer les clés tôt plutôt que de compter dessus.
4. Appliquer les étiquettes via les étiquettes par défaut au niveau du fournisseur dans le code d'infrastructure, afin que chaque ressource créée par le code les porte ; ajouter les clés aux interfaces des modules pour qu'un module ne puisse pas être instancié sans propriétaire.
5. Imposer à la création par une politique : une règle de refus pour la création de ressource sans les clés obligatoires (politique d'organisation, Azure Policy, contrôle d'admission dans Kubernetes pour les volumes et équilibreurs de charge provisionnés dans le cloud).
6. Ne pas compter sur l'héritage : la documentation Azure (citée) indique que les ressources n'héritent pas des étiquettes appliquées à un groupe de ressources ou à un abonnement, donc étiqueter explicitement chaque ressource plutôt que de supposer que les enfants portent les étiquettes d'un parent ; les ressources partagées (passerelles NAT, transfert de données, plans de support) ne se rattachent jamais proprement à un seul service.
7. Chaque mois, exporter les coûts regroupés par les clés obligatoires, lister le reliquat non étiqueté par service, et soit étiqueter les ressources, soit répartir le coût partagé selon une règle écrite, soit l'accepter explicitement.

Résultat attendu

Un export de facturation dans lequel la part non étiquetée est faible et expliquée, et un coût par service que l'équipe propriétaire reconnaît comme le sien.

Limites et base de vérification

Les étiquettes ne couvrent pas les ressources créées hors du code ou par des services gérés pour le compte du client, et les frais qui ne sont rattachés à aucune ressource étiquetable restent dans le reliquat non étiqueté ; la page Azure citée note que tous les types de ressources ne prennent pas en charge les étiquettes. Le comportement du fournisseur suit la documentation citée ; aucun chiffre de coût n'est revendiqué.