Services Projets Tarifs Blogue À propos Appel gratuit →
Blogue

CloudWatch Logs : une rétention unique pour tout le compte

AWS permet de fixer la durée de conservation des journaux pour tout un compte. Ce que ça change à la facture, les pièges à éviter et comment l’essayer.

6 min de lectureInfonuagiqueCoûts infonuagiques

Le 9 novembre 2026, AWS a annoncé les politiques de rétention au niveau du compte pour Amazon CloudWatch Logs. Une seule politique peut maintenant fixer la durée de conservation de tous les groupes de journaux d’un compte, ou seulement de ceux dont le nom commence par un préfixe donné. Pour une équipe SaaS dont la facture d’infonuagique grimpe sans qu’on sache pourquoi, c’est un levier simple. C’est aussi un levier qui supprime des données pour de bon. Voici ce qui a changé, qui est concerné et ce qu’on vérifie d’abord.

Pourquoi les journaux coûtent-ils de plus en plus cher?

Par défaut, les données de journaux sont conservées indéfiniment dans CloudWatch Logs, sauf si vous configurez une durée pour chaque groupe de journaux. Or, beaucoup de services, dont Lambda, créent leurs propres groupes. Si personne ne règle la durée au moment de la création, le stockage ne fait que croître.

La page de tarification de CloudWatch facture l’ingestion et le stockage séparément. Dans ses exemples pour les régions US East, AWS utilise 0,50 $ US par Go pour l’ingestion en classe Standard (N. Virginia) et 0,03 $ US par Go-mois pour le stockage archivé, (dans l’exemple d’AWS, sur la taille compressée). Ces exemples sont illustratifs et les prix varient selon la région : vérifiez les tarifs de ca-central-1 avant de calculer quoi que ce soit.

Le stockage est donc un coût qui s’accumule : plus la durée est longue, plus le volume conservé en régime établi est grand.

Qu’est-ce qu’AWS a annoncé exactement?

Selon l’annonce du 9 novembre 2026 et le guide CloudWatch Logs, en novembre 2026 :

  • Une politique s’applique à tous les groupes du compte ou à ceux dont le nom commence par un préfixe, par exemple /aws/lambda. Seuls les préfixes sont pris en charge.
  • Elle fixe une durée en jours. Les valeurs permises vont de 30 à 3 653 jours (30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1 096, 1 827, 2 192, 2 557, 2 922, 3 288, 3 653), ou NEVER_EXPIRE. Le minimum est de 30 jours.
  • Le mode d’application est RETROACTIVE (groupes existants et nouveaux) ou NEW_ONLY (seulement les groupes créés après la politique).
  • On peut créer jusqu’à 20 politiques par région. Elles se chevauchent : si plusieurs s’appliquent au même groupe, c’est la durée la plus longue qui l’emporte, et NEVER_EXPIRE compte comme la plus longue.
  • La fonctionnalité est offerte sans frais supplémentaires dans toutes les régions commerciales, sauf Moyen-Orient (Bahreïn) et Moyen-Orient (EAU). Les régions canadiennes y sont donc incluses.

D’après la documentation de PutAccountPolicy, les politiques de compte sont propres à une région : il faut créer la politique dans chaque région où vous avez des journaux.

Quel est le piège principal?

La documentation est claire : une politique de compte remplace la durée réglée sur le groupe, même si celle du groupe est plus longue. Son exemple : un groupe configuré pour 10 ans, auquel on applique une politique de 90 jours, perd les événements de plus de 90 jours.

Pensez aux journaux d’audit, aux preuves de contrôle pour une certification ou aux journaux qu’une obligation légale vous demande de garder. Une politique trop large peut les supprimer. La solution est la politique plus longue sur un préfixe précis : puisque la durée la plus longue l’emporte, une politique de 365 jours sur /security l’emporte sur une durée de base de 90 jours pour tout le compte.

Deux détails de plus tirés de la documentation :

  • La politique prend effet 24 heures après sa création ou sa modification.
  • CloudWatch ne supprime pas les événements à la seconde près. La suppression prend habituellement jusqu’à 72 heures après l’échéance, mais les événements échus cessent d’être facturés dès qu’ils sont marqués pour suppression.

Comment l’essayer en toute sécurité cette semaine?

  1. Faites l’inventaire. Dressez la liste de vos groupes de journaux par volume stocké. L’opération PutAccountPolicy avec dryRun renvoie aussi les 20 groupes qui stockent le plus de données dans la portée de la politique.
  2. Classez les journaux. Distinguez ce qui sert au débogage (quelques semaines suffisent souvent) de ce qui sert à l’audit, à la sécurité ou à une obligation légale.
  3. Faites un essai à blanc. Ajoutez --dry-run à la commande. Le résultat indique combien de groupes verraient leur durée augmenter, diminuer ou rester inchangée. Rien n’est créé.
  4. Commencez par un préfixe, pas par tout le compte. Par exemple /aws/lambda avec 90 jours.
  5. Protégez les exceptions. Créez une politique plus longue, ou NEVER_EXPIRE, pour les préfixes à conserver.
  6. Surveillez la facture. Comparez le stockage de journaux dans Cost Explorer avant et après. Les données échues disparaissent dans les jours qui suivent la prise d’effet, et la facture le reflète au fil du mois de facturation.

Voici la commande de la documentation pour un essai à blanc :

aws logs put-account-policy \
  --policy-name LambdaRetentionPolicy \
  --policy-type RETENTION_POLICY \
  --policy-document '{"retentionInDays": 90, "enforcementMode": "RETROACTIVE"}' \
  --selection-criteria 'LogGroupNamePrefix="/aws/lambda"' \
  --dry-run

Qui devrait s’y intéresser, et qui peut passer son tour?

Cette fonction intéresse les équipes qui ont des dizaines de groupes créés par des fonctions, des conteneurs ou des pipelines, et qui n’ont jamais fixé de durée. Elle intéresse aussi celles qui doivent démontrer une durée de conservation constante lors d’une vérification.

Si vous n’avez que quelques groupes déjà bien configurés, ou si vos journaux sont surtout envoyés ailleurs, le gain sera mince. Sachez aussi que les droits requis (logs:PutAccountPolicy et logs:PutRetentionPolicy) devraient être réservés aux administrateurs : une seule politique peut toucher tous les groupes du compte.

Qu’est-ce qu’on vérifie en premier?

Nous commençons par la question qui précède le coût : combien de temps chaque type de journal doit-il vraiment être gardé, et pourquoi? Pour une entreprise assujettie à la Loi 25, les journaux contiennent souvent des renseignements personnels : la durée de conservation est alors aussi une décision de gouvernance, à vérifier avec votre responsable de la protection des renseignements personnels, pas seulement avec la facture. Ensuite, nous faisons l’essai à blanc, nous protégeons les journaux d’audit et nous appliquons la politique par étapes. Si vous voulez de l’aide pour plafonner la facture d’infonuagique sans rien casser, consultez nos services ou l’option CTO fractionnel.

Ce billet est de l’information générale, pas un avis juridique, de sécurité ou financier. Les prix et les fonctions changent : vérifiez-les dans la documentation d’AWS avant de décider.