Votre facture CloudWatch s'envole ? Le guide pratique de réduction des coûts pour Logs et Metrics

CloudWatch peut facilement passer du statut d’outil d’observabilité par défaut à celui de gouffre financier. En particulier après l’intégration de conteneurs, de microservices, de Lambda, d’API Gateway et de VPC Flow Logs, l’ingestion de Logs, la rétention des journaux, les Custom Metrics, les Alarms et les Dashboards augmentent simultanément. Pour réduire les coûts, la première étape ne consiste pas à supprimer la surveillance, mais à comprendre précisément où va l’argent.

Les tarifs suivants sont basés sur les prix publics généralement constatés dans us-east-1, les tarifs réels dépendant de votre région AWS actuelle : l’ingestion standard de CloudWatch Logs coûte généralement environ $0.50/GB, l’archivage des journaux environ $0.03/GB-month ; les requêtes Logs Insights environ $0.005/GB scanned ; les 10 000 premiers Custom Metrics environ $0.30/metric-month ; une alarm à résolution standard environ $0.10/alarm metric-month ; et un dashboard personnalisé environ $3/dashboard-month.

D’abord identifier : Logs ou Metrics, qu’est-ce qui coûte cher ?

Dans Cost Explorer, sélectionnez CloudWatch sous Service, puis regroupez par Usage type. Les postes de coûts élevés les plus courants comprennent :

• DataProcessing-Bytes : Ingestion des journaux.
• TimedStorage-ByteHrs : Rétention des journaux.
• MetricMonitorUsage : Métriques personnalisées.
• AlarmMonitorUsage : Alarmes.
• GMD-Metrics ou requêtes API : Requêtes GetMetricData.

De nombreuses équipes pensent que les dashboards coûtent cher, alors qu’en réalité, ce sont souvent l’ingestion de journaux ou les custom metrics à forte cardinalité qui pèsent sur la facture.

Logs Astuce 1 : Configurer la période de rétention

Par défaut, un CloudWatch Log Group peut conserver les données indéfiniment. Pour les journaux applicatifs, de nombreuses équipes n’ont besoin que de 7, 14, 30 ou 90 jours de recherche en ligne.

Lister globalement :

aws logs describe-log-groups \
  --query 'logGroups[*].[logGroupName,retentionInDays,storedBytes]' \
  --output table

Configurer la rétention :

aws logs put-retention-policy \
  --log-group-name /aws/ecs/prod-api \
  --retention-in-days 30

Il est recommandé de segmenter selon le type de journal : 90 jours pour les journaux d’erreurs en production, 14 à 30 jours pour les journaux applicatifs standards, 3 à 7 jours pour le débogage, et un transfert vers S3 pour la conservation à long terme des journaux d’audit et de conformité.

Logs Astuce 2 : Filtrer avant l’ingestion, pas après

La partie la plus coûteuse de CloudWatch Logs est généralement l’ingestion. Une fois les journaux entrés dans CloudWatch, l’utilisation de subscription filter ou de Logs Insights pour les filtrer ne permettra pas d’économiser sur les frais d’ingestion.

Le filtrage doit s’effectuer au niveau de l’application, du sidecar, de Fluent Bit ou d’OpenTelemetry Collector :

[FILTER]
    Name   grep
    Match  app.*
    Exclude log ^.*healthcheck.*$

Éliminez en priorité les journaux fréquents et à faible valeur, tels que les health check, les requêtes 200 sur ressources statiques, les logs de debug redondants ou les payloads trop volumineux. Configurer le niveau par défaut sur INFO en production, et passer temporairement à DEBUG pour le dépannage, s’avère bien plus économique que de conserver le debug complet en continu.

Logs Astuce 3 : Nettoyer les Log Groups inutilisés

Après la suppression de ressources Lambda, ECS, API Gateway ou Step Functions, les log groups associés ne sont pas toujours automatiquement supprimés. Vous pouvez identifier les groupes sans écriture depuis longtemps :

aws logs describe-log-groups \
  --query 'logGroups[?storedBytes>`0`].[logGroupName,storedBytes,retentionInDays]' \
  --output table

Vérifiez ensuite si le groupe est toujours actif à l’aide de lastEventTimestamp. Avant toute suppression, il est conseillé de l’exporter vers S3 pour éviter de perdre des données de conformité.

Logs Astuce 4 : Intégrer avec prudence les journaux à fort volume

Les VPC Flow Logs, ALB Access Logs, WAF Logs et CloudFront Logs peuvent atteindre des volumes considérables. Évitez de tout envoyer par défaut vers CloudWatch.

Une approche plus courante consiste à :

• Envoyer les journaux de dépannage à court terme vers CloudWatch.
• Stocker les journaux d’accès à long terme dans S3.
• Utiliser Athena pour interroger les données historiques.
• Échantillonner uniquement les champs nécessaires pour les VPC Flow Logs, ou ne les activer que pour les subnets ou ENI critiques.

Le duo S3 + Athena offre une expérience interactive moins fluide que CloudWatch Logs, mais le coût de rétention à long terme est nettement inférieur, ce qui convient particulièrement aux requêtes d’audit peu fréquentes.

Logs Astuce 5 : Envisager des alternatives complémentaires

Si le point de friction majeur concerne les coûts d’ingestion et de stockage de CloudWatch Logs, vous pouvez évaluer des alternatives. Par exemple, S4 Logs est une solution alternative optimisée pour les coûts de CloudWatch Logs, idéale pour les volumes importants, les longues périodes de rétention, et lorsque les capacités de requête natives de CloudWatch ne constituent pas une exigence absolue.

Cela ne doit pas être vu comme un remplacement systématique de CloudWatch. Si vos équipes dépendent fortement de Logs Insights, de CloudWatch Alarm et de vos processus opérationnels actuels, le coût de migration doit être pris en compte. Une approche pragmatique consiste à choisir un log group à fort trafic et à faible risque pour un projet pilote, puis à utiliser un calculateur d’économies pour estimer les gains potentiels.

Metrics Astuce 1 : Contrôler la cardinalité

Le risque majeur avec les Custom Metrics réside dans la forte cardinalité. CloudWatch facture selon la combinaison de namespace, metric name et dimension. Une structure de dimensions comme celle-ci est particulièrement risquée :

MetricName=Latency
Dimensions=service, endpoint, customer_id, pod_id, request_id

Si customer_id compte 10 000 valeurs et endpoint en compte 50, les combinaisons théoriques explosent rapidement. Il est plus sûr de ne conserver que les dimensions réellement indispensables au dépannage et aux alertes :

MetricName=LatencyP95
Dimensions=service, endpoint, environment

Les champs à forte cardinalité comme pod_id ou request_id ont davantage leur place dans les journaux ou les traces, et ne devraient pas servir de dimensions pour les CloudWatch custom metrics.

Metrics Astuce 2 : Agréger avant de publier

Évitez d’appeler directement PutMetricData pour chaque instance, locataire (tenant) ou interface. Privilégiez une agrégation au niveau applicatif ou du collecteur, par exemple en publiant toutes les 60 secondes des valeurs comme p50/p95/p99, count ou error_count.

L’API PutMetricData elle-même engendre des frais de requête, généralement de l’ordre de $0.01/1,000 requests. Passer d’un intervalle de publication de 10 secondes à 60 secondes n’affectera pas la plupart de vos alertes métier, tout en réduisant considérablement le nombre de requêtes API et de métriques générées.

Metrics Astuce 3 : Utiliser correctement le format EMF

L’Embedded Metric Format (EMF) permet d’extraire des métriques à partir de journaux structurés, facilitant ainsi la corrélation entre logs et métriques. Cependant, l’EMF ne fournit pas de métriques gratuites. Il génère toujours des frais d’ingestion de journaux et peut également occasionner des coûts de custom metrics.

Lors de l’utilisation d’EMF, veillez à :

• Ne pas inclure user_id, order_id ou container_id dans les dimensions.
• Limiter le nombre de namespaces.
• Agréger les événements à haute fréquence avant de générer l’EMF.
• Contrôler régulièrement le nombre de unique metrics réellement créées.

Metrics Astuce 4 : Rationaliser les alarmes et les Dashboards

Une erreur courante consiste à configurer une alarm pour chaque combinaison de dimensions, ce qui aboutit à des milliers d’alarmes. Il est recommandé de :

• Créer un nombre restreint d’alarmes agrégées pour les SLO critiques.
• Utiliser les dashboards ou les journaux pour analyser les détails.
• Utiliser des composite alarms pour regrouper les alertes associées et limiter le bruit.
• Supprimer les dashboards inutilisés.

Le prix unitaire d’un dashboard n’est pas forcément élevé, mais les rafraîchissements automatiques fréquents entraînent des coûts via l’API GetMetricData, notamment pour les écrans de contrôle (monitoring walls) et les systèmes de scrutation.

Quand envisager S4 Metrics ?

Si le problème principal de CloudWatch Custom Metrics réside dans les coûts liés à la forte cardinalité, et que votre activité requiert impérativement de conserver des métriques à grain fin, vous pouvez évaluer des alternatives comme S4 Metrics. Son but est de réduire les coûts liés à la cardinality des indicateurs personnalisés CloudWatch, sans pour autant remplacer l’intégralité de votre système d’observabilité. Il convient de démarrer par des tests A/B sur des namespaces non critiques ou sur les familles de métriques les plus onéreuses.

Un plan d’action sur 7 jours

Jour 1 : Identifier le Top usage type de CloudWatch via Cost Explorer. Jour 2 : Lister la taille et la retention de tous les log groups. Jour 3 : Remplacer la rétention indéfinie par défaut par une rétention par paliers de 7, 14, 30 ou 90 jours. Jour 4 : Filtrer les journaux à faible valeur en amont dans Fluent Bit ou OTel Collector. Jour 5 : Rediriger les journaux à long terme vers S3 + Athena. Jour 6 : Exporter la liste des custom metrics et éliminer les dimensions à forte cardinalité. Jour 7 : Évaluer la pertinence d’un projet pilote pour des alternatives telles que S4 Logs ou S4 Metrics.

Le principe de la réduction des coûts CloudWatch est simple : conserver les signaux à haute valeur, bloquer le bruit à faible valeur dès l’entrée, et transférer les données nécessitant un archivage à long terme vers des systèmes de stockage plus adaptés.

Divulgation : L’auteur de cet article fait partie de abyo software (le développeur de S4, un produit d’optimisation des coûts disponible sur l’AWS Marketplace).