AWS cumule quatre incidents en quatre mois, dont deux sur le même chemin réseau

24 juillet 2026, 7 h 40 (heure de New York). Les trackers de pannes s’allument en même temps : Apple Pay, DoorDash, Reddit, Hulu et le PlayStation Network cessent de répondre. Le point commun est la région US-WEST-2 d’AWS, en Oregon, dont un problème de connectivité internet déborde sur une partie du web grand public. Début août 2026, un second incident frappe le même chemin réseau. C’est le quatrième incident notable d’AWS en quatre mois — et le signal n’est pas tant le nombre que la répétition d’un même point de défaillance.

Pour un SRE ou un RSSI qui héberge de la production dans us-west-2, ce n’est plus une anecdote. C’est un motif récurrent qui change la manière de parler du risque mono-fournisseur en réunion de planification.

Le 24 juillet, minute par minute

Les premiers signalements remontent sur Downdetector peu après 6 h 40 (heure de New York). AWS reconnaît le problème à 4 h 40 (heure du Pacifique) et confirme enquêter sur la connectivité de US-WEST-2. À 8 h 01, l’entreprise annonce avoir identifié la cause racine ; à 8 h 14, US-WEST-2 est rétabli, après que US-WEST-1 l’a été quatre minutes plus tôt. Vers 9 h, la perturbation est terminée : environ 80 minutes au total.

AWS a classé l’événement comme « impaired » — une désignation interne pour un incident visible sans mise hors ligne complète de la région. Dix offres ont été nommées dans les mises à jour de statut : Direct Connect, Global Accelerator, Internet Connectivity, IoT Core, Site-to-Site VPN, API Gateway, EC2, ECS, ELB et VPC. Aucune n’est un produit grand public, mais toutes se situent sous les applications des autres — ce qui explique pourquoi un incident backend s’est transformé en titres sur Reddit et Hulu.

Le comptage indépendant d’IncidentHub recense 9 incidents en cascade chez 7 fournisseurs liés à la panne. AWS précise qu’aucune donnée client n’a été perdue et n’attribue pas l’incident à une cyberattaque.

Une cause nommée, une cause commune non tranchée

Le langage public d’AWS pour le 24 juillet est plus précis qu’un simple « problème de connectivité » : un problème matériel de connectivité internet et de réseau sur la route reliant US-WEST-2 à la zone métropolitaine de Seattle. L’entreprise n’a pas précisé quel équipement a lâché, ni si la panne venait de son propre réseau ou plus loin sur le chemin vers Seattle.

C’est une divulgation plus mince que celle de mai 2026, où AWS avait identifié une panne de refroidisseur dans un datacenter de Virginie du Nord, et bien plus mince que le rapport détaillé publié après l’incident d’octobre 2025, qui nommait le sous-système exact (la gestion DNS de DynamoDB) et le mode de défaillance — une condition de course entre deux « Enactors » DNS automatisés dans des zones de disponibilité différentes.

Début août 2026, AWS a pointé vers le même chemin réseau lors d’un second incident plus court sur US-WEST-2. Le support a indiqué sur X une résolution entre 3 h 55 et 4 h 15 (heure du Pacifique), soit 20 minutes, suivie d’un bref événement de reconvergence avec des routages intermittents de 4 h 47 à 4 h 59. AWS a de nouveau désigné les équipements réseau qui acheminent le trafic de la région vers Seattle. L’entreprise n’a pas confirmé si les deux incidents partagent une cause racine ou sont des pannes distinctes sur le même tronçon.

Quatre incidents, quatre couches différentes

Mettre côte à côte les incidents 2026 d’AWS révèle un motif qui tient moins au nombre qu’à la diversité des couches touchées.

Mai était un problème d’infrastructure physique : une panne de refroidisseur dans une seule zone de disponibilité. Juin se situait une couche plus haut, dans de l’infrastructure tierce liée à Zayo. Juillet et août pointent vers une troisième couche : le matériel réseau face à internet reliant US-WEST-2 à Seattle.

Cette distinction par couche compte davantage qu’un simple compteur d’incidents. Une panne de refroidisseur et une panne réseau sur une même route appellent des remédiations différentes : la redondance physique règle la première, tandis que la diversité des chemins réseau ou une connectivité de sortie secondaire règle la seconde. Traiter « quatre incidents » comme un seul problème de fiabilité risque d’orienter les budgets vers le mauvais correctif. Traiter juillet et août comme un cluster de deux incidents sur le même chemin réseau est un constat plus étroit, plus actionnable — et c’est celui que les déclarations publiques d’AWS soutiennent le mieux.

Pourquoi us-west-2 et us-east-1 concentrent le risque

La quasi-totalité des incidents les plus perturbants d’AWS sur la dernière décennie remonte à deux régions : US-EAST-1 (Virginie du Nord) et, désormais, US-WEST-2 (Oregon). Ce n’est pas un hasard. US-EAST-1 est la région d’origine, lancée en 2006, toujours région par défaut d’innombrables applications et hôte de fonctions de plan de contrôle dont d’autres régions dépendent. US-WEST-2 porte une concentration analogue sur la côte ouest, prisée pour la latence vers l’Asie-Pacifique et choisie comme région secondaire il y a des années par des entreprises qui n’en sont jamais parties.

Les équipes fiabilité prônent le multi-région depuis des années à cause de cette concentration. Le frein, c’est le coût : un actif-actif sur deux régions double à peu près les transferts de données et la charge opérationnelle pour beaucoup de workloads, ce qui explique pourquoi tant d’entreprises — y compris des groupes milliardaires — font encore tourner du critique en région unique. Un outil de visibilité des coûts permet de chiffrer cette redondance avant de s’engager.

Ce que le marché ne dit pas encore

Aucun de ces incidents n’a érodé la position d’AWS d’une manière visible dans les chiffres. Au premier trimestre 2026, AWS conserve 28 % du marché mondial de l’infrastructure cloud selon Synergy Research Group, devant Azure (21 %) et Google Cloud (14 %). Les dépenses d’infrastructure cloud d’entreprise ont atteint 129 milliards de dollars au T1 2026, en hausse de 35 % sur un an, portées par la demande en IA.

Azure et Google Cloud croissent plus vite en pourcentage — 40 % et 63 % contre 19 % pour AWS — mais c’est une histoire de bases plus petites qui rattrapent, pas de clients qui fuient AWS pour un incident de 80 minutes. Les contrats cloud courent sur des années et les coûts de migration sont lourds. Ce qui change, en revanche, c’est le ton des équipes internes : quatre incidents en quatre mois suffisent à inscrire une ligne au budget du prochain trimestre pour les tests de reprise, les exercices de bascule multi-région, ou au minimum un audit des charges de production encore mono-point de défaillance.

Verdict

Le chiffre « quatre incidents en quatre mois » est un artefact de calendrier ; le signal durable, lui, est le cluster juillet-août sur le même chemin réseau reliant US-WEST-2 à Seattle, qu’AWS n’a toujours pas relié à une cause commune. C’est ce point précis qui doit dicter vos décisions.

Si votre production tourne en région unique dans us-west-2, vous êtes exposé à un point de défaillance que la multi-AZ ne couvre pas : quand c’est la connectivité internet de la région entière qui flanche, répartir vos instances sur plusieurs zones de disponibilité ne sert à rien. Prévoyez l’une des deux options — une bascule multi-région documentée et testée pour les services critiques, ou au minimum une connectivité de sortie diversifiée hors du chemin Seattle. Si vous êtes déjà multi-région, votre prochaine action est plus simple : vérifiez que votre plan de bascule ne repose pas, lui aussi, sur une seule route réseau vers US-WEST-2.

Le confort de la région unique se paie désormais en probabilité, pas en hypothèse : deux pannes sur le même tronçon en un mois, c’est un motif, pas une coïncidence.

Références

• Tech Insider, « AWS Outage Hits US-West-2: 4th Incident in 4 Months », mis à jour août 2026.
• AWS Health Dashboard, mises à jour de statut du 24 juillet 2026.
• IncidentHub, comptage des incidents en cascade du 24 juillet 2026.
• Synergy Research Group, parts de marché de l’infrastructure cloud au T1 2026.
• AWS, « Summary of the October 19, 2025 Amazon DynamoDB Service Event », message 101925.