Qu’est-ce que CloudWatch ?
Amazon CloudWatch est le service de supervision d’AWS. Il collecte trois types de données produites par les ressources cloud : des métriques chiffrées (charge processeur, nombre de requêtes, latence), des journaux applicatifs et système, et des événements signalant un changement d’état.
Sur ces données, on pose des alarmes. Quand un seuil est franchi pendant une durée définie, CloudWatch prévient une équipe ou déclenche une action automatique, par exemple l’ajout d’une instance.
Le service est activé par défaut sur la plupart des ressources AWS, ce qui explique qu’on le rencontre dès le premier projet, souvent sans l’avoir choisi.
À quoi sert CloudWatch ?
CloudWatch répond à trois questions du quotidien : est-ce que ça tourne, est-ce que c’est lent, et qu’est-ce qui s’est passé à 3 h 12 cette nuit.
- Suivre l’état d’un service et déclencher une astreinte quand il se dégrade.
- Centraliser les journaux de plusieurs serveurs et fonctions Lambda, puis les fouiller avec Logs Insights, un langage de requête propre au service.
- Piloter la mise à l’échelle automatique : une alarme sur la charge processeur ou sur la longueur d’une file d’attente commande l’ajout ou le retrait d’instances.
- Construire des tableaux de bord partagés entre l’équipe technique et les responsables métier.
- Surveiller un parcours utilisateur de bout en bout avec les canaris de CloudWatch Synthetics, qui rejouent un scénario à intervalle régulier depuis l’extérieur.
Comment fonctionne CloudWatch ?
Les services AWS publient d’eux-mêmes un jeu de métriques standard. Pour une instance EC2, la surveillance de base remonte des points toutes les cinq minutes ; la surveillance détaillée, facturée en supplément, descend à la minute.
Un point surprend souvent les débutants : la mémoire utilisée et l’espace disque d’une instance EC2 ne figurent pas dans les métriques par défaut. L’hyperviseur ne voit pas l’intérieur de la machine. Il faut installer l’agent CloudWatch pour les obtenir.
Les journaux sont organisés en groupes, eux-mêmes découpés en flux. Leur durée de conservation est réglable, et par défaut ils ne sont jamais supprimés, ce qui alimente une ligne de facture qui grossit silencieusement pendant des mois.
Une alarme se déclenche sur un seuil observé pendant un nombre de périodes consécutives, et envoie sa notification via SNS, vers une adresse mail, un canal Slack ou un outil d’astreinte. On peut aussi publier ses propres métriques applicatives, par exemple le nombre de commandes validées par minute.
CloudWatch, CloudTrail ou X-Ray : lequel regarder ?
Ces trois services sont régulièrement confondus alors qu’ils répondent à des questions différentes.
- CloudWatch répond à « comment se comporte le système ». Performance, disponibilité, erreurs.
- CloudTrail répond à « qui a fait quoi ». Il journalise les appels d’API et les actions des utilisateurs, à des fins d’audit et d’enquête après incident.
- AWS X-Ray répond à « où le temps est passé » dans une requête qui traverse plusieurs services. C’est du traçage distribué, utile en architecture microservices.
AWS Config complète l’ensemble sur un quatrième axe, la conformité de la configuration des ressources dans le temps.
Face aux outils du marché, CloudWatch a pour lui l’intégration native et l’absence d’agent à déployer sur les services managés. Datadog, Grafana associé à Prometheus ou New Relic offrent une meilleure expérience de recherche et de corrélation, et couvrent le multicloud. Le choix se joue en général sur ce point, plus que sur les fonctionnalités de base.
Exemples ou cas d’usage concrets
Un site marchand branche une alarme sur la latence de son répartiteur de charge. Au-delà de deux secondes pendant cinq minutes, le groupe d’autoscaling ajoute des instances et l’astreinte reçoit une notification.
Un éditeur cherche l’origine d’une vague d’erreurs 500. Une requête Logs Insights sur les journaux de ses fonctions Lambda isole en quelques secondes le message d’erreur commun et la version déployée qui l’a introduit.
Une PME surveille l’espace disque de sa base Amazon RDS. Une alarme à 80 % laisse le temps d’agir, là où la saturation aurait provoqué un arrêt du service.
Une équipe met en place un canari Synthetics qui rejoue toutes les cinq minutes le tunnel de commande. La panne est détectée avant le premier appel client, y compris quand toutes les métriques d’infrastructure sont au vert.
Quels profils travaillent avec CloudWatch ?
CloudWatch n’est jamais une compétence recherchée pour elle-même. Il apparaît dans les annonces comme une brique parmi d’autres, dans un ensemble AWS.
- Ingénieur DevOps ou cloud : met en place la supervision, écrit les alarmes en Terraform et branche les notifications sur l’outil d’astreinte.
- SRE : définit les indicateurs de niveau de service et les budgets d’erreur, et arbitre ce qui mérite de réveiller quelqu’un la nuit.
- Développeur back-end : instrumente son application et publie les métriques métier qui comptent.
- FinOps : surveille le coût de CloudWatch lui-même, en particulier l’ingestion et la conservation des journaux.
La question qui distingue un candidat expérimenté n’est pas « savez-vous créer une alarme », mais « comment évitez-vous que vos alertes soient ignorées ». Une supervision qui envoie quarante notifications par nuit ne protège plus rien.