L’interruption mondiale de Amazon Web Services (AWS) survenue le lundi 20 octobre nous a à nouveau rappelé la fragilité du tissu numérique lorsque trop d’éléments dépendent d’un même point. En Espagne, des services aussi variés que Bizum, Ticketmaster, Canva, Alexa ou plusieurs jeux en ligne ont rencontré des erreurs ou sont demeurés inaccessibles pendant des heures. Le centre névralgique se trouvait en US-EAST-1 (N. Virginie) : un problème de DNS pointant vers DynamoDB a dégénéré en pannes de EC2, Lambda et équilibreur de charge, entraînant une réaction en chaîne affectant des dizaines de services.

Au-delà de cet incident ponctuel, la situation confère un message dérangeant : nous concentrons toujours les risques dans la même région du même hyper-escaleur, et l’Europe ne dispose pas encore de solutions planifiées lorsque le géant trébuche. « De nombreuses entreprises en Espagne et en Europe confient toute leur infrastructure à des fournisseurs américains et, de plus, ne prévoient pas de plan B même lorsque leurs services sont critiques », résume David Carrero, cofondateur de Stackscale (Groupe Aire). « Il est très pertinent d’assurer une haute disponibilité (HA), mais si tout repose sur un élément commun, l’HA échouera ».

Ce qui s’est produit (et pourquoi cela a été perceptible ici)

• Déclencheur : erreurs de résolution DNS pour DynamoDB en US-EAST-1.
• Effet en cascade : erreurs lors du lancement des instances EC2, problèmes avec le Network Load Balancer et les invocations Lambda, ainsi que files d’attente et limitation de débit dans les services dépendants.
• Impact en Europe : bien que de nombreux chargements soient localisés en régions européennes, les plans de contrôle globaux et les dépendances internes (identité, files d’attente, orchestration) reposent sur N. Virginie, d’où les échecs de connexion, les erreurs 5xx et la latence accrue en Espagne.

« Nous constatons cela à maintes reprises car l’architecture n’est pas réellement multi-régionale », ajoute Carrero. « Les plans de contrôle dans une seule région, des données centralisées par commodité et failovers non testés. Lorsqu’un gros choc survient, nous tout arrêtons. »

Leçons techniques tirées de l’incident

1. US-EAST-1 ne peut pas être une ‘rien en un’ : c’est pratique et peu coûteux, mais il concentre un risque systémique.
2. Multi-AZ n’équivaut pas à résilience : si un composant transversal (DNS d’un service clé) échoue, toutes les zones en pâtissent.
3. Teste ton plan B : un runbook sans gamedays réguliers est une fiction.
4. L’observabilité et DNS sont essentielles : si ta surveillance et ta gestion d’identités dépendent aussi de la région touchée, tu te retrouves aveugle quand tu en as le plus besoin.
5. Communication : une communication claire et régulière réduit l’incertitude et le coût du support.

Que faut-il changer dans les architectures cloud-first ?

1) Vraie multi-régionale
Séparer plans de contrôle et données et pratiquer les commutations. « Tout ne doit pas être actif-actif, mais c’est indispensable pour les services critiques », indique Carrero. « Défini ce qui ne doit pas tomber et conçois pour ces RTO/RPO ».

2) DNS/CDN avec basculement
Adapter des politiques de failover en DNS/GTM qui s’appuient sur la santé du service, et utiliser des origines alternatives en CDN. Éviter des ancrages implicites à une seule région.

3) Sauvegardes et restauration planifiées
Créer des copies immutables / déconnectées et réaliser des tests de restauration en temps réel. La sauvegarde n’est réelle que si elle permet de restaurer.

4) Dépendances globales maîtrisées
Identifier les services « globaux » qui reposent sur US-EAST-1 (IAM, files d’attente, catalogues, tables globales) et préparer des rues alternatives ou des moyens d’atténuer.

5) Multi-cloud… quand cela a du sens
Pour garantir la continuité, la souveraineté ou gérer des risques réglementaires, utiliser au minimum deux fournisseurs : identité/enregistrement, sauvegardes, DNS, ou un sous-ensemble critique. « Il ne s’agit pas de fuir les hyper-escaleurs, mais de réduire la concentration du risque et augmenter la résilience », nuance Carrero.

L’Europe a ses alternatives : complémentez-les

Autre facette de la discussion : l’aspect industriel. « En Europe, il existe de nombreuses options gagnantes souvent sous-estimées à cause de la pression pour rester avec les ‘gros’ » , indique Carrero. « Stackscale peut être une alternative ou un complément : l’écosystème européen et espagnol — cloud privé, bare-metal, housing, connectivité, backup et services gérés — est large et professionnel, sans rien envier aux hyper-escaleurs pour la majorité des besoins. »
Concrètement :

• Stocker les données et applications critiques dans une infra européenne (privée/souveraine) et faire le lien avec SaaS et hyper-escaleurs lorsque cela crée de la valeur.
• S’assurer que les couches de continuité (backups, DNS, observabilité) ne partagent pas un domaine de panne avec le fournisseur principal.
• S’appuyer sur partenaires locaux pour des SLA réels et un soutien de proximité.

Que faire dès aujourd’hui (et pour lundi prochain)

Utilisateurs

• Consulte la page d’état du service affecté avant de procéder à une nouvelle tentative d’installation.
• Réessaie plus tard : la récupération est progressive.

Équipes IT (maintenant)

• Évite les changements précipités ; ne bascule que si une route testée est disponible.
• Communique l’état et les prochaines étapes ; collecte des métriques pour le post-mortem.

Équipes IT (dans les semaines à venir)

• Cartographie RTO/RPO par service et ajuste l’architecture et le budget en conséquence.
• Teste les basculements (gamedays) et documente les résultats.
• Externalise l’observabilité et l’identité d’urgence en dehors du domaine de panne principal.
• Déconnecte les dépendances globales ; revisite ce qui se brise si US-EAST-1 cesse de répondre.

L’essentiel : dépendance et autonomie

La panne a été résolue en quelques heures, mais le schéma se répète (2020, 2021, 2023, 2025). La morale n’est pas de « fuir le cloud », mais concevoir pour échouer et diversifier. « La résilience n’est pas un slogan », conclut Carrero. « C’est une science de l’ingénierie et de la discipline. Si votre entreprise dépend de sa plateforme, elle doit continuer à fonctionner même si le fournisseur principal échoue. HA ne constitue pas un plan B; le vrai plan B, c’est une autre voie complète pour atteindre le même résultat. »

En résumé : en Espagne et en Europe, nous manquons encore de plan B quand un hyper-escaleur éternue. Il faut répartir la charge, tester la continuité et activer l’écosystème européen comme complément. La prochaine panne n’est pas une éventualité lointaine, mais une question de quand. La différence entre un coup de stress et une crise sera, encore une fois, la préparation.