Amazon Web Services est-il en panne ?

Fonctionnement de la disponibilité d’AWS

Amazon Web Services regroupe des services cloud qui fonctionnent sur plusieurs comptes, régions et zones de disponibilité — il ne s’agit pas d’une seule application avec un état de disponibilité universel. Un incident affectant un service ou une région donné peut laisser d’autres workloads AWS fonctionner normalement.

Commencez par consulter la page officielle d’état AWS Health. Comparez chaque événement avec le service, la région, la ressource, le compte ou l’environnement affecté, ainsi qu’avec l’heure approximative du début de la panne. En l’absence d’événement correspondant, recherchez d’abord les causes liées au compte, au workload, à la configuration et à la connectivité avant de considérer le problème comme une panne générale d’AWS.

Une page d’état publique saine ne prouve pas que chaque ressource fonctionne correctement. Les identifiants, les autorisations, le DNS, le routage, les contrôles de sécurité, la sélection de l’endpoint, les changements de déploiement et le code de l’application peuvent tous affecter un service reposant sur AWS.

Diagnostiquer les pannes AWS

1. Vérifier la présence d’un incident de service ou régional

Ouvrez la page officielle d’état AWS Health et recherchez un événement correspondant au service, à la région et à l’heure approximative du début de la panne. La présence d’un événement correspondant rend plus probable un problème côté fournisseur. Évitez de modifier à répétition les paramètres de production ou de redéployer des ressources pendant l’analyse d’un incident.

Si aucun événement correspondant n’apparaît, le problème peut être limité à un compte, un workload, une région, une ressource ou un chemin réseau.

2. Identifier la couche en panne

Définissez précisément l’opération qui échoue : ouvrir la console AWS, déployer du code, résoudre un nom d’hôte, appeler un endpoint AWS, lire des données depuis un stockage ou se connecter à une base de données. Vérifiez si des ressources ou services indépendants de la même région fonctionnent encore.

Comparez la panne avec un déploiement ou un changement de configuration récent. Consultez les logs pour relever l’erreur AWS exacte, l’heure de la requête, la région, l’identifiant de la ressource et l’opération. Une réponse HTTP 5xx ne montre pas à elle seule qu’AWS est indisponible ; elle peut avoir été générée par l’application, le proxy, le load balancer ou la gateway.

3. Vérifier les causes liées au compte, aux autorisations et à la configuration

Pour une panne limitée à un compte, un environnement ou une ressource, vérifiez la région sélectionnée, l’état de la ressource, les identifiants, les autorisations, l’endpoint, les quotas et les changements récents de l’infrastructure. Confirmez que l’application utilise bien le compte et la région prévus. Si une identité ou un déploiement échoue alors qu’un chemin connu pour fonctionner est disponible, examinez les accès et la configuration avant de considérer le problème comme généralisé à la plateforme.

4. Vérifier les problèmes propres au navigateur et à la console

Si la console AWS ou une application hébergée échoue dans un seul navigateur ou sur un seul appareil, essayez une fenêtre privée, un autre navigateur pris en charge ou un autre appareil. Notez l’erreur affichée avant d’effacer les données du site. Un problème limité à la console peut être indépendant de l’état des ressources AWS sous-jacentes.

5. Vérifier le réseau, le DNS et la connectivité

Effectuez un test depuis un second réseau lorsque cela est possible. Comparez la résolution DNS, la négociation TLS et le comportement de la connexion pour le nom d’hôte concerné. Les échecs DNS, les refus de connexion, les erreurs de certificat et les délais d’attente peuvent provenir du DNS local, des paramètres du VPN ou du proxy, des règles du pare-feu, du routage, des security groups, des network ACLs, des listeners du load balancer ou de l’application de destination.

Si la requête fonctionne depuis un autre réseau ou une autre région, examinez le chemin entre le client et AWS plutôt que de supposer une panne mondiale.

6. Vérifier les échecs liés au SDK, à la CLI, aux webhooks et à l’automatisation

Capturez la catégorie complète de l’erreur et l’opération concernée. Distinguez les erreurs d’authentification ou d’autorisation des erreurs de throttling, de validation, d’endpoint, de délai d’attente et des erreurs côté serveur. Confirmez la région et l’endpoint configurés, puis ne réessayez que si l’opération peut être répétée sans risque. Pour les changements en production, conservez les request IDs et les horodatages afin de faciliter le diagnostic ou l’escalade auprès du support.