Un guide systématique pour résoudre tout problème de service AWS

Lorsqu'un problème de service AWS survient, deviner fait perdre du temps et aggrave souvent l'incident. Un workflow de dépannage AWS systématique vous aide à définir le symptôme, vérifier les bonnes preuves, isoler la cause et résoudre le problème sans modifier trois choses à la fois.

Utilisez ce guide lorsque vous êtes confronté à une instance EC2 inaccessible, une erreur AccessDenied, un appel API limité, une fonction Lambda défaillante ou tout autre problème de service AWS dont la cause racine n'est pas évidente.

La méthodologie de dépannage systématique

Un dépannage efficace ne consiste pas à deviner, mais à suivre un processus logique et reproductible. Adopter une méthodologie structurée garantit que vous rassemblez toutes les informations nécessaires, formulez des hypothèses plausibles et les testez efficacement. Voici une décomposition des étapes clés :

1. Définir clairement le problème

Avant de plonger dans les journaux, prenez un moment pour comprendre le problème en profondeur. Demandez-vous :

Quel est exactement le problème ? (par exemple, instance EC2 inaccessible, échecs de téléchargement S3, fonction Lambda expirant).
Quand a-t-il commencé ? Est-il constant ou intermittent ? Y a-t-il des moments spécifiques où il se produit ?
Où se produit-il ? Quelle région, zone de disponibilité, service ou ressource spécifique ?
Qui est concerné ? Tous les utilisateurs, un groupe spécifique ou des systèmes internes ?
À quelle fréquence se produit-il ? S'agit-il d'un événement ponctuel ou d'un schéma récurrent ?
Quel est l'impact ? Est-il de sévérité critique, élevée, moyenne ou faible ?

Astuce : Vérifiez les déploiements récents, les modifications Terraform ou CloudFormation, les modifications IAM, les mises à jour des tables de routage et les modifications des groupes de sécurité avant de creuser plus profondément.

2. Rassembler les informations et observer

C'est là que les puissants outils de surveillance et de journalisation d'AWS entrent en jeu. Collectez autant de données pertinentes que possible sans apporter de modifications.

Consultez le tableau de bord AWS Health : Recherchez des événements spécifiques au compte, des événements de service régionaux ou une maintenance planifiée.
Examinez les métriques CloudWatch : Analysez les métriques pertinentes pour votre service (par exemple, utilisation CPU, E/S réseau, taux d'erreur, requêtes limitées).
Analysez les journaux CloudWatch : Plongez dans les journaux d'application, les journaux VPC Flow, les journaux Lambda, etc., pour détecter des erreurs ou des schémas inhabituels.
Consultez les journaux CloudTrail : Identifiez les appels API récents, surtout si vous soupçonnez un accès non autorisé ou des mauvaises configurations.
Examinez la configuration : Utilisez AWS Config pour voir si les configurations des ressources ont changé récemment.
Vérifiez l'état des ressources : Vérifiez l'état des instances, bases de données, équilibreurs de charge dans leurs consoles respectives.

3. Formuler une hypothèse

Sur la base des informations recueillies, proposez une ou plusieurs causes probables du problème. Votre hypothèse doit être spécifique et testable. Par exemple :

"L'instance EC2 est inaccessible car son groupe de sécurité n'autorise pas le trafic SSH entrant."
"Les téléchargements S3 échouent en raison d'une erreur Access Denied, indiquant une politique IAM incorrecte."
"La fonction Lambda expire car elle atteint une limite de concurrence du service."

4. Tester l'hypothèse et isoler les variables

Concevez un test simple pour prouver ou réfuter votre hypothèse. Si votre test initial ne résout pas le problème, affinez votre hypothèse et testez à nouveau. Lors des tests, effectuez un changement à la fois pour identifier facilement la cause et l'effet.

Exemple (Connectivité) : Si vous soupçonnez un problème de groupe de sécurité, testez à partir d'une adresse IP source connue et d'un seul port. Si cela prouve que la règle est le problème, remplacez le test temporaire par la règle étroite dont vous avez réellement besoin.
Exemple (Autorisations) : Utilisez le simulateur de politique IAM pour tester différentes politiques IAM par rapport aux actions qui échouent.

5. Résoudre et vérifier

Une fois que vous avez identifié la cause racine, mettez en œuvre le correctif approprié. Après avoir appliqué la solution, vérifiez minutieusement que le problème est résolu et qu'aucun nouveau problème n'a été introduit.

6. Documenter et apprendre

Après la résolution, documentez le problème, les étapes de diagnostic, la cause racine et la solution. Cela crée une base de connaissances précieuse pour les incidents futurs et contribue à améliorer la résilience de votre système. Envisagez un post-mortem pour les problèmes critiques afin d'identifier les mesures préventives.

Outils et ressources clés de dépannage AWS

AWS fournit une suite riche d'outils essentiels pour diagnostiquer les problèmes.

Amazon CloudWatch

Votre outil principal pour surveiller les ressources et les applications. CloudWatch offre :

Métriques : Points de données en temps réel sur pratiquement tous les services AWS (utilisation CPU, E/S réseau, nombre de requêtes S3, événements limités DynamoDB, invocations/erreurs Lambda). Créez des métriques personnalisées pour les données spécifiques à l'application.
Journaux : Journalisation centralisée pour presque toutes les sources (EC2, Lambda, journaux VPC Flow, CloudTrail, journaux d'application). Utilisez CloudWatch Logs Insights pour des requêtes et analyses puissantes.
Alarmes : Définissez des seuils sur les métriques pour déclencher des notifications (via SNS) ou des actions automatisées (par exemple, mise à l'échelle automatique).
Tableaux de bord : Créez des tableaux de bord personnalisés pour visualiser les métriques et journaux clés, offrant un tableau de bord unique pour la santé opérationnelle.

AWS CloudTrail

CloudTrail enregistre l'activité API sur l'ensemble de votre compte AWS, montrant qui a fait quoi, quand, d'où et avec quel résultat. Il est indispensable pour les enquêtes de sécurité, l'audit de conformité et, surtout, pour le dépannage des problèmes liés aux autorisations ou aux modifications involontaires de ressources.

Utilisation : Recherchez les événements Access Denied, les opérations UPDATE, DELETE ou CREATE qui coïncident avec le début du problème.

Exemple de requête Athena pour les journaux CloudTrail dans S3 :

SELECT eventtime, eventsource, eventname, useridentity.arn, errorcode, errormessage
FROM cloudtrail_logs
WHERE eventtime > current_timestamp - interval '1' hour
  AND (errorcode LIKE '%AccessDenied%' OR errormessage LIKE '%denied%')
ORDER BY eventtime DESC
LIMIT 100

Console de gestion AWS

Chaque console de service fournit des tableaux de bord spécifiques, des pages d'état et des détails de configuration. C'est souvent le premier endroit pour vérifier l'état et les paramètres des ressources. Par exemple, la console EC2 montre l'état des instances, les groupes de sécurité et les interfaces réseau.

AWS CLI/SDK

Pour les vérifications programmatiques, l'automatisation et les requêtes ad-hoc rapides, l'interface de ligne de commande (CLI) et les kits de développement logiciel (SDK) AWS sont inestimables. Ils vous permettent de récupérer des informations, de modifier des configurations et d'interagir avec les services directement depuis votre terminal ou votre application.

Exemple (Vérifier les règles du groupe de sécurité) :

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0

Tableau de bord AWS Health

Fournit des informations personnalisées sur l'état des services AWS et de votre compte. Il est crucial pour comprendre si un problème est spécifique au compte ou un événement de service AWS plus large. Il montre les problèmes opérationnels, la maintenance planifiée et les alertes personnalisées.

AWS Config

Enregistre les modifications de configuration de vos ressources AWS. Si une ressource se comporte soudainement de manière inattendue, Config peut vous montrer son historique de configuration, en identifiant quand et comment une modification a été apportée.

Catégories courantes de problèmes AWS et solutions

La plupart des problèmes AWS appartiennent à quelques catégories récurrentes. Comprendre ces schémas aide à formuler des hypothèses précises.

1. Problèmes de connectivité

Lorsque les ressources ne peuvent pas communiquer, vérifiez le chemin réseau :

Groupes de sécurité et ACL réseau (NACL) : Ce sont les coupables les plus courants. Les groupes de sécurité sont avec état et s'appliquent aux instances/ENI ; les NACL sont sans état et s'appliquent aux sous-réseaux. Vérifiez que les règles d'entrée/sortie autorisent le trafic nécessaire.
- Astuce : N'oubliez pas que les groupes de sécurité sont des listes d'autorisation. Les NACL ont à la fois des règles d'autorisation et de refus. L'ordre est important pour les NACL.
Tables de routage : Assurez-vous que vos sous-réseaux ont des routes correctes vers Internet (via une passerelle Internet), d'autres VPC (peering) ou des réseaux sur site (VPN/Direct Connect).
Résolution DNS : Si les ressources ne peuvent pas résoudre les noms d'hôte, vérifiez les paramètres DNS VPC, les configurations Route 53 ou les paramètres DNS au niveau de l'application.
Journaux VPC Flow : Pour un dépannage réseau approfondi, les journaux Flow enregistrent tout le trafic IP entrant et sortant des interfaces réseau de votre VPC. Analysez-les dans CloudWatch Logs Insights pour voir les connexions acceptées/rejetées.
```
fields @timestamp, @message
| filter logStatus = 'OK'
| filter action = 'REJECT'
| filter srcAddr = '192.0.2.1' or dstAddr = '192.0.2.1' -- IP d'intérêt
| sort @timestamp desc
```

2. Erreurs d'autorisation (Accès refusé)

Elles sont fréquentes et indiquées par des messages Access Denied, UnauthorizedOperation ou Forbidden.

Politiques IAM : Vérifiez les politiques IAM attachées à l'utilisateur, au rôle ou au groupe effectuant l'action. Vérifiez qu'elles ont des instructions Allow pour l'Action spécifique sur la Resource correcte.
- Astuce : Les politiques IAM sont refuser par défaut. Vous avez besoin d'une autorisation explicite.
Politiques basées sur les ressources : Certains services, dont S3, SQS, KMS, SNS et Lambda, prennent en charge des politiques basées sur les ressources qui accordent ou refusent l'accès directement sur la ressource. Celles-ci doivent s'aligner sur les politiques d'identité IAM.
- Exemple de politique de bucket S3 pour un compte AWS, pas d'accès public :
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromAppRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/app-readonly-role"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-private-bucket/*"
      ]
    }
  ]
}
```
Politiques de contrôle de service (SCP) : Si vous utilisez AWS Organizations, les SCP peuvent définir les autorisations maximales disponibles dans un compte. Une autorisation IAM ne peut pas outrepasser une restriction SCP.
CloudTrail : Recherchez les erreurs Access Denied dans les journaux CloudTrail pour identifier l'appel API exact, le principal et la ressource impliqués.
Simulateur de politique IAM : Un outil puissant dans la console IAM pour tester les effets de différentes politiques sur des actions spécifiques.

3. Limites de service et limitation

Les services AWS ont des limites souples et dures. Atteindre ces limites peut provoquer des erreurs ou une dégradation des performances (ThrottlingException, TooManyRequestsException).

Métriques CloudWatch : Surveillez les métriques spécifiques au service pour détecter des signes de limitation, comme DynamoDB ReadThrottleEvents ou Lambda Throttles.
Console des quotas de service : Cette console répertorie tous vos quotas de service AWS, leur utilisation actuelle et vous permet de demander des augmentations pour les quotas ajustables.
Backoff exponentiel et nouvelles tentatives : Implémentez ces modèles dans vos applications lors de l'interaction avec les API AWS pour gérer gracieusement la limitation temporaire.

4. Mauvaises configurations de ressources

Des ressources mal configurées sont une cause fréquente de problèmes.

Stockage : Autorisations de bucket S3 incorrectes (accès public), volumes EBS non chiffrés, IOPS insuffisantes pour EBS.
Calcul : Mauvais type d'instance EC2, AMI incorrecte, données utilisateur mal configurées, problèmes de groupe de mise à l'échelle automatique.
Bases de données : Problèmes de chaîne de connexion, mauvaise configuration du groupe de sécurité, paramètres du groupe de paramètres.
Équilibreurs de charge : Règles d'écouteur incorrectes, groupes cibles malsains, problèmes de groupe de sécurité.
AWS Config : Utilisez Config pour suivre les modifications des configurations de ressources au fil du temps, aidant à identifier quand une configuration incorrecte a été introduite.

5. Problèmes spécifiques à l'application

Même avec des services AWS fonctionnant parfaitement, le code de l'application peut avoir des problèmes.

Journaux d'application : Assurez-vous que les journaux de votre application sont envoyés vers CloudWatch Logs. Analysez-les pour détecter des erreurs, des exceptions ou des comportements inattendus.
Métriques d'application : Émettez des métriques CloudWatch personnalisées à partir de votre application (par exemple, nombre d'erreurs, latence des requêtes, profondeur de file d'attente) pour des informations plus approfondies.
AWS X-Ray : Pour les applications distribuées, X-Ray offre une visibilité de bout en bout, traçant les requêtes lorsqu'elles traversent divers services et identifiant les goulots d'étranglement de performance ou les erreurs.

Meilleures pratiques pour réduire le MTTR

Une bonne préparation réduit le travail de détection nécessaire lors d'un incident.

Surveillance et alertes proactives : Implémentez des alarmes CloudWatch complètes pour les métriques critiques (utilisation CPU, taux d'erreur, latence, espace disque, erreurs API). Intégrez avec SNS pour envoyer des notifications à PagerDuty, Slack ou par e-mail.
Journalisation centralisée : Agrégez les journaux de tous vos services (EC2, Lambda, conteneurs, etc.) dans CloudWatch Logs ou un lac de données basé sur S3 pour une recherche et une analyse faciles.
Infrastructure en tant que code (IaC) : Utilisez CloudFormation, AWS CDK ou Terraform pour définir votre infrastructure. Cela garantit la cohérence, réduit les erreurs manuelles et facilite l'annulation des modifications.
Runbooks et playbooks : Documentez les problèmes courants, leurs symptômes, les étapes de diagnostic et les procédures de résolution. Cela permet à votre équipe de résoudre les problèmes rapidement et de manière cohérente.
Adoptez le cadre AWS Well-Architected : Concevez vos systèmes en tenant compte de l'excellence opérationnelle, de la sécurité, de la fiabilité, de l'efficacité des performances et de l'optimisation des coûts. Une conception proactive évite de nombreux problèmes.
Audits et examens réguliers : Examinez périodiquement les règles des groupes de sécurité, les politiques IAM et les configurations de ressources pour vous assurer qu'elles sont conformes aux meilleures pratiques et aux exigences actuelles.
Tirez parti du support AWS : Pour les problèmes complexes que vous ne pouvez pas résoudre, ou si vous soupçonnez un problème de service côté AWS, ouvrez un dossier de support si votre plan de support le permet. Incluez les ID de ressource, les régions, les horodatages avec fuseaux horaires, les messages d'erreur, les ID de requête et les étapes que vous avez déjà essayées.

À retenir

Commencez chaque problème de service AWS avec le même rythme : définissez le symptôme, vérifiez les modifications récentes, rassemblez les journaux et métriques, testez une hypothèse à la fois, puis documentez le correctif. Cette habitude maintient votre calme lorsque l'incident ne l'est pas.