AWS Multi-AZ vs Multi-Region: quelle stratégie de reprise après sinistre choisir?

Vous n’avez pas forcément besoin de Multi-Region: voici comment déterminer le niveau de Disaster Recovery réellement nécessaire à votre infrastructure AWS.
La résilience des infrastructures cloud est devenue un enjeu stratégique pour la plupart des entreprises. Une panne, même de quelques minutes, peut avoir un impact direct sur le chiffre d’affaires, la relation client ou la conformité réglementaire. Face à ce constat, beaucoup d’équipes techniques se tournent vers AWS et se posent la même question : faut-il déployer son infrastructure sur plusieurs zones de disponibilité, ou aller plus loin et la répliquer dans plusieurs régions géographiques ?
Il est essentiel de rappeler qu’une architecture hautement disponible n’est pas automatiquement une architecture de Disaster Recovery complète. La haute disponibilité protège contre des pannes localisées et courantes; le Disaster Recovery couvre des scénarios plus larges, allant jusqu’à la perte totale d’une région AWS. Confondre les deux conduit souvent à une fausse impression de sécurité.
La question centrale de cet article est donc simple à formuler, mais plus complexe à trancher : le Multi-AZ suffit-il, ou faut-il investir dans une architecture Multi-Region ? Nous allons définir ces deux notions, les comparer point par point, introduire les critères de décision RTO et RPO, puis proposer un framework concret pour choisir la stratégie adaptée à votre contexte, sans céder au réflexe consistant à considérer le Multi-Region comme systématiquement supérieur.

Haute disponibilité (High Availability)

L’objectif de la haute disponibilité est de maintenir le service disponible malgré une panne, généralement de portée limitée. Elle repose sur la répartition des ressources sur plusieurs composants redondants et sur un failover automatique, sans intervention humaine. Un exemple typique : une instance applicative devient indisponible dans une AZ, le trafic bascule instantanément vers les instances des autres AZ, et les utilisateurs ne perçoivent aucune interruption notable.

Reprise après sinistre (Disaster Recovery)

Le Disaster Recovery vise un objectif différent : restaurer le service après un événement majeur, qu’il s’agisse de la perte d’une infrastructure, d’une région entière, d’une erreur humaine critique ou d’une corruption de données. Les critères de décision ne sont plus seulement la disponibilité technique, mais le RTO et le RPO, deux notions détaillées plus bas. Sauvegarde et réplication sont ici complémentaires : la réplication assure la continuité, la sauvegarde protège contre la propagation d’une erreur ou d’une corruption.

Pourquoi une architecture Multi-AZ n’élimine pas tous les risques

Le Multi-AZ, aussi robuste soit-il, ne protège pas contre tous les scénarios de sinistre. Il reste vulnérable à une panne régionale complète, à une erreur humaine (suppression accidentelle de ressources), à une corruption ou une suppression de données qui se propage instantanément sur toutes les AZ, à une mauvaise configuration déployée globalement, ou encore à des dépendances régionales (un service managé AWS lui-même affecté à l’échelle de la région).
C’est précisément pour couvrir ces angles morts que les entreprises évaluent une stratégie plus large d’AWS Disaster Recovery, au-delà de la seule haute disponibilité AWS apportée par le Multi-AZ. La résilience cloud complète combine donc plusieurs niveaux de protection, du Multi-AZ jusqu’à, si nécessaire, une reprise après sinistre AWS multi-régionale.

Qu’est-ce que le RTO?

Le Recovery Time Objective (RTO) est le temps maximal acceptable pour restaurer le service après un incident. Un RTO de 15 minutes impose une architecture capable de basculer quasi instantanément, tandis qu’un RTO de 4 heures laisse davantage de marge pour une restauration manuelle ou semi-automatisée.

Qu’est-ce que le RPO?

Le Recovery Point Objective (RPO) est la quantité maximale de données que l’entreprise accepte de perdre lors d’un sinistre, exprimée en durée. Un RPO de 5 minutes suppose une réplication quasi continue des données, alors qu’un RPO de 24 heures peut se satisfaire d’une sauvegarde quotidienne classique.

RTO et RPO: pourquoi ils déterminent votre architecture

Plus les objectifs de RTO et de RPO sont stricts, plus la stratégie technique nécessaire devient complexe et coûteuse. Le choix d’architecture est donc avant tout un arbitrage entre coût, performance, disponibilité et complexité opérationnelle. L’erreur la plus fréquente consiste à surdimensionner une architecture par rapport aux besoins métier réels, en visant un RTO proche de zéro pour une application qui pourrait, en pratique, tolérer plusieurs heures d’indisponibilité.

AWS recommande précisément de partir des objectifs de récupération avant de sélectionner la stratégie de Disaster Recovery.

Le tableau ci-dessous synthétise les principales différences entre les deux approches.

Quel est le meilleur choix en matière de disponibilité?

Les deux architectures peuvent atteindre un niveau de disponibilité très élevé. La différence ne se joue pas sur le pourcentage de disponibilité affiché, mais sur la nature des pannes couvertes : le Multi-Region ajoute une protection contre un événement que le Multi-AZ, par construction, ne peut pas absorber.

Quelle architecture coûte le moins cher?

Le Multi-AZ reste, dans la grande majorité des cas, l’option la plus maîtrisée en termes de coûts. Le Multi-Region ajoute une infrastructure dupliquée, des coûts de transfert de données inter-régions et une charge de maintenance supplémentaire, qui doivent être justifiés par un besoin métier réel.

Quelle architecture est la plus simple à exploiter?

Le Multi-AZ est généralement plus simple à exploiter au quotidien : le failover est natif à de nombreux services managés AWS, et les équipes n’ont qu’un seul environnement régional à surveiller et à faire évoluer.

Quelle architecture offre le meilleur niveau de résilience?

Sur le papier, le Multi-Region offre le niveau de résilience le plus élevé, puisqu’il couvre un périmètre de panne plus large. Mais cette résilience théorique n’a de valeur que si l’architecture est correctement conçue, testée régulièrement et alignée avec des RTO/RPO réellement nécessaires, sans quoi elle ajoute surtout de la complexité sans bénéfice proportionné.

AWS structure généralement les stratégies de Disaster Recovery selon quatre profils, du plus économique au plus réactif.

Backup & Restore

• Sauvegarde régulière des données
• Restauration manuelle après sinistre
• Coût réduit
• RTO généralement plus important (plusieurs heures)
• Adapté aux workloads non critiques

Pilot Light

• Données répliquées en continu vers la région secondaire
• Infrastructure minimale maintenue active dans cette région
• Activation des ressources complètes lors du failover
• Bon compromis entre coût et temps de récupération

Warm Standby

• Environnement secondaire déjà opérationnel, à capacité réduite
• Montée en charge (scaling) déclenchée lors du sinistre
• RTO nettement plus faible que Pilot Light

Multi-Site Active/Active

• Applications actives simultanément dans plusieurs régions
• Trafic distribué en permanence entre les régions
• RTO potentiellement proche de zéro
• Complexité et coûts les plus élevés des quatre stratégies

AWS classe ces quatre stratégies selon un compromis croissant entre coût/complexité et objectifs de récupération.

Les cas où Multi-AZ est généralement suffisant

• Applications web classiques
• SaaS avec des exigences de disponibilité élevées, mais non critiques
• Applications internes à l’entreprise
• Environnements avec un RTO raisonnable (heures plutôt que minutes)
• Contexte de budget limité

Les avantages de Multi-AZ

Haute disponibilité native, sans effort d’architecture supplémentaire majeur
Architecture relativement simple à concevoir et à maintenir
Failover plus facile, souvent automatisé nativement par les services managés
Coût sensiblement inférieur à une architecture Multi-Region
Exploitation simplifiée pour les équipes techniques

Les limites de Multi-AZ

• Protection limitée au périmètre d’une seule région
• Aucune protection complète contre une panne régionale
• Exposition aux dépendances régionales de certains services AWS

Les scénarios qui justifient Multi-Region

• Applications critiques pour l’activité de l’entreprise
• Services nécessitant une disponibilité quasi continue
• Risque avéré de panne régionale pour le contexte métier
• Exigences strictes de RTO/RPO
• Besoins internationaux (latence, présence multi-marché)
• Contraintes réglementaires ou sectorielles spécifiques

Multi-Region Active/Passive

Dans ce modèle, une région primaire traite l’ensemble du trafic pendant qu’une région de secours reste en attente, alimentée par une réplication continue des données. En cas de sinistre, le failover bascule le trafic vers la région secondaire. L’avantage est un coût plus maîtrisé que l’actif/actif ; l’inconvénient est un délai de bascule et un risque que l’environnement de secours, rarement sollicité, ne soit pas parfaitement testé.

Multi-Region Active/Active

Ici, plusieurs régions servent simultanément les utilisateurs, avec une distribution du trafic entre elles. Cela impose de gérer la réplication et la cohérence des données entre régions actives, ce qui augmente sensiblement la complexité. Cette architecture n’est réellement pertinente que lorsque les exigences de continuité, de latence internationale ou de criticité métier la justifient explicitement, elle ne doit pas être choisie par précaution excessive.

Amazon EC2 et Auto Scaling

Le déploiement d’instances EC2 réparties sur plusieurs AZ, combiné à l’Auto Scaling, permet une réplication et une élasticité automatique de l’infrastructure applicative.

Amazon RDS

Amazon RDS propose nativement le mode Multi-AZ pour la réplication synchrone, des Read Replicas pour la montée en charge en lecture, et la réplication cross-region pour préparer un scénario Multi-Region.

Amazon S3

Amazon S3 offre une durabilité élevée des données, le versioning pour se prémunir contre les suppressions accidentelles, et la Cross-Region Replication pour dupliquer automatiquement les objets vers une autre région.

Amazon Route 53

Route 53 assure le routage DNS, les health checks pour détecter l’indisponibilité d’un endpoint, et le failover automatique du trafic vers une ressource ou une région saine.

AWS Elastic Load Balancing

L’Elastic Load Balancing distribue le trafic entre les instances disponibles et contribue directement à la haute disponibilité au sein d’une région.

AWS Backup

AWS Backup centralise les sauvegardes, protège contre la perte ou la corruption des données, et permet des copies cross-region pour renforcer une stratégie de Disaster Recovery.

Infrastructure as Code

Des outils comme AWS CloudFormation ou Terraform garantissent la reproductibilité de l’infrastructure et permettent d’automatiser le déploiement, et donc le Disaster Recovery, de manière cohérente entre régions.

AWS recommande notamment

l’Infrastructure as Code pour déployer de manière cohérente les infrastructures dans plusieurs régions et souligne que les sauvegardes restent nécessaires même lorsqu’une réplication des données est utilisée.

Les principaux coûts d’une architecture Multi-AZ

• Ressources supplémentaires (instances, bases de données
• redondantes)
• Load balancing
• Stockage additionnel
• Réplication éventuelle entre AZ

Les coûts supplémentaires du Multi-Region

• Infrastructure dupliquée dans une seconde région
• Transfert de données inter-régions
• Réplication continue
• Monitoring étendu
• DNS et routage supplémentaires
• Maintenance de plusieurs environnements en parallèle

Comment optimiser les coûts d’un Disaster Recovery AWS ?

• Choisir le bon niveau de RTO/RPO plutôt que viser le maximum par défaut
• Privilégier Pilot Light plutôt que Warm Standby lorsque c’est suffisant
• Réserver Warm Standby aux applications qui le justifient réellement
• S’appuyer sur le scaling automatique plutôt que sur des ressources dimensionnées en permanence
• Automatiser via l’Infrastructure as Code pour limiter le coût opérationnel
• Automatiser les tests et le failover pour réduire le coût humain des exercices de reprise

Point important : le Multi-Region ne doit jamais être présenté comme automatiquement « meilleur ». Le bon choix est celui qui correspond au niveau de risque et aux objectifs métier réels de l’entreprise, pas celui qui coche le plus de cases techniques.

Voici un framework de décision en six étapes, applicable à la majorité des contextes.

Étape 1: identifier les scénarios de panne à couvrir

• Panne d’une instance
• Panne d’une AZ
• Panne régionale
• Erreur humaine
• Corruption des données

Étape 2: définir votre RTO et votre RPO

Ces deux valeurs doivent être fixées par les équipes métier et techniques ensemble, application par application, elles ne se déduisent pas uniquement d’un choix technique.

Étape 3: évaluer la criticité de l’application

• Non critique
• Importante
• Critique
• Mission-critical

Étape 4: définir le budget disponible

Le budget conditionne directement le niveau de redondance atteignable ; il doit être posé explicitement avant de choisir une stratégie, plutôt que découvert après coup.

Étape 5: mesurer la complexité opérationnelle acceptable

Une architecture plus résiliente exige davantage de compétences, de tests réguliers et de procédures documentées. Une équipe restreinte doit intégrer cette charge dans son choix.

Étape 6: choisir la stratégie adaptée

Mini arbre de décision :

• Panne d’une AZ à couvrir → Multi-AZ
• Panne régionale à couvrir → Multi-Region
• RTO de plusieurs heures → Backup & Restore
• RTO de quelques dizaines de minutes → Pilot Light
• RTO de quelques minutes → Warm Standby
• RTO proche de zéro → Multi-Site Active/Active

Les valeurs exactes de RTO/RPO dépendent toutefois du workload et de l’implémentation; AWS présente ces stratégies comme des profils de référence plutôt que comme des garanties universelles.

• Penser que Multi-AZ protège contre une panne régionale
• Choisir Multi-Region sans avoir défini son RTO/RPO au préalable
• Négliger la réplication et la sauvegarde des données
• Répliquer automatiquement des données déjà corrompues
• Ne jamais tester le failover en conditions réelles
• Oublier les dépendances externes (API tierces, DNS, services managés)
• Sous-estimer les coûts de transfert de données inter-régions
• Déployer manuellement l’environnement de secours plutôt que via l’Infrastructure as Code
• Utiliser une architecture Multi-Region inutilement complexe pour un besoin qui ne le justifie pas

AWS souligne notamment qu’une réplication seule ne protège pas nécessairement contre la corruption ou la destruction des données : des mécanismes de sauvegarde et de restauration à un point donné restent nécessaires.

Une stratégie de Disaster Recovery qui n’est jamais testée reste théorique. Les tests de failover sont indispensables pour vérifier que les procédures fonctionnent réellement, et pas seulement sur le papier.

• Tester la restauration effective des données depuis les sauvegardes
• Tester le basculement du trafic vers l’environnement de secours
• Mesurer le RTO réel observé pendant le test, et le comparer à l’objectif
• Mesurer le RPO réel, c’est-à-dire la perte de données effectivement constatée
• Simuler différents scénarios de panne (AZ, région, corruption, erreur humaine)
• Documenter et automatiser les procédures de récupération pour réduire la dépendance à une seule personne

AWS recommande de tester régulièrement la stratégie de Disaster Recovery afin de vérifier que les objectifs de récupération peuvent réellement être atteints.

Cas 1: Vous avez une application classique. Multi-AZ est souvent le meilleur compromis.
Cas 2: Votre application est critique. Envisagez le Multi-Region, en fonction de vos RTO/RPO réels.
Cas 3: Vous avez besoin d’un RTO très faible. Orientez-vous vers Warm Standby ou Multi-Site Active/Active.
Cas 4: Le budget est limité. Multi-AZ combiné à des sauvegardes cross-region peut constituer un excellent compromis.
Cas 5: Vous êtes soumis à des exigences très fortes de continuité. Envisagez une architecture Multi-Region Active/Active, en pleine conscience de sa complexité.