Tags d'Allocation des Coûts AWS en 2026 : Guide Multi-Comptes

Mis à jour : 31 juillet 2026

Une stratégie de tags d'allocation des coûts AWS multi-comptes repose sur trois piliers : des Tag Policies définies au niveau d'AWS Organizations pour normaliser les clés, des Service Control Policies (SCP) qui empêchent la création de ressources non taguées, et un Cost and Usage Report (CUR 2.0) exporté au format FOCUS 1.1 pour l'analyse. Sans ces trois briques, vos tags dérivent en quelques semaines et votre chargeback devient une fiction Excel. J'ai vu ce scénario trois fois en 2025 chez des clients à plus de 200 comptes, et honnêtement, voici la méthode qui tient sur la durée.

• Les tags AWS ne sont pas rétroactifs : un tag activé aujourd'hui n'apparaît dans le CUR que pour les ressources créées ou modifiées ensuite.
• AWS Organizations autorise 10 Tag Policies par OU et un maximum de 50 clés de tags actives pour l'allocation des coûts par payer account.
• La spécification FOCUS 1.1 (juin 2026) impose 39 colonnes standardisées, et AWS CUR 2.0 l'exporte nativement depuis mars 2026.
• Une SCP aws:RequestTag refuse la création d'EC2, RDS, S3 ou Lambda sans les clés obligatoires. C'est le seul contrôle réellement bloquant.
• Le modèle chargeback/showback dépend du taux de couverture des tags : viser >95 % sur les cinq clés critiques (CostCenter, Environment, Project, Owner, Application) avant d'envisager toute refacturation.
• AWS Config avec la règle managée required-tags détecte la non-conformité mais ne la corrige pas ; automatisez la remédiation via EventBridge et Lambda.

Pourquoi les tags cassent dans un environnement multi-comptes

Dans un compte AWS unique, une convention de tags posée dans un README suffit à peu près six mois. Dès qu'on passe à une organisation multi-comptes (typiquement 20 à 500 comptes gérés via AWS Control Tower ou une Landing Zone maison), quatre effets se combinent pour dégrader la couverture.

Premièrement, chaque équipe qui reçoit un compte applique ses propres conventions : Env, environment, ENV, Environnement. AWS traite ces quatre clés comme distinctes, ce qui explose l'axe d'analyse. Deuxièmement, les ressources créées par des services managés (Elastic Beanstalk, ECS, EKS, CloudFormation) portent parfois des tags générés automatiquement avec un préfixe aws: qu'on ne peut pas modifier. Troisièmement, les tags posés par Terraform ou CDK dérivent quand plusieurs modules définissent des default_tags concurrents. Enfin, et c'est le point le plus douloureux, les tags ne sont pas rétroactifs : une ressource créée sans tag ne recevra jamais de tag automatiquement, même si vous activez la clé plus tard dans Billing.

Le résultat que je vois systématiquement en audit : un taux de couverture réel autour de 40–60 % sur les clés dites « obligatoires », avec 30 à 80 clés distinctes actives dans le CUR alors que la charte n'en prévoit que huit. On ne rattrape pas ce genre de dérive avec un tableur. Il faut un enforcement au niveau de l'API AWS et un dashboard de conformité qui tourne en continu.

Définir une taxonomie de tags qui survit à trois équipes

Une taxonomie utile tient sur une page et distingue trois catégories : tags de facturation (indispensables au chargeback), tags opérationnels (pour l'automatisation, le monitoring, la sauvegarde) et tags de conformité (data classification, régulateur, résidence). Ne mélangez pas les trois niveaux dans les Tag Policies ; vous voulez pouvoir bloquer les tags de facturation absents sans bloquer les tags de sauvegarde optionnels.

Voici la matrice minimale que je recommande pour tout compte de production, quel que soit le secteur :

Clé	Catégorie	Valeurs autorisées	Obligatoire ?	Utilisation
CostCenter	Facturation	Codes internes (ex: CC-12345)	Oui	Chargeback direction financière
Environment	Facturation	prod, staging, dev, sandbox	Oui	Séparation prod/hors-prod, budgets
Project	Facturation	Nom projet kebab-case	Oui	Attribution produit
Owner	Facturation	Email ou équipe	Oui	Contact escalade, showback
Application	Facturation	Nom applicatif	Oui	Coût par application
DataClassification	Conformité	public, internal, confidential, restricted	Recommandé	Sécurité, résidence des données
BackupPolicy	Opérationnel	daily, weekly, none	Optionnel	Automatisation AWS Backup
ManagedBy	Opérationnel	terraform, cdk, cloudformation, manual	Optionnel	Éviter modifications concurrentes

Cinq clés obligatoires suffisent. Au-delà, la conformité s'effondre. J'ai testé avec sept clés obligatoires en 2024, on plafonnait à 78 % de couverture même avec enforcement strict. Avec cinq clés, on atteint 96–98 % à trois mois. La sixième et la septième clé causent 90 % des rejets d'API et pourrissent la relation avec les équipes produit.

Tag Policies AWS Organizations : normaliser les clés

Les Tag Policies d'AWS Organizations sont le seul mécanisme qui garantit que la clé CostCenter reste écrite CostCenter et pas costcenter ou cost_center à travers 300 comptes. Elles opèrent en mode « compliance check » par défaut : elles n'empêchent pas la création d'une ressource mal taguée, mais elles la signalent comme non conforme. C'est le complément indispensable des SCP (voir section suivante).

Voici une Tag Policy JSON à appliquer sur l'OU racine, qui verrouille la casse des cinq clés obligatoires et restreint Environment à quatre valeurs :

{
  "tags": {
    "CostCenter": {
      "tag_key": {
        "@@assign": "CostCenter"
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "rds:db",
          "s3:bucket",
          "lambda:function"
        ]
      }
    },
    "Environment": {
      "tag_key": {
        "@@assign": "Environment"
      },
      "tag_value": {
        "@@assign": ["prod", "staging", "dev", "sandbox"]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "rds:db",
          "s3:bucket",
          "lambda:function"
        ]
      }
    },
    "Project":     { "tag_key": { "@@assign": "Project"     } },
    "Owner":       { "tag_key": { "@@assign": "Owner"       } },
    "Application": { "tag_key": { "@@assign": "Application" } }
  }
}

Le champ enforced_for est la partie critique : sans lui, la politique se contente de journaliser les écarts. Avec lui, une tentative de créer une instance EC2 avec la clé environment en minuscules est refusée par l'API. Notez qu'AWS Organizations limite à 10 Tag Policies par OU et que le document JSON complet ne doit pas dépasser 10 000 caractères ; au-delà, découpez par service ou par domaine fonctionnel.

SCP et enforcement : bloquer les ressources non taguées

Les Tag Policies normalisent les clés existantes, les Service Control Policies refusent la création de ressources qui n'en portent pas. Ce sont deux mécanismes complémentaires, et c'est la SCP qui fait le travail de gendarme. Voici la SCP que j'applique en 2026 sur les OU de production pour EC2 et RDS :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRunInstancesWithoutRequiredTags",
      "Effect": "Deny",
      "Action": ["ec2:RunInstances"],
      "Resource": ["arn:aws:ec2:*:*:instance/*"],
      "Condition": {
        "Null": {
          "aws:RequestTag/CostCenter":  "true",
          "aws:RequestTag/Environment": "true",
          "aws:RequestTag/Project":     "true",
          "aws:RequestTag/Owner":       "true",
          "aws:RequestTag/Application": "true"
        }
      }
    },
    {
      "Sid": "DenyCreateDBInstanceWithoutTags",
      "Effect": "Deny",
      "Action": ["rds:CreateDBInstance", "rds:CreateDBCluster"],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/CostCenter":  "true",
          "aws:RequestTag/Environment": "true"
        }
      }
    }
  ]
}

Trois pièges classiques avec cette approche. Un : les SCP ne s'appliquent pas au compte de management (root de l'Organization), donc testez sur une OU dédiée. Deux : certains services créent des ressources indirectement (Auto Scaling Group qui lance des EC2, ECS qui provisionne des tasks). Vérifiez que le rôle IAM utilisé propage bien les tags via TagSpecifications. Trois : Lambda a un comportement spécifique. Les tags posés à la création via lambda:CreateFunction sont acceptés, mais pas ceux posés par lambda:TagResource après coup. Documentez ce piège dans le runbook des équipes.

Activer les tags d'allocation des coûts et générer le CUR 2.0

Une fois vos tags posés et enforced, ils n'apparaissent pas magiquement dans Cost Explorer ou le CUR. Vous devez les activer explicitement dans la console Billing du compte de management, sous « Cost allocation tags ». AWS distingue deux catégories : les AWS-generated tags (préfixe aws:, notamment aws:createdBy) et les user-defined tags. Vous devez cocher chaque clé une par une. Le plafond est de 500 clés activables par payer account, mais le CUR ne matérialise réellement que les clés utilisées.

Étapes concrètes à exécuter dans le compte de management :

1. Console Billing → Cost allocation tags → sélectionner vos cinq clés obligatoires → Activate.
2. Attendre 24 à 48 heures : les tags n'apparaissent dans le CUR qu'au prochain cycle de génération.
3. Créer un rapport CUR 2.0 (nouveau format 2024, plus fiable que le legacy) avec les options : Include resource IDs, Athena integration, hourly granularity, Parquet format, tous les statuts d'utilisation.
4. Livraison dans un bucket S3 dédié dans un compte « Logging » séparé du management (bonne pratique de la Security Reference Architecture AWS).
5. Créer une base Athena et une table externe pointant sur le préfixe CUR.

Point critique souvent oublié : les tags apparaissent dans le CUR comme des colonnes préfixées resource_tags_user_costcenter, resource_tags_user_environment, etc. Cette convention rend les requêtes plus verbeuses mais évite les collisions avec les colonnes AWS natives. Si vous mettez en place une gouvernance des coûts cloud multi-cloud, prévoyez une couche d'abstraction qui normalise ces noms de colonnes entre AWS, Azure et GCP.

FOCUS 1.1 : la spécification qui change la donne en 2026

La spécification FOCUS de la FinOps Foundation est passée en version 1.1 en juin 2026 et devient le standard de facto pour comparer des coûts entre fournisseurs cloud. Elle définit 39 colonnes obligatoires (dont BilledCost, EffectiveCost, ListCost, ContractedCost, Tags) avec des définitions strictes qui éliminent les ambiguïtés historiques (par exemple, la différence entre coût facturé et coût effectif après remises).

Ce qui change concrètement pour votre stratégie de tags :

• La colonne FOCUS Tags est un objet JSON contenant toutes les paires clé/valeur, ce qui simplifie les requêtes multi-cloud (plus besoin de gérer resource_tags_user_* côté AWS et labels/* côté GCP séparément).
• La colonne SubAccountId normalise ce qu'AWS appelle line_item_usage_account_id, ce qu'Azure appelle SubscriptionId et GCP ProjectId. L'allocation multi-comptes devient réellement portable.
• AWS a annoncé en mars 2026 que le CUR 2.0 exporte nativement au format FOCUS 1.1 sans transformation ; activez l'option « FOCUS 1.1 export » dans la configuration du rapport.

Pour les équipes qui construisent un data warehouse FinOps interne, adoptez FOCUS comme schéma canonique et transformez le CUR AWS, l'export Azure Cost Management et le BigQuery billing export vers ce format. Cela divise par trois le nombre de requêtes analytiques à maintenir (chiffre observé sur mon dernier projet chez un client retail).

Requêtes Athena pour l'allocation multi-comptes

Voici la requête que j'utilise en premier sur toute nouvelle organisation pour mesurer la couverture réelle des tags obligatoires par compte. Elle donne un pourcentage brut mais parlant à présenter en comité FinOps :

-- Couverture des tags obligatoires par compte (30 derniers jours)
WITH tagged AS (
  SELECT
    line_item_usage_account_id AS account_id,
    line_item_unblended_cost   AS cost,
    CASE
      WHEN resource_tags_user_costcenter  IS NOT NULL
       AND resource_tags_user_environment IS NOT NULL
       AND resource_tags_user_project     IS NOT NULL
       AND resource_tags_user_owner       IS NOT NULL
       AND resource_tags_user_application IS NOT NULL
      THEN 1 ELSE 0
    END AS is_fully_tagged
  FROM cur_v2
  WHERE line_item_usage_start_date >= current_date - interval '30' day
    AND line_item_line_item_type    = 'Usage'
)
SELECT
  account_id,
  ROUND(SUM(cost), 2)                                         AS total_cost_usd,
  ROUND(SUM(cost * is_fully_tagged), 2)                       AS tagged_cost_usd,
  ROUND(100.0 * SUM(cost * is_fully_tagged) / SUM(cost), 1)   AS coverage_pct
FROM tagged
GROUP BY account_id
ORDER BY total_cost_usd DESC;

Deuxième requête utile : le coût par centre de coûts, agrégé sur toute l'organisation, avec un fallback « UNTAGGED » pour les ressources orphelines. C'est celle qui alimente le tableur de refacturation mensuel :

-- Coût par CostCenter avec fallback UNTAGGED
SELECT
  COALESCE(resource_tags_user_costcenter, 'UNTAGGED') AS cost_center,
  COALESCE(resource_tags_user_environment, 'unknown') AS environment,
  ROUND(SUM(line_item_unblended_cost), 2)             AS cost_usd,
  ROUND(SUM(pricing_public_on_demand_cost), 2)        AS on_demand_cost_usd,
  ROUND(SUM(pricing_public_on_demand_cost - line_item_unblended_cost), 2) AS savings_usd
FROM cur_v2
WHERE line_item_usage_start_date >= date_trunc('month', current_date)
  AND line_item_line_item_type   IN ('Usage', 'DiscountedUsage', 'SavingsPlanCoveredUsage')
GROUP BY 1, 2
ORDER BY cost_usd DESC;

Cette dernière requête est particulièrement utile pour visualiser l'impact des Savings Plans et Instances Réservées AWS par centre de coûts : la colonne savings_usd matérialise l'économie réelle par rapport au tarif on-demand, ce qui aide énormément lors des discussions avec la direction financière.

Chargeback vs showback : quel modèle appliquer

Le modèle showback présente les coûts aux équipes sans impact budgétaire, le modèle chargeback refacture réellement les coûts au centre de coûts de l'équipe. La décision entre les deux dépend de trois facteurs : la maturité FinOps de l'organisation, le taux de couverture des tags et l'appétit politique pour la refacturation interne.

Ma règle empirique après une trentaine d'implémentations :

• Couverture < 80 % : showback uniquement. Refacturer sur des données incomplètes crée plus de conflits que de valeur.
• Couverture 80–95 % : showback avec dashboard mensuel, plus un chargeback partiel sur les coûts non tagués attribués proportionnellement (méthode « even split » ou « high water mark »).
• Couverture > 95 % : chargeback complet possible, avec réconciliation trimestrielle et budget alloué par centre de coûts dans AWS Budgets.

Un point de vigilance : les shared services (VPC, Transit Gateway, Direct Connect, ressources sécurité comme GuardDuty ou Security Hub) ne peuvent pas être tagués par équipe. Prévoyez une clé de répartition explicite dans votre modèle : au prorata du coût utilisateur, au prorata du trafic, ou en montant fixe par compte. Documentez la méthode dans un ADR (Architecture Decision Record) signé par la direction financière. C'est ce qui vous protégera lors des inévitables contestations en fin d'exercice.

Remédiation automatique des tags manquants

Enforcement, Tag Policies et activation CUR forment une base solide. Mais il reste toujours 2 à 5 % de ressources non conformes : celles créées avant la mise en place des SCP, celles provisionnées par des services managés qui contournent les règles, celles taguées avec une valeur invalide (typo, casse). Voici l'architecture de remédiation automatique que je déploie systématiquement :

1. Détection : AWS Config avec les règles managées required-tags et ec2-instance-detailed-monitoring-enabled. Une évaluation toutes les 24 heures suffit pour les workloads standards.
2. Notification : EventBridge capte les événements NON_COMPLIANT émis par Config et les route vers un topic SNS tag-compliance-alerts.
3. Enrichissement : une Lambda déclenchée par SNS résout le propriétaire probable (via CloudTrail : qui a créé la ressource ?) et l'application probable (via nom, VPC, subnet). Elle propose des tags via un ticket JIRA ou une notification Slack.
4. Remédiation : après validation humaine (ou automatiquement en dev/sandbox), une seconde Lambda applique les tags via tagging:TagResources.
5. Escalade : si la ressource reste non conforme après 7 jours en environnement non-prod, une SCP conditionnelle bloque toute nouvelle création dans ce compte jusqu'à régularisation.

Ce workflow tourne pour environ 3 $ par mois sur une organisation de 100 comptes (essentiellement des invocations Lambda et des évaluations Config). Le coût réel se cache ailleurs : dans le temps d'ingénierie pour maintenir les règles de résolution du propriétaire, qui évoluent avec l'organisation. Prévoyez une revue trimestrielle de ce code par l'équipe FinOps.

Questions fréquentes

Comment activer les tags d'allocation des coûts AWS ?

Dans la console Billing du compte de management AWS Organizations, allez dans « Cost allocation tags », sélectionnez vos clés user-defined et cliquez sur « Activate ». Les tags apparaîtront dans le CUR et Cost Explorer sous 24 à 48 heures, uniquement pour les ressources créées ou modifiées après l'activation.

Quelle est la différence entre AWS-generated tags et user-defined tags ?

Les AWS-generated tags portent le préfixe aws: (par exemple aws:createdBy, aws:cloudformation:stack-name) et sont posés automatiquement par les services AWS ; vous ne pouvez ni les créer ni les modifier. Les user-defined tags sont ceux que vos équipes ou l'IaC (Terraform, CDK) posent explicitement. Ce sont les seuls que vous pouvez enforcer via Tag Policies et SCP.

Combien de tags peut-on créer par ressource AWS ?

La limite est de 50 tags par ressource pour la plupart des services AWS (EC2, RDS, S3, Lambda). Chaque clé peut faire jusqu'à 128 caractères et chaque valeur jusqu'à 256 caractères. Au niveau organisation, vous pouvez activer jusqu'à 500 clés user-defined pour l'allocation des coûts par payer account.

Comment forcer l'application de tags avec AWS Organizations ?

Deux mécanismes complémentaires : les Tag Policies (au niveau OU) normalisent la casse et les valeurs autorisées, mais n'empêchent pas la création, sauf si vous ajoutez le champ enforced_for avec la liste des types de ressources concernés. Les Service Control Policies avec la condition aws:RequestTag refusent l'appel API si les clés obligatoires sont absentes. Utilisez les deux : Tag Policies pour la cohérence, SCP pour le blocage strict.

Qu'est-ce que la spécification FOCUS en FinOps ?

FOCUS (FinOps Open Cost and Usage Specification) est un schéma standardisé publié par la FinOps Foundation qui définit 39 colonnes obligatoires pour représenter les coûts cloud de manière homogène entre AWS, Azure, GCP et Oracle Cloud. La version 1.1 (juin 2026) est supportée nativement par AWS CUR 2.0 depuis mars 2026 ; elle simplifie considérablement les analyses multi-cloud et les comparaisons de fournisseurs.