La panne d'AWS et le rôle du load balancing

Une application peut avoir plusieurs serveurs et rester vulnérable à une seule panne. S'ils dépendent tous du même service pour résoudre des adresses, créer de la capacité ou recevoir du trafic, cette dépendance limite la reprise.

La panne

En octobre 2025, le DNS de DynamoDB a échoué dans us-east-1. La reprise d'EC2 a accumulé des retards réseau. Les health checks NLB ont ensuite retiré des capacités saines du service. Le rapport AWS décrit cet enchaînement.

La distinction compte. La version initiale de cet article attribuait le début de la panne à la surveillance des répartiteurs. Le rapport ultérieur permet de corriger cette explication.

Pour comprendre le rôle du load balancing dans cette chaîne, commençons par son fonctionnement dans une application courante.

Qu'est-ce que le load balancing ?

Imaginez un restaurant avec une seule caisse. Si 50 personnes arrivent ensemble, une file se forme. Ouvrir d'autres caisses permet de partager le travail, à condition d'organiser la répartition.

Le load balancing, ou répartition de charge, distribue le trafic entre des serveurs. Dans une application web, le répartiteur reçoit les requêtes et choisit une destination disponible. Cela réduit la concentration du travail sur une machine, mais ne crée pas une capacité illimitée.

Comment ça fonctionne

Une requête peut suivre ce chemin :

[Utilisateur] → [Load balancer] → [Serveur 1]
                               → [Serveur 2]
                               → [Serveur 3]
                               → [Serveur 4]

L'application doit supporter cette répartition. Si la session existe seulement dans la mémoire d'un serveur, la requête suivante envoyée ailleurs risque de ne pas la trouver. Le choix du stockage de l'état fait partie de l'architecture.

Stratégies de répartition

Round robin alterne les destinations dans l'ordre. Least connections préfère le serveur ayant le moins de connexions actives. Le choix dépend du trafic. Une connexion longue ne représente pas le même travail qu'une réponse courte.

Des poids permettent d'envoyer des proportions différentes vers des serveurs de capacités différentes. Certaines stratégies utilisent l'adresse IP du client pour conserver une affinité avec une destination. Le routage géographique choisit à un autre niveau, celui de la région qui reçoit le trafic. Les options dépendent du répartiteur.

Health checks

Les health checks vérifient périodiquement des critères définis. Application Load Balancer d'AWS utilise des intervalles et des seuils de réussites ou d'échecs pour changer l'état d'une cible. Le retrait n'est pas immédiat. Voir sa documentation.

La question posée par le test compte aussi. Un endpoint toujours positif peut ignorer un processus incapable de traiter les commandes. À l'inverse, exiger le fonctionnement de tous les services externes peut retirer des serveurs encore capables d'effectuer une partie du travail.

Pourquoi utiliser un répartiteur ?

Il permet d'ajouter des serveurs et de leur distribuer de nouvelles requêtes. Il aide aussi à la maintenance. On peut cesser d'envoyer de nouvelles requêtes à une destination et attendre la fin du travail en cours avant de l'arrêter.

Quand un serveur tombe, les autres peuvent recevoir les nouvelles requêtes. Ils doivent disposer de capacité libre. Si quatre machines fonctionnent déjà à leur limite, en perdre une augmente la pression sur les autres.

Cette répartition ne transfère pas automatiquement une opération déjà en cours. L'application doit définir ce que voit l'utilisateur et si une nouvelle tentative peut éviter de dupliquer les effets.

L'effet domino

Les quatre serveurs du schéma peuvent cacher une seule base de données, une seule file ou une configuration commune. Multiplier les serveurs ne duplique pas ces dépendances.

Notre recommandation opérationnelle est de tester la reprise lorsqu'une dépendance est indisponible. Créer des instances supplémentaires pendant une panne aide seulement si leur création fonctionne encore. Envoyer tout le trafic aux destinations restantes demande aussi de connaître leur capacité.

Que tester dans votre application ?

Retirez un serveur du service dans un environnement contrôlé et observez les requêtes en cours. Vérifiez ensuite si les destinations restantes supportent la charge et combien de temps la surveillance met à détecter le changement.

Testez aussi une dépendance lente. Relevez quand l'application cesse d'attendre, combien de tentatives elle effectue et comment elle empêche leur accumulation indéfinie dans la file.

Le répartiteur gère la distribution du trafic. La disponibilité dépend également de ces décisions. Parlez avec Tucupy si vous devez revoir la réaction de votre système aux pannes.

Texte révisé le 12 septembre 2026 pour corriger l'explication de l'incident.