Votre instance EC2 ne répond plus, et pourtant CloudWatch indique que tout va bien? Un grand classique. AWS fournit par défaut des métriques sur le CPU, le réseau et les E/S disque, mais il n’affiche ni l’utilisation de la mémoire ni l’espace disque libre. Ces chiffres restent cachés à l’intérieur de la machine virtuelle, et tant que vous ne les exposez pas, vous pilotez à l’aveugle.

Quand la mémoire est saturée, l’instance ne vous prévient pas: elle plante simplement. L’OOM Killer arrête des processus dans un ordre aléatoire, et vous en êtes réduit à deviner: un plugin a-t-il échoué? La base de données est-elle tombée? La cause réelle, c’est que vous avez épuisé les gigaoctets de RAM que vous ne surveilliez pas. Pour le disque, c’est la même histoire: les logs, les sauvegardes et les fichiers temporaires remplissent le stockage en silence, et un beau matin vous voyez apparaître No space left on device.

La solution, c’est l’agent CloudWatch, l’agent standard AWS qui collecte la mémoire, le disque, le swap et environ deux douzaines d’autres métriques système pour les envoyer vers CloudWatch. La mise en place prend 20 minutes et reste dans le cadre de l’offre gratuite (10 métriques personnalisées par mois). Voici un guide pas à pas, de la configuration IAM jusqu’au tableau de bord final.

💡 Aperçu rapide:

• Créez une politique IAM avec cloudwatch:PutMetricData et attachez-la à un utilisateur
• Téléchargez et installez l’agent CloudWatch sur une instance Ubuntu
• Configurez le fichier JSON: mémoire, disque, swap
• Démarrez l’agent et vérifiez que les métriques remontent bien dans CloudWatch
• Construisez un tableau de bord personnalisé avec des graphiques d’utilisation mémoire et disque

Gestion des identités et des accès AWS

L’agent a besoin d’autorisations pour envoyer des métriques vers CloudWatch. Nous allons créer une politique IAM et l’attacher à un utilisateur disposant d’un accès programmatique.

Politique IAM

Ouvrez la console IAM, allez dans Politiques → Créer une politique et basculez sur l’onglet JSON. Collez le document suivant:

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "CloudWatchAgentMetrics",
6
            "Effect": "Allow",
7
            "Action": [
8
                "cloudwatch:PutMetricData",
9
                "ec2:DescribeTags",
10
                "cloudwatch:GetMetricStatistics",
11
                "cloudwatch:ListMetrics"
12
            ],
13
            "Resource": "*"
14
        }
15
    ]
16
}

Cliquez sur Vérifier la politique, saisissez un nom (par exemple CloudWatchAgentPolicy), puis cliquez sur Créer une politique.

Utilisateur IAM

Allez dans Utilisateurs → Ajouter un utilisateur. Saisissez un nom et assurez-vous de cocher la case «Accès programmatique»; cela fournit l’Access Key ID et la Secret Access Key que l’agent utilisera pour s’authentifier.

Sur l’écran des autorisations, sélectionnez Attacher directement les politiques existantes. Dans le filtre par type de politique, choisissez Gérées par le client pour retrouver rapidement la politique CloudWatchAgentPolicy que vous venez de créer.

Cochez la politique et cliquez sur Suivant → Créer un utilisateur. AWS affiche alors les clés d’accès. Conservez immédiatement l’Access Key ID et la Secret Access Key. Si vous fermez la page, les clés disparaissent définitivement et vous devrez les recréer.

Installation de l’agent CloudWatch

Les anciens scripts de surveillance en Perl (CloudWatchMonitoringScripts-1.2.2.zip) sont marqués comme obsolètes depuis longtemps. L’approche actuelle repose sur l’agent CloudWatch unifié, qui collecte non seulement la mémoire et le disque, mais aussi le swap, la charge CPU, les interfaces réseau et environ deux douzaines d’autres métriques sans configuration supplémentaire.

Téléchargement et installation

Connectez-vous à l’instance via SSH et téléchargez le paquet de l’agent pour Ubuntu:

1
wget https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

Installez le paquet avec dpkg:

1
sudo dpkg -i amazon-cloudwatch-agent.deb

Si le gestionnaire de paquets signale des dépendances manquantes, installez-les avec une seule commande:

1
sudo apt-get install -f

L’agent est installé, mais il ne sait pas encore quelles métriques collecter ni quelles clés utiliser pour s’authentifier auprès de CloudWatch. Passons à sa configuration.

Remarque: l’agent est également disponible via AWS Systems Manager (SSM). Si vous avez des dizaines d’instances, il est plus pratique de le déployer de manière centralisée avec Run Command, sans avoir à vous connecter en SSH sur chaque machine. Pour une ou deux instances, l’installation manuelle reste plus simple et plus rapide.

Configuration de l’agent

Création du fichier de configuration

La configuration de l’agent CloudWatch est un document JSON qui décrit les métriques à collecter et à quelle fréquence. Lancez l’assistant intégré:

1
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

L'assistant vous posera plusieurs questions de manière interactive: type de serveur (EC2 ou sur site), destination des métriques (CloudWatch) et quelles métriques collecter. Pour suivre la mémoire et le disque, répondez comme suit:

• Système d'exploitation: Linux
• Utilisez-vous Amazon EC2?: Oui
• Métriques à collecter: Métriques personnalisées (mem et disk_used_percent)
• Résolution: 60 secondes (Standard)
• Fichiers de log: passez cette étape si vous n'avez pas besoin de logs

L'assistant générera un fichier config.json dans le répertoire /opt/aws/amazon-cloudwatch-agent/bin/. Voici un exemple minimal fonctionnel pour le pourcentage de mémoire utilisée + le pourcentage de disque utilisé + le swap:

1
{
2
    "agent": {
3
        "metrics_collection_interval": 60,
4
        "run_as_user": "root"
5
    },
6
    "metrics": {
7
        "metrics_collected": {
8
            "mem": {
9
                "measurement": [
10
                    "mem_used_percent"
11
                ]
12
            },
13
            "disk": {
14
                "measurement": [
15
                    "disk_used_percent"
16
                ],
17
                "resources": [
18
                    "/"
19
                ]
20
            },
21
            "swap": {
22
                "measurement": [
23
                    "swap_used_percent"
24
                ]
25
            }
26
        }
27
    }
28
}

Le paramètre resources pour disk spécifie le point de montage: "/" correspond au volume racine EBS NVMe SSD, le stockage principal de l'instance. Si vous avez des volumes supplémentaires (par exemple, /data), ajoutez-les au tableau.

Identifiants de l'agent

Les clés d'accès sauvegardées lors de l'étape IAM doivent être fournies à l'agent. Créez un fichier d'identifiants dans le répertoire personnel de l'utilisateur:

1
sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml

Ajoutez cette section:

1
[credentials]
2
    shared_credential_profile = "AmazonCloudWatchAgent"

Ajoutez ensuite les identifiants au fichier d'identifiants AWS standard:

1
aws configure --profile AmazonCloudWatchAgent

Le système vous demandera l'ID de clé d'accès, la clé d'accès secrète et la région. Une fois ces informations renseignées, l'agent pourra envoyer des métriques pour le compte de l'utilisateur IAM que vous avez créé.

Une autre approche consiste à utiliser un rôle IAM attaché à l'instance. C'est plus sécurisé (pas de clés stockées sur le disque) et plus simple en cas de montée en charge. Si vous lancez EC2 avec un rôle IAM disposant de l'autorisation cloudwatch:PutMetricData, l'agent récupérera automatiquement les permissions et vous pourrez sauter l'étape des identifiants.

Test

Démarrez l'agent manuellement et vérifiez que les métriques sont bien envoyées:

1
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
2
  -a fetch-config \
3
  -m ec2 \
4
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
5
  -s

L'option -s démarre l'agent en tant que service. En une minute ou deux, les premières métriques apparaîtront dans CloudWatch. Pour confirmer que les données arrivent, ouvrez la console CloudWatch, allez dans Métriques → Toutes les métriques et cherchez l'espace de noms CWAgent (l'agent y écrit par défaut).

Développez l'espace de noms et vous verrez les dimensions InstanceId ventilées par métriques: mem_used_percent, disk_used_percent et swap_used_percent. Cliquez sur n'importe quelle ligne pour générer un graphique; vous pouvez immédiatement vérifier que les données arrivent et semblent cohérentes.

Quatre métriques de base (mémoire, disque, swap, CPU) sur deux instances représentent 8 métriques. L'offre gratuite CloudWatch inclut 10 métriques personnalisées par mois, comme décrit sur la page de tarification. Vous restez dans cette limite. Si vous avez plus de trois instances, certaines métriques dépasseront la limite, mais le coût reste modeste: 0,30 $ par métrique et par mois (données AWS en date de 2026).

Mise en place de la planification

Par défaut, l'agent s'exécute en tant que service systemd et envoie les métriques à l'intervalle spécifié dans metrics_collection_interval (60 secondes dans notre configuration). Aucune entrée cron supplémentaire n'est nécessaire; systemd garantit que l'agent reste actif et redémarre en cas de plantage.

Vérifiez le statut:

1
sudo systemctl status amazon-cloudwatch-agent

Vérifiez que le service est active (running) et activé au démarrage (enabled). Si ce n'est pas le cas, démarrez-le et activez-le:

1
sudo systemctl enable amazon-cloudwatch-agent
2
sudo systemctl start amazon-cloudwatch-agent

Après un redémarrage, l'agent se lancera automatiquement.

Pour une démonstration visuelle de l'ensemble du processus, de l'IAM au tableau de bord, regardez cette vidéo:

Créer un tableau de bord personnalisé

Les métriques arrivent; il ne vous reste plus qu’à les présenter proprement. Je vais vous montrer comment construire un tableau de bord pour superviser une instance de production: mémoire, disque, charge CPU et solde de crédits (pour les instances de type T) sur un seul écran.

Création du tableau de bord

Dans la console CloudWatch, allez dans Tableaux de bord → Créer un tableau de bord. Saisissez un nom (par exemple Production-EC2) et choisissez un type de widget.

Sélectionnez Courbes pour le premier graphique; ce type est le mieux adapté pour afficher des métriques dans le temps.

Widget de type graphique

Cliquez sur Ajouter un widget et choisissez le type Courbes, un simple graphique en courbes et le meilleur choix pour la plupart des métriques. Dans la boîte de dialogue qui s’ouvre, cliquez sur Configurer et naviguez jusqu’à l’espace de noms CWAgent.

Trouvez la métrique mem_used_percent correspondant à votre instance (via l’InstanceId) et cliquez sur la ligne; CloudWatch affiche immédiatement un graphique.

Astuce: le type Aires empilées fonctionne bien quand un même widget comporte plusieurs métriques (par exemple mémoire + swap); le type Nombre est utile pour lire instantanément la valeur actuelle (pratique dans un coin du tableau de bord); le type Texte sert pour les titres et les notes entre les graphiques.

Ajustement fin du graphique

Quelques réglages qui rendent le graphique lisible:

• Période: si l’agent envoie les métriques toutes les minutes, choisissez une période d’une minute pour voir la résolution complète des données.

• Titre: renommez la légende du graphique avec un libellé compréhensible, par exemple «RAM utilisée%» plutôt que mem_used_percent / i-1234567890abcdef0.

• Maximum de l’axe Y (Options du graphique): fixez la limite (par exemple 100 pour des pourcentages ou 16 pour 16 Go de RAM). Sans cela, CloudWatch ajuste automatiquement l’échelle et un petit pic paraît aussi alarmant qu’une situation critique. Avec une limite fixe, vous voyez en un coup d’œil à quel point vous êtes proche de la saturation.

Cliquez sur Créer le widget; le premier bloc du tableau de bord est prêt. Répétez l’opération pour chaque métrique: disk_used_percent, puis swap_used_percent, puis cpu_usage (une métrique EC2 intégrée, ne provenant pas de CWAgent) et CPUCreditBalance pour les instances de type T. Vous pouvez faire glisser, redimensionner et modifier les widgets. Quand tout vous semble correct, cliquez sur Enregistrer le tableau de bord.

Le tableau de bord est prêt. Ajoutez-le aux favoris (l’étoile dans le menu du haut) et revenez-y en un clic chaque fois que vous avez besoin de vérifier l’état de l’instance avant un déploiement ou après un pic de trafic.

⁉️🤔 Questions fréquentes

Pourquoi les métriques EC2 standard n’incluent-elles pas la mémoire et le disque?

AWS virtualise le CPU et le réseau au niveau de l’hyperviseur; ces métriques sont disponibles de l’extérieur sans entrer dans le système d’exploitation invité. La mémoire et le disque sont des ressources internes de la machine virtuelle; l’hyperviseur n’en a pas connaissance. Pour les voir, vous avez besoin d’un agent à l’intérieur du système d’exploitation qui lit /proc/meminfo et df et envoie les données à CloudWatch. C’est exactement ce que fait CloudWatch Agent: une fois par minute, il interroge les compteurs système et les envoie vers l’espace de noms CWAgent. La liste complète d’environ deux douzaines de métriques se trouve dans la documentation officielle AWS.

Combien cela coûte-t-il?

Pour un scénario typique de 1 à 2 instances avec 4 métriques chacune, rien. L’offre gratuite CloudWatch inclut 10 métriques personnalisées, 10 alarmes et 3 tableaux de bord par compte et par mois, conformément à la page de tarification CloudWatch. Deux instances avec 4 métriques chacune représentent 8 des 10 métriques gratuites. Si vous avez plus de trois instances, le dépassement coûte 0,30 $ par métrique et par mois. Pour une douzaine de serveurs, cela représente 6 à 9 $ par mois, le prix pour éviter les mauvaises surprises à trois heures du matin.

Pourquoi CloudWatch Agent est-il meilleur que les anciens scripts Perl?

Les scripts Perl (mon-put-instance-data.pl) sont officiellement dépréciés depuis 2023 et ne reçoivent plus de mises à jour. CloudWatch Agent est l’outil officiellement pris en charge qui écrit non seulement vers CloudWatch mais aussi vers Amazon Managed Prometheus; il collecte les métriques via StatsD et collectd; il peut envoyer des logs et des traces. Surtout, il s’intègre avec Systems Manager, ce qui signifie que vous pouvez le déployer sur 50 instances avec une seule commande depuis la console, sans SSH. Si vous avez encore des scripts Perl en cours d’exécution, migrez: l’ancien format awscreds.conf avec des clés en clair sur le disque est une faille de sécurité. CloudWatch Agent fonctionne avec des rôles IAM et ne nécessite pas de stocker des secrets dans un fichier texte.

Que dois-je faire si les métriques n’apparaissent pas dans CloudWatch?

Vérifiez dans l’ordre: (1) le statut du service via systemctl status amazon-cloudwatch-agent, qui doit être active; (2) les logs de l’agent dans /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log, où vous trouverez l’erreur spécifique; (3) les permissions IAM, l’utilisateur ou le rôle doit disposer de la permission cloudwatch:PutMetricData; (4) la région, l’agent et la console doivent pointer vers la même région AWS. D’après mon expérience, l’écrasante majorité des problèmes sont soit des permissions, soit une incohérence de région.

Puis-je superviser des instances Windows?

Oui, CloudWatch Agent prend en charge Windows Server à parité avec Linux. L’installation se fait via un installeur MSI depuis le même compartiment S3 (amazon-cloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/). La configuration utilise le même JSON, mais les noms de métriques diffèrent: au lieu de mem_used_percent, utilisez Memory % Committed Bytes In Use. L’assistant de configuration sous Windows substituera automatiquement les noms corrects.

Ce que la supervision de la mémoire et du disque apporte en pratique

Vous avez lancé CloudWatch Agent sur une instance Ubuntu, configuré la collecte de la mémoire, du disque et du swap, et ajouté un tableau de bord avec des graphiques. Qu’est-ce qui a changé? Exactement une chose: l’angle mort a disparu. Vous voyez non seulement le CPU et le réseau, mais aussi les deux principaux tueurs d’instances: les fuites de mémoire et les disques pleins.

En pratique, cela signifie que vous remarquez la mémoire grimper trois jours AVANT que l’OOM Killer ne tue PHP-FPM. Vous voyez que le disque s’est rempli presque complètement après une mise à jour de thème et vous videz les logs AVANT que la base de données ne plante. Sans ces métriques, chaque incident devient une enquête post-mortem. Avec elles, vous recevez une alerte dans le canal une demi-heure avant la panne.

Si vous avez plus de trois instances, mettez en place des alarmes CloudWatch sur des valeurs seuils (par exemple mem_used_percent > 90 pendant 5 minutes) et connectez les notifications via SNS vers Slack ou Telegram. Agent + alarmes = vous apprenez le problème par AWS, pas par un client.

La configuration de l’agent est un investissement unique de 20 minutes par instance. Ensuite, il tourne tout seul.