CloudWatch : alarmes, logs et métriques
À la fin de ce tutoriel, vous créerez une alarme CloudWatch (billing ou CPU), un Log Group, enverrez un événement de log, et brancherez une notification SNS — socle observability en
ca-central-1(billing metrics souvent us-east-1).Niveau : Débutant → Intermédiaire · Temps estimé : 50–60 min · Versions testées : CloudWatch 2026, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region lab :
ca-central-1← Précédent : SNS/SQS · → Suivant : SSM · Hub : Démarrer avec AWS
Prérequis
- Topic SNS lab (ou créez-en un) — SNS/SQS
- EC2 optionnelle pour métrique CPU
- Profil
lab
Coût estimé : alarmes et logs à bas volume = cents. Attention ingestion Logs et Contributor Insights en prod : un conteneur bavard peut coûter plus cher que l’EC2 qu’il observe. Fixez rétention et filtres tôt.
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
Ce que nous allons construire
Métrique CPU EC2 (ou EstimatedCharges)
│
▼
Alarme CloudWatch ──OK/ALARM──► SNS topic lab-alerts
Logs applicatifs ──► Log Group /aws/lab/app
(Schéma — alt : « Métrique → alarme → SNS ; logs → Log Group ».)
Étape 1 — Les briques CloudWatch
| Brique | Rôle |
|---|---|
| Metrics | Points numériques (CPU, facturation, custom) |
| Alarms | Seuil → action (SNS, ASG, EC2 action) |
| Logs | Journaux (agent / Lambda / SDK) |
| Dashboards | Vue consolidée |
| Events / EventBridge | Historiquement CloudWatch Events → EventBridge |
Namespaces : AWS/EC2, AWS/Billing, custom Lab/App, etc.
Étape 2 — Alarme billing (anti-facture)
Les métriques Billing sont publiées dans us-east-1 :
# Activez d'abord « Receive Billing Alerts » dans Account (console Billing)
TOPIC_ARN=$(aws sns create-topic --name lab-alerts --query TopicArn --output text)
# souscrivez votre email et confirmez le lien
aws cloudwatch put-metric-alarm
--region us-east-1
--alarm-name lab-billing-5
--alarm-description "Estimated charges > 5 USD"
--namespace AWS/Billing
--metric-name EstimatedCharges
--dimensions Name=Currency,Value=USD
--statistic Maximum
--period 21600
--evaluation-periods 1
--threshold 5
--comparison-operator GreaterThanThreshold
--alarm-actions "$TOPIC_ARN"
C’est le filet du hub « Démarrer avec AWS » formalisé en alarme.
Étape 3 — Alarme CPU EC2
INSTANCE_ID=i-0abc… # instance lab running
aws cloudwatch put-metric-alarm
--alarm-name lab-ec2-cpu-high
--namespace AWS/EC2
--metric-name CPUUtilization
--dimensions Name=InstanceId,Value="$INSTANCE_ID"
--statistic Average
--period 300
--evaluation-periods 2
--threshold 70
--comparison-operator GreaterThanThreshold
--alarm-actions "$TOPIC_ARN"
--treat-missing-data notBreaching
Liez la même idée à un ASG (scaling policy) plutôt qu’email seul en prod.
États d’alarme
Une alarme est OK, ALARM ou INSUFFICIENT_DATA. Trop d’INSUFFICIENT_DATA = métrique absente (instance stoppée) ou période trop courte vs granularité. treat-missing-data (breaching / notBreaching / ignore) change le comportement — pour billing, notBreaching évite les faux positifs nocturnes si la métrique tarde.
Période et évaluation
period=300 + evaluation-periods=2 = 10 minutes de moyenne au-dessus du seuil avant ALARM. Trop sensible = spam SNS ; trop lâche = incident tardif. Alignez avec vos SLO.
Étape 4 — Log Group
- événement test
aws logs create-log-group --log-group-name /aws/lab/app
aws logs create-log-stream --log-group-name /aws/lab/app --log-stream-name test-1
# put-log-events exige sequenceToken après le 1er appel — pour un lab, console « Create log event »
# ou :
TS=$(date +%s000)
aws logs put-log-events
--log-group-name /aws/lab/app
--log-stream-name test-1
--log-events timestamp=$TS,message="hello-cloudwatch-lab"
Rétention : par défaut indefinite (coût) — fixez 7 ou 14 jours en lab :
aws logs put-retention-policy --log-group-name /aws/lab/app --retention-in-days 7
Étape 5 — Metric filter (aperçu)
Transformez des logs « ERROR » en métrique custom puis alarme — pattern apps sans agent metrics. Utile Lambda / conteneurs.
Exemple minimal après le Log Group /aws/lab/app :
aws logs put-metric-filter --log-group-name /aws/lab/app --filter-name lab-errors --filter-pattern "ERROR" --metric-transformations metricName=LabAppErrors,metricNamespace=Lab/App,metricValue=1,defaultValue=0
aws cloudwatch put-metric-alarm --alarm-name lab-app-errors --namespace Lab/App --metric-name LabAppErrors --statistic Sum --period 60 --evaluation-periods 1 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --alarm-actions "$TOPIC_ARN" --treat-missing-data notBreaching
Chaque ligne de log contenant ERROR incrémente la métrique. En prod, affinez le filter pattern (JSON fields) pour éviter le bruit.
Étape 6 — Dashboards
aws cloudwatch put-dashboard --dashboard-name lab-sa
--dashboard-body '{
"widgets": [{
"type": "metric",
"x": 0, "y": 0, "width": 12, "height": 6,
"properties": {
"metrics": [["AWS/EC2", "CPUUtilization"]],
"region": "ca-central-1",
"title": "EC2 CPU"
}
}]
}'
Étape 7 — Vérification
aws cloudwatch describe-alarms --alarm-names lab-ec2-cpu-high
aws logs describe-log-groups --log-group-name-prefix /aws/lab
Checklist : alarme créée · action SNS · log group + rétention · (billing alarm us-east-1) · dashboard optionnel.
Logs Insights
Requêtes SQL-like sur vos log groups (fields @message | filter @message like /ERROR/). Facturé à la donnée scannée — restreignez l’intervalle de temps. Idéal pour post-mortem après une alarme.
Exemple de requête (console Logs Insights ou start-query) :
fields @timestamp, @message
| filter @message like /ERROR|hello-cloudwatch/
| sort @timestamp desc
| limit 20
Astuce lab : après put-log-events, attendez quelques secondes avant Insights. En prod, indexez via metric filters les signaux chauds et gardez Insights pour l’investigation.
Cross-account observability
Organizations peut centraliser metrics/logs vers un compte monitoring. Hors lab solo, pattern entreprise fréquent.
Lien avec le budget SNS
Réutilisez le topic lab-alerts pour ASG, RDS CPUUtilization, ALB HTTPCode_Target_5XX_Count. Une seule souscription email, plusieurs alarmes — évite la dispersion.
En lab ca-central-1, créez le topic une fois, confirmez l’email, puis enchaînez les alarmes (CPU, 5XX, FreeStorageSpace, Errors Lambda). En prod, séparez parfois ops-critical et ops-warning pour éviter la fatigue d’alerte, mais gardez le même principe : peu de topics, beaucoup d’alarmes ciblées.
Nettoyage
aws cloudwatch delete-alarms --alarm-names lab-ec2-cpu-high lab-app-errors
aws cloudwatch delete-alarms --region us-east-1 --alarm-names lab-billing-5
aws logs delete-metric-filter --log-group-name /aws/lab/app --filter-name lab-errors || true
aws logs delete-log-group --log-group-name /aws/lab/app
aws cloudwatch delete-dashboards --dashboard-names lab-sa
# topic SNS : delete si plus utilisé
EC2 status checks
Outre CPU, alarmez StatusCheckFailed pour remplacer une instance morte via action EC2 Recover/Reboot — complémentaire du health check ALB en production réelle.
Erreurs fréquentes
| Symptôme | Cause | Correction |
|---|---|---|
| Billing metric vide | Pas us-east-1 / alerts off | Region + Billing preferences |
| Alarme INSUFFICIENT_DATA | Instance stop / période | Données manquantes ; treat-missing-data |
| Facture Logs | Rétention never / gros volume | Retention policy + filtres |
Agent vs Embedded Metric Format
EC2 : CloudWatch Agent pour mem/disk. Apps : EMF dans les logs → métriques sans PutMetricData manuel. Pour l’examen, sachez que CPU de base arrive sans agent ; RAM nécessite l’agent.
Custom metrics
PutMetricData permet d’envoyer Lab/App OrdersPerMinute. Respectez les quotas et agrégez côté app (pas un put par requête web si possible). Les métriques custom hors Free Tier peuvent être facturées.
Synthèse SA
Observability = metrics + logs + traces (X-Ray). Ce lab couvre metrics/logs ; les traces viennent avec les tutos Lambda/API.
Composite alarms & Anomaly detection
Alarmes composites (AND/OR) et détection d’anomalie (bande machiniste) existent pour réduire le bruit — hors lab minimal, utiles en prod mature.
Lab bonus (5–8 min) — forcer ALARM et lire l’historique
# Force l’état pour tester la chaîne SNS sans stresser l’EC2
aws cloudwatch set-alarm-state --alarm-name lab-ec2-cpu-high --state-value ALARM --state-reason "lab-test-manual"
aws cloudwatch describe-alarm-history --alarm-name lab-ec2-cpu-high --max-records 5 --query 'AlarmHistoryItems[].{Time:Timestamp,Summary:HistorySummary}'
# Remettre OK ensuite
aws cloudwatch set-alarm-state --alarm-name lab-ec2-cpu-high --state-value OK --state-reason "lab-test-reset"
Vérifiez l’email / la souscription SNS (confirmez le lien si premier abonnement). Objectif : valider alarme → action sans attendre un vrai pic CPU.
Scénario examen classique
« Vous devez être alerté si la facture estimée dépasse 5 USD et si une flotte EC2 dépasse 70 % CPU pendant 10 minutes. » → alarme Billing en us-east-1 + alarme CPUUtilization en ca-central-1, toutes deux vers le même topic SNS. Pour l’ASG, préférez une scaling policy sur la métrique plutôt qu’un simple email. N’oubliez pas treat-missing-data et la rétention des Log Groups — deux pièges fréquents Associate.
Checklist lab anti-facture CloudWatch
- Region lab =
ca-central-1; billing alarm explicitement--region us-east-1. - Rétention Log Group 7 ou 14 jours dès la création (jamais « Never expire » en lab).
- Une seule souscription email sur
lab-alerts; plusieurs alarmes dessus. - Supprimez alarmes, dashboard, metric filter, log group et (si jetable) le topic SNS en fin de lab.
- Évitez Contributor Insights / Canaries / métriques custom haute cardinalité hors besoin réel.
Granularité et namespaces utiles
| Namespace | Métriques typiques | Usage SA |
|---|---|---|
AWS/EC2 |
CPU, StatusCheckFailed, Network | ASG, recover |
AWS/ApplicationELB |
HTTPCode_Target_5XX_Count, TargetResponseTime |
SLO HTTP |
AWS/RDS |
CPU, FreeStorageSpace, DatabaseConnections | Disque plein |
AWS/Lambda |
Errors, Throttles, Duration | Serverless |
AWS/Billing |
EstimatedCharges (us-east-1) | Anti-facture |
En ca-central-1, alarmez d’abord CPU + 5XX ALB + FreeStorageSpace RDS — trio qui évite 80 % des surprises lab.
Quiz (5 questions)
1. Les métriques AWS/Billing se consultent surtout en :
– A. eu-west-3 uniquement
– B. us-east-1
– C. Local Zones
2. Un Log Group sans rétention :
– A. S’auto-supprime
– B. Peut coûter indéfiniment
– C. Est gratuit illimité
3. Une alarme CloudWatch peut surtout :
– A. Remplacer IAM
– B. Notifier SNS / déclencher actions
– C. Créer un VPC
4. Un metric filter sert surtout à :
– A. Remplacer VPC Flow Logs
– B. Transformer des lignes de logs en métrique alarmable
– C. Chiffrer EBS
5. set-alarm-state en lab permet surtout de :
– A. Modifier la facture AWS
– B. Tester la chaîne alarme → SNS sans vrai pic
– C. Créer un Log Group
Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B
Pour aller plus loin
Maillage série AWS (P1)
| ← Précédent | SNS/SQS |
| → Suivant | SSM Session Manager |
| Aussi | ASG · EC2 |
Retour parcours AWS — hub de la série et leçons sœurs.
