La panne d’AWS ravive la crainte que l’internet mondial dépende d’un petit nombre d’entreprises

• La panne d’AWS, le plus grand service de cloud, a provoqué l’arrêt de milliers de sites web et d’applications, mettant en avant l’alerte selon laquelle l’infrastructure internet dépend de manière excessive de quelques entreprises
• La panne a touché des services majeurs tels que Snapchat, Roblox, Signal, Duolingo, ainsi que des institutions publiques et financières comme Lloyds Bank, Ring, HMRC
• AWS a attribué la panne à une erreur de son système interne dans la région US-East et a exclu une cyberattaque ; la plupart des services ont été rétablis en quelques heures
• Les experts ont souligné qu’« il ne faut pas que les fondements du débat démocratique et du journalisme reposent sur les infrastructures de quelques entreprises », en insistant sur la nécessité de diversifier l’infrastructure cloud
• L’évaluation selon laquelle une structure dominée par de grands acteurs cloud a révélé la vulnérabilité d’Internet au niveau mondial a relancé le débat sur la souveraineté technologique des infrastructures publiques

---

Aperçu de la panne

• Une panne massive de services mondiaux est survenue après une erreur interne sur la région US-East-1 d’AWS
  • L’incident a débuté vers 8 h heure locale, lundi (16 h au Royaume-Uni)
  • Amazon a annoncé que le taux d’erreurs API et la latence avaient augmenté
  • Selon Downdetector, plus de 2 000 entreprises ont été touchées dans le monde, avec plus d’1,9 million de signalements aux États-Unis, 1 million au Royaume-Uni et 410 000 en Australie
• AWS a désigné comme cause un problème du sous-système de surveillance de son équilibrage de charge interne, en excluant la possibilité d’une cyberattaque
  • Un défaut lié à DynamoDB aurait provoqué des échecs de réponse API
  • Pour éviter une explosion de trafic, une limitation temporaire des requêtes a été mise en place
• AWS a officiellement annoncé un retour à un fonctionnement normal en fin de journée, mais certains services ont continué à signaler des incidents

Portée de l’impact

• Principaux services : Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton, parmi de nombreux autres
• Au Royaume-Uni, l’accès à des services financiers tels que Lloyds, Halifax, Bank of Scotland et au site web de HMRC (l’agence fiscale) a été interrompu
• Les utilisateurs de Ring Doorbell ont indiqué que le service de surveillance d’ouverture de porte était indisponible
• Des incidents de non-disponibilité ont également été signalés sur des plateformes mondiales telles que Epic Games, Pokémon Go, Wordle

Analyse d’experts

• Dr Corinne Cath-Speth (Article 19) : « La dépendance des bases du discours démocratique et du journalisme indépendant vis-à-vis de l’infrastructure d’un petit nombre d’entreprises est dangereuse. La diversification du cloud est urgente. »
• Cori Crider (Future of Technology Institute) : « Le Royaume-Uni doit s’extraire d’une dépendance envers la Big Tech américaine. L’incident d’AWS illustre une économie moderne entièrement paralysée par la panne d’un seul acteur. »
• Madeline Carr (UCL) : « Bien que la sécurité et l’évolutivité soient maintenues grâce au poids financier des grands acteurs cloud, une structure qui lie le monde entier au même risque reste extrêmement dangereuse. »
• Steven Murdoch (UCL) : « On estime que la cause ne serait pas une cyberattaque, mais une erreur opérationnelle interne à AWS. »

Réponses gouvernementales et réglementaires

• Le gouvernement britannique a annoncé avoir activé des contacts d’urgence avec AWS et avoir surveillé la progression de la restauration
• La commission des finances de la Chambre des communes a appelé à ce que AWS soit désigné comme « critical third party » dans le secteur financier
  • Ce statut permettrait de placer AWS sous la supervision des autorités de régulation financière, avec ainsi la possibilité de garantir la stabilité de l’infrastructure financière
  • La présidente Meg Hillier a critiqué le fait qu’AWS affirme offrir de la résilience tout en révélant en réalité des vulnérabilités

Contexte et implications

• Avec plus de 30 % de parts de marché dans le cloud mondial, AWS occupe la première place
• Avec Microsoft Azure et Google Cloud, une structure de concentration autour de trois grands acteurs cloud se dessine
• En 2024 déjà, une erreur logicielle de CrowdStrike a provoqué une vague de « Blue Screen » touchant les PC Windows dans le monde entier
• Cet incident a de nouveau mis en lumière le risque systémique de la concentration de l’infrastructure numérique et a relancé le débat, dans plusieurs pays, sur la souveraineté technologique et les stratégies de diversification du cloud

[chickendreamtree]

Bon courage, Naver Cloud !

[kimjoin2]

« Si le cloud vous déplaît, déployez-le vous-même et utilisez-le. » Je me demande si on peut vraiment en discuter.
Le multi-cloud ? Le déploiement et la gestion, ce n’est pas quelque chose qu’on fait à votre place.

[GN⁺]

Opinion de Hacker News

• Plusieurs services sur AWS us-east-1 semblent être en panne et la discussion est en cours, avec un long thread ici

• Lors de la panne Fastly en 2021, des “experts” ont déjà fait des critiques similaires, mais aucun changement tangible ne s’est produit. Une semaine plus tard, ce sujet n’apparaît plus dans la presse. Les praticiens savent combien il est difficile d’opérer à l’échelle d’AWS. Les vraies précautions pour se préparer à ce type de situation coûtent tellement cher que l’intérêt concret est quasi nul pour la majorité des entreprises. Si un service est vraiment “critique”, il faut bien le concevoir pour se protéger contre ce type de panne. Le fait de ne pas pouvoir se connecter à Fortnite montre à quel point il n’est pas facile en pratique de s’y préparer et quel coût cela représente. Les médias, en temps normal, ne parlent pas de l’importance du multi-région ou du multi-cloud, puis n’en parlent qu’au moment d’un incident avant d’oublier vite. Au final, la curiosité porte surtout sur la cause technique. Les reproches des “experts” sans suites n’ont guère de sens. L’essentiel n’est pas la critique sans suivi, mais une postmortem constructive et sans blame.

  • Les “experts” mentionnés ici n’ont pas d’expérience réelle de l’infrastructure ou de l’exploitation cloud. Par exemple, Dr Corinne Cath‑Speth est anthropologue, Cori Crider est avocate, et Madeline Carr est professeure de science politique. Ce sont donc des gens qui rédigent des papiers et donnent des interviews médiatiques, sans expérience concrète d’exploitation d’un service d’hébergement.
  • En critiquant la dépendance au cloud, on finit par accepter qu’il faut en pratique anticiper plus de 16 heures d’indisponibilité par an. Une panne de quelques heures est bien ressentie par un individu, mais une baisse de performance peut être bien plus fatale pendant les 8 742 heures restantes. Si 16 heures d’indisponibilité suffisaient à faire tomber une entreprise, c’est que toi ou moi nous ne comprenons pas le business. Je suis plus intéressé par des systèmes à haute disponibilité, la redondance géographique et la haute durabilité.
  • Il n’est pas nécessaire de dépenser des sommes énormes; tous les services n’ont pas besoin d’encaisser pareil. Mettre en place des fournisseurs différents permet de faire en sorte qu’ils ne soient pas tous impactés en même temps.
  • La redondance multi-région/multi-cloud mise en avant par la presse est mise en avant comme étant peu efficace. Même si, de l’extérieur, on a l’impression qu’un seul région est touchée, il arrive souvent que les services soient impactés sur plusieurs régions. Le “hot standby” multi-cloud devient coûteux à mesure que l’infrastructure se complique. Le déployer plus tard, sans planification initiale, est très compliqué.
  • Les rapports publiés par AWS lui-même montrent une concentration excessive sur certaines régions et certains services (par ex. DynamoDB). Ce type d’architecture centralisée est observé depuis plus de dix ans. La question, c’est pourquoi ça ne change pas. Plus de 2 000 services sont restés hors service longtemps lors de cet incident. AWS health page

• Il vaut sans doute la peine de remplacer les mots “cloud” ou “internet” par “entrepôt de Virginie”. Par exemple : “Notre service est entièrement dans l’entrepôt de Virginie”, “Tous mes fichiers sont dans l’entrepôt de Virginie”, “L’entrepôt de Virginie est conçu pour résister à une guerre nucléaire”, etc. original

  • En pratique, cet entrepôt (l’entrepôt de Virginie) est plutôt bon. Les blagues et analogies autour du cloud négligent des alternatives réelles. Pour la plupart des entreprises, l’alternative réaliste au cloud est l’étagère dans le couloir du bureau. Avant l’arrivée d’un responsable IT, il était courant que quelqu’un qui tirait le code fasse tomber toute la boîte.

• Il existe déjà de nombreux fournisseurs de VPS, et des cas de baisse de coûts en basculant vers cette option apparaissent régulièrement, ce qui montre que c’est surtout un problème de cloud lock-in et de marketing.

  • Aujourd’hui, les entreprises n’utilisent pas des services IaaS bas niveau comme EC2, mais des services PaaS haut de gamme d’AWS tels que DynamoDB ou RedShift. Azure et Google Cloud sont dans la même situation. En étant dépendant de ces services de haut niveau, migrer vers un VPS comme Hetzner ou du self-hosting signifie réinstaller et exploiter de nouveau la stack AWS, ce qui est extrêmement complexe. On ne résout rien en installant juste PostgreSQL.
  • Les articles qui disent avoir réduit les coûts avec des VPS reçoivent souvent le contre-argument : “AWS, c’est du web-scale et ça ne tombe jamais, tandis que le VPS n’offre qu’un uptime d’un seul jour par mois.”
  • Amazon propose aussi un VPS de type EC2 ; je me demande si EC2 a été impacté par cette panne.

• Les opinions d’experts portent en fait davantage sur le contexte géopolitique (par ex. la dépendance en temps réel des systèmes nationaux à des entreprises étrangères) que sur le technique. Pour une entreprise classique, s’appuyer sur un seul fournisseur réduit la complexité et n’est pas problématique en termes de fréquence d’incidents. On n’a pas besoin de multi-cloud. Utiliser un seul cloud peut même améliorer la fréquence des downtimes.

  • Les experts cités dans les médias n’apportent pas réellement de solution. Ils interviennent généralement lorsque le problème éclate.

• Je pense que l’ensemble du secteur est pris dans le cloud lock-in. La vraie question est de savoir comment on peut revenir en arrière. Je considère Docker comme l’une des causes du lock-in, au même titre que les grands acteurs cloud.

  • Du point de vue des ingénieurs opérationnels ou du support, la réalité est que vers 1h du matin, lorsqu’ils voient qu’une panne généralisée d’AWS a fait s’effondrer toute l’infrastructure, personne ne cherche à changer ça.
  • Je me demande pourquoi Docker pose problème.

• Je n’interviens plus dans le cloud opérationnel depuis longtemps, mais à l’époque, les fonctionnalités de base (“primitive”) étaient en train de se standardiser entre tous les providers. Je me demande si la redondance multi-cloud était trop coûteuse, si l’écart technique était trop grand, ou si la question n’était même pas utile sous l’angle business. diapositive pets vs cattle

  • Déployer et opérer sur plusieurs clouds est bien trop lourd en gestion et en charge cognitive pour une équipe. Il faut beaucoup de ressources humaines pour maintenir une expertise sur l’infrastructure de deux clouds ou plus. Ce n’est pas adapté aux petites équipes ni aux équipes rapides. La simplicité de l’usage d’un seul cloud se traduit directement en uptime. Les grands groupes y gagnent aussi, en obtenant des prix réduits via de gros volumes sur un seul cloud. Et personne n’est licencié pour avoir choisi AWS.
  • Le multi-cloud est peu utile précisément parce qu’on n’arrive pas à réagir même si un autre cloud a une panne dans sa propre région. Les fournisseurs restent encore à 100 % sur leurs standards propriétaires, et le control plane reste kubernetes. Au final, tout le monde s’est retrouvé sur kubernetes.
  • Tous les clouds proposent un compute bon marché, mais la sortie réseau (egress) est outrageusement chère. Mettre en place du multi-cloud fait exploser la facture de trafic. J’y vois là une stratégie intentionnelle.
  • Les clouds semblent en fait générer leurs revenus via les frais d’egress. C’est pourquoi le multi-cloud, et même la redondance entre régions ou AZ au sein d’un même cloud, est trop coûteux pour de nombreux clouds et applications. En cas de panne globale sur un cloud unique, la redondance régionale ne sert à rien. De plus, quand un cloud tombe, déplacer le trafic vers un autre cloud est difficile et le rapport coût/effort est trop défavorable. Pour la plupart des applications, il vaut mieux accepter ces quelques heures de downtime et consacrer argent et efforts ailleurs.
  • De nombreux clients gardent leurs fichiers/données dans le cloud, mais si les données sont sur un autre cloud, l’exploitation du service n’est pas facile et cela désavantage aussi l’acquisition réelle de clients. Puisque le fournisseur devient la norme de marché et que les clients concentrent leurs données sur ce même cloud, il est difficile de justifier des coûts de stockage sur deux clouds. J’ai voulu partir en indépendant vis-à-vis des plateformes, mais la complexité a en pratique diminué puisque tous les clients potentiels utilisent le même cloud.

• Cette année, on ne pouvait pas prévoir d’avance qu’AWS us-east-1 ne dépasserait pas la barre des deux chiffres de 9.

  • En tant que personne qui utilise AWS depuis près de 20 ans, je ne comprends pas pourquoi on choisirait us-east-1, qui est la région avec le plus de trafic et la plus importante. C’est aussi la plus ancienne et la moins stable.
  • Je me demande si des instances comme EC2 ont réellement été impactées.

• On pourrait penser que si tout le monde tombe en panne, c’est “exonéré”, mais l’expérience montre que ça ne passe pas pour un service destiné à des clients ordinaires.

• La cause de cette panne était dans un sous-système interne chargé des health checks des load balancers réseau. Page de statut du service AWS