Claude Code × AWS CloudWatch Guide Complet | Analyse de Logs, Alarmes et Dashboards Automatiques

« Une erreur est apparue en production ! Mais les logs sont si nombreux que je ne sais pas où chercher. » — C’est la panique classique lors de la gestion d’incidents.

CloudWatch est le service de monitoring standard d’AWS, mais avec des volumes de logs colossaux, les informations critiques s’y noient, et la configuration des alarmes est souvent repoussée. Je surveille un système ECS + Lambda au travail, et laisser Claude Code lire les logs pour identifier la cause a réduit notre temps moyen de réponse aux incidents de 40 %.

Cet article explique étape par étape comment automatiser l’analyse de logs CloudWatch, la conception d’alarmes et la construction de dashboards avec Claude Code.

---

Principaux composants de CloudWatch

CloudWatch Logs      : Stockage et recherche de logs d'apps et de services AWS
CloudWatch Metrics   : Données numériques comme l'utilisation CPU et le nombre de requêtes
CloudWatch Alarms    : Détecte les dépassements de seuils et notifie SNS, etc.
CloudWatch Dashboards: Vues personnalisées pour visualiser métriques et logs
Log Insights         : Moteur de requêtes similaire à SQL pour analyser les logs

---

Étape 1 : Déléguer l’analyse de patterns de logs à Claude Code

Lors d’un incident, la première priorité est de comprendre le pattern des logs d’erreur.

# Récupérer les logs d'erreur de la dernière heure
aws logs filter-log-events \
  --log-group-name "/ecs/myapp" \
  --start-time $(date -d "1 hour ago" +%s000) \
  --filter-pattern "ERROR" \
  --output json > error-logs.json

claude -p "
Analyse les logs d'erreur CloudWatch suivants et :

1. Classifie les erreurs par type (5xx, 4xx, erreurs de connexion BD, timeouts, etc.)
2. Identifie l'erreur la plus fréquente
3. Détermine le moment où les erreurs ont explosé
4. Propose des hypothèses sur la cause racine
5. Suggère les prochaines actions d'investigation

$(cat error-logs.json | head -500)
"

Générer automatiquement des requêtes Log Insights

claude -p "
Génère des requêtes CloudWatch Log Insights pour les objectifs suivants :

1. Taux d'erreur par endpoint sur la dernière heure (top 10)
2. Détails des requêtes avec une latence supérieure à 500 ms
3. Tous les logs d'opérations d'un utilisateur spécifique (user_id : 12345)
4. Premières erreurs apparues dans les 30 minutes suivant un déploiement

Format de log : JSON (timestamp, level, message, user_id, endpoint, duration_ms, status_code)
"

Exemple de requêtes Log Insights générées :

-- Taux d'erreur par endpoint
fields @timestamp, endpoint, status_code
| filter status_code >= 400
| stats count() as error_count by endpoint
| sort error_count desc
| limit 10

-- Requêtes avec latence supérieure à 500 ms
fields @timestamp, endpoint, duration_ms, user_id
| filter duration_ms > 500
| sort duration_ms desc
| limit 50

-- Logs d'opérations d'un utilisateur spécifique
fields @timestamp, level, message, endpoint
| filter user_id = "12345"
| sort @timestamp desc
| limit 100

---

Étape 2 : Générer automatiquement la configuration des alarmes

claude -p "
Conçois toutes les alarmes CloudWatch nécessaires pour le système suivant.
Implémentation en CDK TypeScript.

[Architecture du système]
- ECS Fargate (serveur API, 2–10 instances)
- RDS PostgreSQL
- ALB (Application Load Balancer)
- Lambda (traitement par lots)

[Exigences des alarmes]
- Production : alarmes déclenchées en moins de 5 minutes
- Destinataires de notification : SNS → Slack et PagerDuty
- Alarmes à deux niveaux (Warning / Critical)
- En dehors des heures ouvrées : Critical uniquement
"

// lib/monitoring-stack.ts
import * as cdk from "aws-cdk-lib";
import * as cloudwatch from "aws-cdk-lib/aws-cloudwatch";
import * as actions from "aws-cdk-lib/aws-cloudwatch-actions";
import * as sns from "aws-cdk-lib/aws-sns";

export class MonitoringStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const alertTopic = sns.Topic.fromTopicArn(
      this, "AlertTopic",
      `arn:aws:sns:${this.region}:${this.account}:prod-alerts`
    );
    const warnTopic = sns.Topic.fromTopicArn(
      this, "WarnTopic",
      `arn:aws:sns:${this.region}:${this.account}:prod-warnings`
    );

    // Alarme de taux d'erreur 5xx d'ALB
    const alb5xxAlarm = new cloudwatch.Alarm(this, "Alb5xxAlarm", {
      alarmName: "prod-alb-5xx-critical",
      alarmDescription: "Le taux d'erreur 5xx d'ALB a dépassé 5%",
      metric: new cloudwatch.Metric({
        namespace: "AWS/ApplicationELB",
        metricName: "HTTPCode_Target_5XX_Count",
        dimensionsMap: { LoadBalancer: "app/myapp/xxx" },
        statistic: "Sum",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 10,
      evaluationPeriods: 2,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD,
      treatMissingData: cloudwatch.TreatMissingData.NOT_BREACHING,
    });
    alb5xxAlarm.addAlarmAction(new actions.SnsAction(alertTopic));

    // Alarme d'utilisation CPU ECS (Warning/Critical)
    const ecsCpuWarning = new cloudwatch.Alarm(this, "EcsCpuWarning", {
      alarmName: "prod-ecs-cpu-warning",
      metric: new cloudwatch.Metric({
        namespace: "AWS/ECS",
        metricName: "CPUUtilization",
        dimensionsMap: { ClusterName: "myapp-cluster", ServiceName: "myapp-service" },
        statistic: "Average",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 70,
      evaluationPeriods: 3,
    });
    ecsCpuWarning.addAlarmAction(new actions.SnsAction(warnTopic));

    const ecsCpuCritical = new cloudwatch.Alarm(this, "EcsCpuCritical", {
      alarmName: "prod-ecs-cpu-critical",
      metric: new cloudwatch.Metric({
        namespace: "AWS/ECS",
        metricName: "CPUUtilization",
        dimensionsMap: { ClusterName: "myapp-cluster", ServiceName: "myapp-service" },
        statistic: "Average",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 90,
      evaluationPeriods: 2,
    });
    ecsCpuCritical.addAlarmAction(new actions.SnsAction(alertTopic));

    // Alarme de nombre de connexions RDS
    const rdsConnectionAlarm = new cloudwatch.Alarm(this, "RdsConnectionAlarm", {
      alarmName: "prod-rds-connections-critical",
      metric: new cloudwatch.Metric({
        namespace: "AWS/RDS",
        metricName: "DatabaseConnections",
        dimensionsMap: { DBInstanceIdentifier: "myapp-db" },
        statistic: "Maximum",
        period: cdk.Duration.minutes(5),
      }),
      threshold: 80,  // 80% des connexions maximales de db.t3.micro
      evaluationPeriods: 2,
    });
    rdsConnectionAlarm.addAlarmAction(new actions.SnsAction(alertTopic));

    // Alarme d'erreurs Lambda
    const lambdaErrorAlarm = new cloudwatch.Alarm(this, "LambdaErrorAlarm", {
      alarmName: "prod-lambda-errors-critical",
      metric: new cloudwatch.Metric({
        namespace: "AWS/Lambda",
        metricName: "Errors",
        dimensionsMap: { FunctionName: "myapp-batch" },
        statistic: "Sum",
        period: cdk.Duration.minutes(15),
      }),
      threshold: 5,
      evaluationPeriods: 1,
    });
    lambdaErrorAlarm.addAlarmAction(new actions.SnsAction(alertTopic));
  }
}

---

Étape 3 : Générer automatiquement un dashboard personnalisé

claude -p "
Génère un dashboard CloudWatch en CDK affichant les informations suivantes.

[Disposition du dashboard]
Ligne 1 : Santé globale du système (requêtes ALB, taux 5xx, latence P50/P95/P99)
Ligne 2 : Service ECS (CPU, mémoire, nombre de tâches en cours)
Ligne 3 : RDS (connexions, latence, utilisation CPU)
Ligne 4 : Lambda (invocations, erreurs, durée)
Ligne 5 : Métriques métier (nouvelles inscriptions, taux de succès des paiements) ← métriques personnalisées
"

// Définition du dashboard (extrait)
const dashboard = new cloudwatch.Dashboard(this, "AppDashboard", {
  dashboardName: "myapp-production",
});

dashboard.addWidgets(
  new cloudwatch.Row(
    new cloudwatch.GraphWidget({
      title: "Requêtes ALB",
      left: [new cloudwatch.Metric({
        namespace: "AWS/ApplicationELB",
        metricName: "RequestCount",
        statistic: "Sum",
        period: cdk.Duration.minutes(1),
      })],
      width: 8,
    }),
    new cloudwatch.GraphWidget({
      title: "Taux d'erreur 5xx ALB (%)",
      left: [new cloudwatch.MathExpression({
        expression: "5xx / (2xx + 3xx + 4xx + 5xx) * 100",
        usingMetrics: {
          "5xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_5XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
          "2xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_2XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
          "3xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_3XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
          "4xx": new cloudwatch.Metric({ metricName: "HTTPCode_Target_4XX_Count", namespace: "AWS/ApplicationELB", statistic: "Sum" }),
        },
        period: cdk.Duration.minutes(1),
      })],
      width: 8,
    }),
  )
);

---

Étape 4 : Déléguer l’investigation d’incidents à Claude Code

claude -p "
Je veux investiguer un incident en production. Exécute les commandes suivantes et analyse les résultats :

1. aws logs filter-log-events --log-group-name '/ecs/myapp' \
   --start-time \$(date -d '2 hours ago' +%s000) \
   --filter-pattern 'ERROR' --limit 100

2. aws cloudwatch get-metric-statistics \
   --namespace AWS/ApplicationELB \
   --metric-name HTTPCode_Target_5XX_Count \
   --start-time \$(date -d '2 hours ago' -u +%Y-%m-%dT%H:%M:%SZ) \
   --end-time \$(date -u +%Y-%m-%dT%H:%M:%SZ) \
   --period 300 --statistics Sum

Sur la base des résultats, résume :
- Heure de début de l'incident
- Nombre estimé d'utilisateurs impactés
- Top 3 des hypothèses sur la cause racine
- Actions de réponse immédiates
"

---

Étape 5 : Concevoir automatiquement des métriques personnalisées

claude -p "
Génère du code Node.js (AWS SDK v3) pour mesurer les KPIs métier suivants
d'un site e-commerce en tant que métriques personnalisées CloudWatch.

Métriques à mesurer :
- Nombre de paiements réussis et échoués (toutes les minutes)
- Taux d'abandon de panier (toutes les 5 minutes)
- Nouvelles inscriptions (toutes les heures)

Espace de noms : MyApp/Business
Étiqueter chaque métrique avec l'environnement (Production/Staging)
"

// src/monitoring/business-metrics.ts
import { CloudWatchClient, PutMetricDataCommand } from "@aws-sdk/client-cloudwatch";

const cw = new CloudWatchClient({ region: process.env.AWS_REGION });
const NAMESPACE = "MyApp/Business";
const ENV = process.env.NODE_ENV ?? "development";

export async function recordPaymentSuccess() {
  await cw.send(new PutMetricDataCommand({
    Namespace: NAMESPACE,
    MetricData: [{
      MetricName: "PaymentSuccess",
      Value: 1,
      Unit: "Count",
      Dimensions: [{ Name: "Environment", Value: ENV }],
    }],
  }));
}

export async function recordPaymentFailure(reason: string) {
  await cw.send(new PutMetricDataCommand({
    Namespace: NAMESPACE,
    MetricData: [{
      MetricName: "PaymentFailure",
      Value: 1,
      Unit: "Count",
      Dimensions: [
        { Name: "Environment", Value: ENV },
        { Name: "Reason", Value: reason },
      ],
    }],
  }));
}

---

4 pièges courants à éviter

1. evaluationPeriods trop court

// ❌ L'alarme se déclenche sur des pics momentanés
evaluationPeriods: 1,
threshold: 10,

// ✅ L'alarme ne se déclenche qu'après 3 périodes consécutives (réduit les faux positifs)
evaluationPeriods: 3,
threshold: 10,
datapointsToAlarm: 2,  // Alarme quand le seuil est dépassé 2 fois sur 3 périodes

2. Ignorer les coûts de Log Insights

Log Insights facture en fonction de la quantité de données scannées. Exécuter des requêtes sans limiter la plage temporelle peut engendrer des factures inattendues. Spécifiez toujours --start-time et --end-time.

3. Les métriques personnalisées haute résolution coûtent cher

Les métriques standard (60 secondes) sont gratuites, mais les métriques haute résolution (1 seconde) coûtent environ 10 fois plus cher. Une agrégation à 1 minute suffit généralement pour les métriques métier.

4. Ne pas configurer la durée de rétention des logs Lambda

La valeur par défaut est « Ne jamais expirer », ce qui fait croître les coûts de stockage indéfiniment. Configurez toujours une durée de rétention sur les groupes de logs.

new logs.LogGroup(this, "AppLogGroup", {
  logGroupName: "/ecs/myapp",
  retention: logs.RetentionDays.ONE_MONTH,  // Suppression automatique après 30 jours
});

---

Récapitulatif

Tâche	Contribution de Claude Code
Analyse de logs	Lit les logs d’erreur et propose des hypothèses de cause racine avec des étapes de résolution
Requêtes Log Insights	Génère des requêtes à partir d’une description de l’objectif d’analyse
Configuration des alarmes	Génère du code CDK en masse à partir d’une description du système
Dashboard	Génère des définitions de widgets à partir d’une description de ce que vous souhaitez afficher
Investigation d’incidents	Exécute des commandes AWS CLI et analyse les résultats

« On configurera le monitoring plus tard » — et puis un incident survient et vous n’avez aucune visibilité. Avec Claude Code, vous pouvez avoir des alarmes et des dashboards de niveau production prêts en 30 minutes.

Articles associés

• Claude Code × AWS ECS/Fargate Guide Complet
• Claude Code × AWS CodePipeline/CodeBuild Guide Complet
• Claude Code × AWS IAM Guide Complet

Références

• Documentation officielle Amazon CloudWatch
• Syntaxe des requêtes CloudWatch Log Insights
• Module CDK CloudWatch