Comme l’a dit Werner Vogels, directeur technique d’Amazon : « Tout tombe en panne tout le temps. » Cette phrase, bien que brutale, résume une vérité fondamentale du monde numérique : aucune infrastructure, qu’elle soit on-premise ou cloud, n’est à l’abri d’incidents.

Pour les PME québécoises et canadiennes, cet événement a ravivé des questions légitimes sur la fiabilité du cloud et les stratégies de résilience. Entre les appels au multi-cloud, les suggestions de retour au on-premise et les recommandations d’architectures multi-régions complexes, il est temps d’adopter une approche pragmatique. Car la réalité est que chaque solution a ses compromis, et que la « solution parfaite » n’existe pas – seulement des choix éclairés adaptés à votre contexte d’affaires.

L’effet domino sur l’écosystème AWS

La panne de DynamoDB a déclenché une réaction en chaîne affectant des services critiques :

• EC2 : Les nouveaux lancements d’instances ont échoué. Le système DWFM (Droplet Workflow Manager), responsable de la gestion des serveurs physiques hébergeant les instances EC2, dépend de DynamoDB pour maintenir les « leases » avec ces serveurs. Sans DynamoDB, ces leases ont expiré, rendant des milliers de serveurs indisponibles pour de nouveaux lancements. Lorsque DynamoDB est revenu en ligne à 2h25, DWFM a tenté de rétablir simultanément toutes ces leases, créant un état de « congestion » – le système était tellement surchargé qu’il ne pouvait plus progresser.
• Lambda : Les fonctions Lambda ont connu des erreurs d’invocation et des retards de traitement. Les sources d’événements SQS et Kinesis étaient particulièrement affectées, avec des gros backlogs de messages à traiter.
• Network Load Balancer (NLB) : Les NLB ont subi des erreurs de connexion accrues dues à des échecs de health checks. Le système de vérification de santé lançait de nouvelles instances EC2 dont la configuration réseau n’était pas encore propagée, créant des résultats alternant entre « sain » et « défaillant ».

Les chiffres qui relativisent

Selon AWS, us-east-1 représente environ 20% de leur capacité mondiale. L’incident a affecté une portion de cette région pendant 15 heures. Pour mettre en perspective : AWS maintient un SLA de 99,99% pour DynamoDB, ce qui autorise 52 minutes d’interruption par an. Cette panne unique a largement dépassé ce quota, mais reste exceptionnelle dans l’historique d’AWS.

Les clients utilisant DynamoDB Global Tables ont pu basculer sur leurs réplicas dans d’autres régions, démontrant l’efficacité des architectures multi-régions – pour ceux qui les avaient déployées.

Remarque importante sur la facturation

De plus, il est possible d’obtenir un crédit en cas de non-respect du SLA. Compte tenu de l’interruption de service ayant largement dépassé la durée maximale autorisée par les SLA des différents services. Exemple: Le SLA de DynamoDB est de 99,99%, les clients affectés sont éligibles à demander un dédommagement, sous la forme d’un crédit.

Les pannes on-premise sont invisibles, pas inexistantes

Quand AWS tombe, le monde entier en parle. Quand votre centre de données local subit une panne, seules vos équipes et vos clients le savent. Cette différence de visibilité crée un biais de perception.

Selon une étude du Uptime Institute, 31% des organisations ont connu au moins une panne majeure de leur infrastructure on-premise en 2023, avec une durée moyenne d’interruption de 7 heures. Les causes les plus fréquentes : défaillances matérielles (35%), erreurs humaines (27%).

Le coût caché de l’on-premise

Serveurs à remplacer tous les 3-5 ans, salle de serveurs à entretenir, infrastructures réseau à mettre à jour. Une PME hébergeant on-premise dépense typiquement 40 à 60% de plus qu’en cloud pour une disponibilité souvent inférieure (95-98% vs 99,9%+).

Quand le multi-région fait sens

• Applications critiques avec tolérance zéro : Systèmes de paiement, plateformes de télémédecine, applications financières où chaque minute d’interruption coûte des dizaines de milliers de dollars.
• Services à haute disponibilité contractuelle : Si vous avez un SLA de 99,99% avec vos clients (52 minutes d’interruption autorisées par an), une architecture mono-région est insuffisante.
• Volume d’affaires justifiant l’investissement : Applications générant plusieurs millions de dollars annuellement où la perte d’une heure représente un manque à gagner significatif.

Les coûts réels du multi-région

Une architecture multi-région nécessite :

• Réplication des données : DynamoDB Global Tables ou Aurora Global Database coûtent 2 à 3 fois plus cher qu’une base mono-région. La réplication cross-région génère des frais de transfert de données (0,02$ par Go).
• Services dupliqués : Lambda, API Gateway, load balancers, caches – tout doit être déployé dans chaque région. Attendez-vous à une augmentation de 80 à 120% de vos coûts d’infrastructure.
• Complexité de routage : Route 53 avec health checks et failover automatique, gestion des sessions utilisateurs cross-région, synchronisation des secrets et configurations.
• Tests et validation : Chaque déploiement doit être testé dans toutes les régions. Les tests de basculement (failover tests) doivent être réguliers, ajoutant 20 à 30% de temps aux cycles de release.

L’approche hybride : Multi-région sélectif

Une stratégie plus réaliste consiste à identifier vos composants vraiment critiques et à les déployer en multi-région, tout en gardant les autres en mono-région :

• Base de données transactionnelle : DynamoDB Global Tables ou Aurora Global Database pour vos données critiques.
• Services stateless : Lambda et conteneurs peuvent facilement être déployés dans plusieurs régions à coût modéré.
• Stockage critique : Réplication S3 cross-région pour vos documents importants.
• Services non-critiques : Logs, métriques, environnements de développement restent mono-région.

Cette approche peut réduire les surcoûts de 50 à 60% tout en protégeant l’essentiel.

Les vrais enseignements de la panne du 20 octobre

Architecture découplée : Le facteur clé

Marc Sanfaçon, VP chez Coveo, partageait dans un article récent que leur expérience de recherche – le cœur de leur plateforme – est restée pleinement opérationnelle pendant toute la panne. Comment ? Grâce à une architecture hautement découplée où le chemin critique des requêtes était isolé des dépendances à DynamoDB et aux nouveaux lancements EC2.

Cédric Thibault, dans son analyse de l’incident, souligne les écarts de temps de récupération entre différents SaaS : Reddit est revenu en ligne rapidement, tandis qu’Atlassian a pris plusieurs heures supplémentaires. La différence ? Des architectures élastiques capables de gérer l’afflux de messages au retour en ligne, et des plans de basculement bien préparés.

Préparation opérationnelle : Au-delà de l’architecture

La vraie résilience ne vient pas uniquement de l’architecture technique, mais aussi de la préparation :

Playbooks de réponse : Procédures documentées et testées pour chaque type d’incident. Qui appeler ? Quelles actions prendre ? Dans quel ordre ?

Observabilité approfondie : Dashboards temps réel, alertes intelligentes, corrélation des métriques. Impossible de résoudre ce que vous ne pouvez pas voir.

Tests de chaos engineering : Simulez régulièrement des pannes (un service down, une région inaccessible) pour valider que vos mécanismes de récupération fonctionnent.

Accepter les compromis éclairés

Pour une PME, la question n’est pas « comment atteindre 100% de disponibilité » – c’est impossible et ruineux. La vraie question est : « Quel niveau de disponibilité justifie quel investissement ? »

• Analysez votre tolérance réelle aux pannes : Combien coûte une heure d’interruption ? Pas en théorie, mais en revenus perdus, clients insatisfaits, pénalités contractuelles ?
• Évaluez vos SLA internes : Vos équipes peuvent-elles répondre à une panne à 3h du matin ? Avez-vous des procédures d’escalation claires ?
• Priorisez les quick wins : Avant d’investir dans le multi-région, avez-vous des backups automatisés ? Des health checks robustes ? Des mécanismes de retry intelligents ?
• Investissez progressivement : Commencez par des architectures mono-région bien conçues. Ajoutez de la résilience par composants critiques. Évoluez vers le multi-région seulement si le ROI est clair.

La vraie question n’est pas « Comment éviter toute panne ? » mais « Comment construire une résilience proportionnée à mes besoins et à mes moyens ? » Pour la majorité des PME québécoises, la réponse n’est ni le multi-cloud coûteux, ni le retour nostalgique à l’on-premise, ni les architectures multi-régions dignes des GAFAM.

La réponse est une combinaison pragmatique : services managés dans une région canadienne (Montréal ou Calgary pour la souveraineté), multi-AZ systématique, architecture découplée, monitoring robuste, et préparation opérationnelle. Investissez dans la résilience progressivement, guidés par des analyses coûts-bénéfices concrètes plutôt que par des peurs ou des dogmes.

Car au final, la meilleure architecture n’est pas celle qui ne tombe jamais – elle n’existe pas. C’est celle qui tombe rarement, se remet rapidement, et dont le coût de construction et de maintenance est justifié par la valeur qu’elle protège.

Chez Unicorne, nous accompagnons les entreprises québécoises dans la construction d’architectures cloud résilientes adaptées à leur réalité. Nous croyons aux solutions pragmatiques plutôt qu’aux chimères technologiques, et à l’honnêteté des analyses coûts-bénéfices plutôt qu’aux discours marketing. Parce que votre infrastructure doit servir votre business, pas l’inverse.