Datadog vs CloudWatch pour une PME AWS : quand payer un tiers, quand rester natif

CloudWatch est déjà là, activé par défaut, et déjà partiellement payé — chaque service AWS y pousse ses métriques de base gratuitement. Datadog, lui, s’installe volontairement, coûte tout de suite un forfait par hôte, et promet une expérience largement supérieure : dashboards unifiés, corrélation logs/métriques/traces, alerting plus fin, une UI que les équipes préfèrent unanimement à la console AWS. La question n’est donc pas « lequel est meilleur » — c’est « à partir de quand la différence d’expérience justifie l’écart de facture, et sur quel poste ça dérape vraiment ».

La réponse courte : ça dépend beaucoup moins du nombre de serveurs que de la densité de métriques custom par serveur — et c’est précisément l’inverse de l’intuition la plus répandue.

Deux philosophies de facturation, pas juste deux prix

CloudWatch facture à l’unité, brique par brique : par métrique custom, par Go de logs ingéré, par Go de logs stocké, par dashboard, par alarme, par requête d’API. Rien n’est inclus au-delà du free tier (10 métriques, 5 Go de logs, 3 dashboards, 10 alarmes, 1 M de requêtes API par mois). Chaque fonctionnalité s’active et se paie séparément — y compris l’équivalent APM, Application Signals, facturé au signal ingéré et non au serveur.

Datadog facture au forfait par hôte et par mois, avec un allotment inclus généreux : le plan Pro (15 $/hôte/mois en engagement annuel, 18 $ à la demande) inclut 100 métriques custom indexées par hôte. L’APM se paie en plus — soit en plan bundlé avec l’infra (35 $/hôte/mois pour APM Pro, infra incluse), soit en standalone. Les logs sont facturés à part : 0,10 $/Go ingéré, puis 1,70 $ par million d’événements indexés (ce qui les rend réellement interrogeables).

Cette différence structurelle — facturation à l’usage granulaire vs forfait par hôte avec allotment — explique pourquoi le “gagnant” dépend de votre ratio métriques/hôte, pas juste de votre nombre de serveurs.

Combien ça coûte, réellement

Prenons un profil PME SaaS B2B typique : 15 hôtes (mix EC2 + tâches ECS/Fargate comptées comme hôtes), 1 000 métriques custom applicatives, 50 Go de logs/mois, une trentaine d’alarmes, 5 dashboards.

Sur CloudWatch (tarifs officiels AWS) :

• Métriques custom : 990 métriques facturables (au-delà des 10 gratuites) × 0,30 $ = 297 $/mois
• Logs ingérés (standard) : 45 Go facturables × 0,50 $ = 22,50 $/mois
• Dashboards : 2 payants × 3 $ = 6 $/mois
• Alarmes : 30 facturables × 0,10 $ = 3 $/mois
• Total ≈ 330 $/mois, soit ≈ 300 €/mois — 3 650 €/an

Sur Datadog Pro, infra seule (sans APM), même profil :

• 15 hôtes × 15 $ = 225 $/mois
• Logs ingérés : 50 Go × 0,10 $ = 5 $/mois
• Métriques custom : 1 000 métriques tiennent dans l’allotment inclus (15 × 100 = 1 500) → 0 $ de dépassement
• Total ≈ 230 $/mois, soit ≈ 210 €/mois — 2 540 €/an

Sur ce profil précis, Datadog Infra Monitoring seul revient moins cher que CloudWatch — parce que l’allotment de métriques custom par hôte absorbe ce que CloudWatch facture à l’unité. C’est le point que la plupart des comparatifs ratent en s’arrêtant à « CloudWatch = natif = moins cher ».

Ajoutez l’APM (35 $/hôte/mois, infra incluse) et le calcul s’inverse brutalement : 15 × 35 $ + logs ≈ 530 $/mois, soit ≈ 490 €/mois — 5 850 €/an, près de deux fois le coût CloudWatch + Application Signals sur un volume de requêtes comparable (100 M de signaux golden mensuels ≈ 150 $/mois en mode par défaut, avant tout tracing X-Ray additionnel).

Ces chiffres sont des ordres de grandeur calculés à partir des grilles officielles AWS et Datadog au 28 août 2026 — hors indexation détaillée des logs, hors data transfer, hors remises volume négociées. Recalculez-les sur votre profil exact avant toute décision budgétaire.

Le vrai facteur de dérapage : la cardinalité, pas le nombre de serveurs

Le piège n’est presque jamais le prix affiché — c’est la façon dont chaque outil compte une “métrique”.

Chez Datadog, une métrique custom est définie par la combinaison nom + valeurs de tags, y compris le tag d’hôte. Ajouter un tag customer_id ou endpoint à une métrique existante peut multiplier son cardinal par le nombre de valeurs distinctes — une équipe qui tague ses métriques HTTP par route et par client peut passer de 100 à plusieurs milliers de métriques custom effectives sans avoir rien changé côté infra. Les histogrammes et distributions comptent chacun pour cinq métriques custom par combinaison. Et le dépassement d’allotment indexé (celui qui alimente réellement vos dashboards) n’a pas de tarif public : Datadog le fixe “selon votre contrat” — seul le dépassement côté ingestion est publié (0,10 $ par tranche de 100 métriques/mois).

Côté CloudWatch, le symétrique existe sous une autre forme : les alarmes en haute résolution (0,30 $/métrique/mois contre 0,10 $ en standard) et les alarmes à détection d’anomalies (facturées sur 3 métriques sous-jacentes, donc environ 0,30 $/mois chacune) s’accumulent vite si chaque micro-service embarque son propre jeu d’alarmes automatisées. Et l’indexation des logs CloudWatch reste basique par rapport à Datadog — pas de tiering intelligent natif équivalent aux exclusion filters ou au Flex Storage (0,05 $ par million d’événements stockés, hors index actif) de Datadog.

Le levier FinOps concret dans les deux cas : auditer la cardinalité de tags avant d’instrumenter, pas après avoir reçu la facture. Un tag request_id ou session_id posé sur une métrique custom, côté Datadog comme côté CloudWatch (Embedded Metric Format), est le classique qui fait passer une facture de 300 € à 3 000 €/mois sans qu’aucun humain n’ait “ajouté un serveur”.

Quand rester 100 % natif CloudWatch

• Stack mono-service ou peu de microservices, faible densité de métriques custom par hôte (moins d’une centaine).
• Équipe déjà à l’aise avec CloudWatch Logs Insights et les dashboards natifs, sans besoin de corrélation cross-signal poussée.
• Priorité : conformité budgétaire stricte et prévisibilité — la tarification à l’unité, bien maîtrisée, ne réserve pas de mauvaise surprise contractuelle.
• Pas de besoin de tracing distribué complexe, ou volume de requêtes suffisamment élevé pour qu’Application Signals (facturé au signal, pas à l’hôte) reste structurellement moins cher qu’un plan APM par hôte.
• Vous êtes strictement mono-cloud AWS et n’avez pas de besoin de dashboards unifiés multi-fournisseurs (Stripe, Vercel, GitHub Actions, etc.).

Quand Datadog devient pertinent

• Densité de métriques custom élevée par hôte (au-delà de l’allotment Datadog, il faut recalculer — mais en dessous, Datadog gagne souvent, contrairement à l’intuition).
• Stack multi-services distribuée (EKS, Lambda, ECS) où la corrélation logs/traces/métriques en un seul écran fait gagner un temps de MTTR mesurable — le vrai ROI de Datadog n’est presque jamais le prix, c’est le temps d’ingénieur économisé en incident.
• Besoin de dashboards unifiés multi-fournisseurs au-delà d’AWS (SaaS tiers, on-prem résiduel).
• Équipe SRE/Ops de petite taille (2-4 personnes) qui n’a pas le temps d’opérer manuellement l’écosystème CloudWatch (Logs Insights, Contributor Insights, Application Signals, X-Ray) et préfère une UX packagée.
• Vous avez déjà audité votre cardinalité de tags et savez que votre volume restera prévisible — sans cet audit préalable, le risque de dérapage contractuel côté indexation est réel des deux côtés.

Notre lecture

La question n’est presque jamais “Datadog ou CloudWatch” en bloc — c’est un arbitrage poste par poste : infra monitoring, logs, APM et alerting ont chacun leur propre point de bascule, et les mélanger dans une seule décision “on prend Datadog” ou “on reste 100 % AWS” fait perdre de l’argent dans un sens ou dans l’autre. Beaucoup de PME que nous auditons ont soit sur-souscrit un plan Datadog Enterprise pour des besoins Pro, soit accumulé des alarmes CloudWatch haute résolution qu’un simple standard suffirait à couvrir. Un audit DevSecOps ou une revue FinOps permet de faire ce calcul poste par poste sur votre volumétrie réelle avant de signer — ou de resigner — un contrat annuel.

Conclusion

CloudWatch et Datadog ne se comparent pas sur un seul chiffre. Sur une stack peu instrumentée, CloudWatch gagne nettement. Sur une stack avec une densité de métriques custom moyenne à élevée, l’allotment par hôte de Datadog peut inverser le résultat côté infra monitoring — l’APM, lui, reste structurellement le poste le plus cher chez Datadog dès qu’on le compare à un Application Signals bien dimensionné. La seule méthode fiable est de recalculer les deux grilles sur votre volumétrie exacte, poste par poste, avant de renouveler ou de résilier quoi que ce soit.

Sources : tarification Amazon CloudWatch, tarification Datadog, documentation Datadog — facturation des métriques custom, nouveautés AWS — CloudWatch Logs Infrequent Access.