Les pannes répétées d’AWS : pourquoi une seule liaison réseau en Oregon continue de casser Internet

La même liaison réseau a échoué deux fois en quelques semaines

Le 24 juillet 2026, la région us-west-2 d’AWS — l’une de ses plus importantes, basée en Oregon — a perdu sa connectivité vers l’extérieur via une route physique spécifique. Selon un compte rendu détaillé de l’incident, le matériel réseau assurant le routage entre la région et Seattle Metro est tombé en panne à 10h55 UTC. Les ingénieurs d’AWS sont intervenus dès 11h01 UTC, la connectivité a commencé à revenir à 11h15 UTC, et la convergence complète du routage n’a été achevée qu’à 11h59 UTC — avec une perturbation secondaire de Direct Connect persistant jusqu’à 12h12 UTC, soit une fenêtre d’incident totale d’environ 77 minutes.

Dix services AWS ont été affectés durant cette fenêtre, selon le rapport d’incident : Direct Connect, Global Accelerator, Internet Connectivity, IoT Core, Site-to-Site VPN, API Gateway, EC2, ECS, Elastic Load Balancing et VPC. Fait crucial, le calcul (compute) fonctionnant à l’intérieur de la région a continué de fonctionner normalement — la défaillance se situait spécifiquement à la frontière d’entrée/sortie, ce qui signifie que le trafic déjà à l’intérieur d’us-west-2 se portait bien, mais que tout ce qui tentait de traverser la bordure de la région ne le pouvait pas.

Quelques semaines plus tard, la même signature de défaillance s’est reproduite. AWS a de nouveau attribué la perturbation à un problème de connectivité internet et de matériel réseau sur la liaison réseau reliant sa région US-WEST-2 à la zone de Seattle Metro, qui a également brièvement affecté la région voisine US-WEST-1. La répétition d’une description de cause racine identique — la même liaison réseau régionale — est le détail qui a transformé un incident isolé en un schéma méritant un examen approfondi.

Des produits bien réels se sont retrouvés hors ligne

La panne du 24 juillet n’était pas un événement d’infrastructure abstrait. Selon un rapport sur la perturbation, le PlayStation Network de Sony s’est retrouvé hors ligne pour les utilisateurs pendant la fenêtre de l’incident — une victime visible et grand public d’une défaillance réseau en arrière-plan dont la plupart de ces utilisateurs n’auraient autrement jamais soupçonné l’existence.

C’est la forme générale que prend le risque moderne de concentration du cloud : une seule panne matérielle sur une liaison réseau d’une zone métropolitaine peut mettre hors service, en silence, des services sans lien apparent entre eux ni avec l’Oregon, simplement parce qu’ils font tous transiter leur trafic par la même bordure régionale.

Un schéma récurrent, pas un incident isolé

Des observateurs d’incidents ont documenté la panne d’us-west-2 du 24 juillet comme la troisième défaillance majeure d’infrastructure en neuf jours à l’échelle du secteur, après une panne de CloudFront d’AWS le 16 juillet et une panne d’Azure West US le 23 juillet — deux de ces trois incidents étant spécifiquement liés au réseau de bordure régionale plutôt qu’à des défaillances de calcul ou de stockage. Le même rapport d’incident a recensé neuf incidents en aval confirmés chez sept autres fournisseurs dont les services dépendent de l’infrastructure AWS concernée, ainsi que trois incidents en cascade supplémentaires possibles.

Le schéma s’est poursuivi en août. La couverture de cette répétition l’a qualifiée de partie d’un quatrième incident de fiabilité notable chez AWS en l’espace d’environ quatre mois en 2026, après des incidents antérieurs incluant un événement thermique de centre de données en mai et une perturbation réseau distincte en juin, la répétition d’août ayant duré environ 80 minutes entre les premiers signalements des clients et l’avis de résolution d’AWS.

Pourquoi cela continue d’inquiéter les régulateurs

AWS reste le plus grand fournisseur d’infrastructure cloud, et de loin. Selon des données de Synergy Research Group citées par The Register, AWS détenait 28 % du marché mondial de l’infrastructure cloud au deuxième trimestre 2026, devant les 20 % de Microsoft Azure et les 15 % de Google Cloud — les trois acteurs réunis représentant 67 % de l’ensemble des revenus du cloud ce trimestre-là, contre 63 % un an plus tôt.

Cette échelle explique précisément pourquoi une seule liaison réseau en Oregon a des conséquences bien au-delà de l’Oregon. La couverture de la répétition du mois d’août a noté que l’infrastructure financière grand public — d’Apple Pay à Coinbase en passant par CME Direct — a été touchée par un incident AWS à un moment ou un autre de 2026, et a averti que les inquiétudes relatives au risque de concentration, latentes à Washington et à Bruxelles depuis 2025, pourraient ressurgir maintenant qu’un quatrième incident s’est produit en l’espace de quelques mois sur la même famille d’infrastructure. Lorsqu’un marché aussi concentré subit des défaillances répétées avec une cause racine identique déclarée, la question passe de « était-ce de la malchance » à « s’agit-il d’une faiblesse architecturale qu’AWS n’a pas encore corrigée ».

Ce que cela signifie pour les équipes techniques dépendant d’une seule région cloud

1. Cartographiez votre véritable rayon d’impact avant le prochain incident, pas pendant

La plupart des équipes savent quels services tournent « dans AWS us-west-2 ». Moins nombreuses sont celles qui savent lesquels de ces services dépendent spécifiquement d’un trafic inter-régions ou de sortie internet, par opposition à un trafic qui reste entièrement à l’intérieur de la région. Étant donné que l’incident du 24 juillet a laissé le calcul intrarégional fonctionner normalement alors que seul le trafic traversant la bordure a échoué, les équipes devraient auditer leur architecture spécifiquement pour les équilibreurs de charge exposés à internet, les points de terminaison API Gateway, les liaisons Direct Connect et les tunnels Site-to-Site VPN — la liste exacte des services qu’AWS a confirmé comme affectés — car ce sont les composants les plus exposés à la répétition de ce mode de défaillance spécifique.

2. Considérez « le matériel réseau entre la région et sa zone métropolitaine » comme un risque nommé dans votre plan de résilience

Une entrée de risque vague du type « AWS pourrait subir une panne » n’est pas actionnable. Une entrée précise — « la liaison réseau entre us-west-2 et Seattle Metro a échoué au moins deux fois ces derniers mois avec la même cause déclarée » — impose une décision concrète : accepter le risque, ajouter une région secondaire pour le trafic destiné à internet, ou ajouter un fournisseur cloud secondaire pour les services les plus exposés. Les déploiements AWS multi-régions génériques qui font toujours transiter tout le trafic externe par la même liaison métropolitaine physique ne résolvent pas réellement ce problème.

3. Construisez et testez un véritable basculement inter-régions spécifiquement pour le trafic destiné à internet

Puisque le mode de défaillance concerne le trafic traversant la bordure plutôt que le calcul, une stratégie de basculement qui ne gère que le scénario « toute la région est en panne » ne se déclenchera pas correctement lorsque la défaillance réelle est « la région fonctionne en interne mais ne peut pas atteindre internet ». L’automatisation du basculement doit spécifiquement tester l’accessibilité externe, pas seulement les contrôles de santé des instances, et doit être validée face à une simulation de défaillance de sortie, pas seulement une simulation de panne régionale.

4. Réévaluez le multi-cloud comme une décision de résilience, pas seulement de coût ou de dépendance à un fournisseur

La cause racine récurrente dans ces incidents — du matériel réseau physique sur une liaison métropolitaine spécifique — est le type de défaillance qu’une seconde région AWS ne peut pas entièrement prévenir si les deux régions partagent une infrastructure réseau ou des points de peering en amont. Pour les services où même une heure d’inaccessibilité externe est inacceptable (paiements, infrastructure de jeu en temps réel, systèmes critiques pour la sécurité), évaluez si un second fournisseur cloud pour cette charge de travail spécifique est désormais justifié compte tenu de la fréquence des incidents documentée par AWS en 2026, plutôt que de considérer le multi-cloud uniquement comme un levier de négociation tarifaire.

La leçon structurelle

Aucun des incidents d’AWS en 2026 ne semble catastrophique pris individuellement — des durées mesurées en dizaines de minutes à un peu plus d’une heure, avec le calcul intrarégional non affecté à chaque fois. Ce qui rend le schéma significatif, c’est la combinaison de la récurrence, d’une cause racine identique déclarée, et de la part démesurée de 28 % d’AWS sur un marché lui-même de plus en plus concentré entre trois fournisseurs contrôlant 67 % des revenus mondiaux du cloud. Une liaison réseau fragile entre une région et une zone métropolitaine est un problème d’ingénierie local lorsqu’il se produit une fois. Lorsque la même liaison échoue à nouveau avec la même explication quelques semaines plus tard, et que l’infrastructure financière et de divertissement grand public — d’Apple Pay à PlayStation Network — se retrouve à chaque fois dans le rayon d’impact, cela devient une question systémique sur la part de la plomberie d’internet qui transite par des points qu’AWS n’a pas encore renforcés.

Questions Fréquemment Posées

Sources et lectures complémentaires

• The July 24, 2026 AWS us-west-2 Outage: Network Routing and a Long Recovery Tail — IncidentHub
• AWS Outage Hits US-West-2: 4th Incident in 4 Months [2026] — Tech Insider
• The PSN is back online after AWS outage — TheSixthAxis
• Enterprise cloud infrastructure uptake shows no sign of slowing — The Register