Résilience cloud : HA, DR, chaos engineering et continuité d'activité

Votre application cloud tombe en panne, combien de temps pouvez-vous rester indisponible avant de perdre des clients ? Combien de données pouvez-vous accepter de perdre ? Ces deux questions, posées au métier avant la première ligne de code, déterminent l'architecture résiliente que vous devez construire. Ce guide explique HA et DR, comment définir RTO/RPO, comment architecturer en multi-AZ et multi-région, comment tenir la règle 3-2-1 des backups, comment implémenter les patterns cloud-native (circuit breaker, retry, bulkhead, graceful degradation), et comment valider tout ça en chaos engineering.

Ce que vous allez apprendre

• La différence entre HA (Haute Disponibilité) et DR (Disaster Recovery)
• Comment définir RTO (Recovery Time Objective) et RPO (Recovery Point Objective)
• Concevoir une architecture multi-AZ tolérante aux pannes
• Mettre en place une stratégie backup et restore efficace (règle 3-2-1)
• Les 4 patterns DR : Backup & Restore, Pilot Light, Warm Standby, Active-Active
• Les 4 patterns cloud-native de résilience applicative
• Le chaos engineering et ses outils 2026

Prérequis : connaître les régions et zones de disponibilité. Si besoin, voir Régions et zones cloud.

1. HA vs DR : deux concepts complémentaires

Haute Disponibilité (HA) : éviter l'interruption

Objectif : garantir que votre application reste accessible même si un composant tombe en panne (serveur, datacenter, réseau).

Principe : redondance + basculement automatique (failover).

Exemple concret. Vous avez un site e-commerce. Pour garantir la HA, vous déployez l'application dans 2 zones de disponibilité (AZ) différentes, vous placez un load balancer devant les serveurs, et si une AZ tombe, le load balancer redirige automatiquement vers l'autre.

SLA typique : 99,9 % à 99,99 % de disponibilité (8h45 à 52 minutes d'indisponibilité par an maximum).

Disaster Recovery (DR) : se remettre du pire

Objectif : récupérer après un événement catastrophique (incendie de datacenter, cyberattaque massive, corruption de données, erreur humaine massive).

Principe : sauvegardes + réplication + plan de reprise testé régulièrement.

Exemple concret. Un ransomware chiffre toute votre base de données de production. Sans DR, vos données sont perdues, vous payez la rançon sans garantie de récupération. Avec DR, vous restaurez la base depuis le backup de la veille, perte maximale 24 heures de données (RPO = 24 h).

Comparaison HA vs DR

Critère	Haute Disponibilité (HA)	Disaster Recovery (DR)
Objectif	Éviter l'interruption	Se remettre de l'interruption
Échelle de temps	Secondes à minutes	Minutes à heures
Événement	Panne technique (serveur, AZ)	Catastrophe (incendie, cyber, corruption)
Solution	Redondance + failover auto	Backups + réplication + runbook
Coût	Moyen (× 2 à × 3 ressources)	Variable (stockage backups + tests DR)
Test	Automatique (load balancer, health checks)	Manuel régulier (DR drill)

Glissez pour voir

HA ET DR, pas HA OU DR

Les deux sont complémentaires, pas alternatifs. HA protège contre les pannes courantes (serveur qui crash, mise à jour ratée, panne d'AZ). DR protège contre les événements catastrophiques rares (datacenter détruit, ransomware, erreur humaine massive). Une architecture mature a les deux.

2. RTO et RPO : vos contraintes métier

Avant de concevoir une architecture résiliente, définissez deux métriques clés avec le métier, pas seul dans votre coin technique.

RPO (Recovery Point Objective)

Question : combien de données pouvez-vous perdre maximum ?

Définition : ancienneté maximale acceptable de la dernière sauvegarde avant l'incident.

Cas d'usage	RPO acceptable	Stratégie de backup
Blog personnel	1 semaine	Backup hebdomadaire manuel
Site e-commerce	1 heure	Backup horaire automatisé
Transactions bancaires	0 minute (zéro perte)	Réplication synchrone continue

Glissez pour voir

Concrètement : RPO = 24 h signifie un backup quotidien à 3h du matin, si l'incident survient à 14 h, vous perdez 11 h de données. RPO = 1 h signifie un backup horaire, si l'incident survient à 14h32, vous perdez au maximum 32 min. RPO = 0 signifie une réplication synchrone, chaque transaction écrite simultanément dans 2 datacenters avant validation.

RTO (Recovery Time Objective)

Question : combien de temps d'indisponibilité pouvez-vous tolérer ?

Définition : délai maximal acceptable entre l'incident et le retour à la normale.

Cas d'usage	RTO acceptable	Architecture nécessaire
Site vitrine corporate	4 heures	Backup + restore manuel
SaaS B2B (clients professionnels)	15 minutes	HA multi-AZ + failover auto
Plateforme financière	0 minute (zéro downtime)	Active-active multi-région

Glissez pour voir

Matrice RTO/RPO

RTO	RPO	Coût	Architecture type
Élevé (4 h+)	Élevé (24 h+)	€	Backup quotidien + restore manuel
Moyen (1 h)	Moyen (1 h)	€€	HA multi-AZ + backup horaire
Faible (5 min)	Faible (5 min)	€€€	HA multi-AZ + réplication async
Zéro	Zéro	€€€€	Active-active multi-région + sync

Glissez pour voir

Le coût de la résilience

RTO/RPO faibles = architecture complexe et coûteuse. Ne visez zéro downtime que si le métier le justifie réellement. Un site vitrine peut tolérer 1 h d'indisponibilité par an. Une plateforme de trading ne peut pas tolérer 1 seconde. Règle d'or : définissez RTO/RPO avec le métier avant de concevoir l'architecture, pas après.

3. Architecture HA multi-AZ

La haute disponibilité repose sur la redondance géographique : déployer votre application dans plusieurs zones de disponibilité (AZ) indépendantes au sein d'une même région.

Rappel sur les AZ

Une zone de disponibilité est un datacenter (ou groupe de datacenters) isolé au sein d'une région cloud, avec alimentation électrique séparée, refroidissement indépendant, et réseau dédié à très faible latence (< 2 ms entre AZ d'une même région). Sur les principaux fournisseurs européens, on retrouve 3 AZ par région :

• AWS Paris (eu-west-3) : eu-west-3a, eu-west-3b, eu-west-3c.
• Outscale Paris (eu-west-2) : eu-west-2a, eu-west-2b, eu-west-2c.
• GCP Paris (europe-west9) : europe-west9-a, europe-west9-b, europe-west9-c.
• Azure France (francecentral) : 1, 2, 3.

Si une AZ perd l'électricité, les autres continuent de fonctionner. Le détail vit dans Régions et zones cloud.

Architecture HA type

Composants :

1. Load Balancer : répartit le trafic entre les 3 AZ, health checks automatiques.
2. App Servers : déployés dans chaque AZ (minimum 2 AZ, idéal 3).
3. Database : configuration multi-zone avec réplication synchrone vers un réplica de secours dans une autre zone de la même région (RDS Multi-AZ chez AWS, Cloud SQL HA chez GCP, configuration zone-redondante d'Azure SQL, Outscale RDS Multi-Subregion).

Ne pas confondre zone-redondance et géo-réplication

L'active geo-replication d'Azure SQL n'est pas un mécanisme de haute disponibilité intra-région, et elle est asynchrone. La documentation Microsoft l'écrit : elle s'appuie sur la technologie Always On availability group pour répliquer le journal de transactions de façon asynchrone, parce que la latence d'un réseau longue distance interdit le synchrone. Une bascule forcée peut donc perdre les transactions non encore répliquées.

Pour de la haute disponibilité au sein d'une région, c'est la configuration zone-redondante qu'il faut viser. La géo-réplication, elle, répond à un autre besoin : la reprise après un sinistre régional, traitée plus bas. Les deux sont utiles, elles ne remplacent pas la même chose.

Scénario de panne : AZ-A perd l'électricité, tous ses serveurs tombent. Le load balancer détecte que AZ-A ne répond plus (health check fail). Le trafic est automatiquement redirigé vers AZ-B et AZ-C. Les utilisateurs ne voient aucune interruption, juste une légère augmentation de latence pendant les ~30 secondes de bascule.

Checklist architecture HA

• Application déployée dans au moins 2 AZ (idéal : 3).
• Load balancer avec health checks actifs.
• Base de données en mode Multi-AZ ou réplication synchrone.
• Stockage répliqué (objet replication, snapshots multi-AZ).
• Sessions externalisées (Redis, Memcached, DynamoDB) pour rendre les serveurs stateless.
• Autoscaling configuré pour remplacer automatiquement les instances défaillantes.

Stateless = condition du failover

Pour que le failover fonctionne, vos serveurs applicatifs doivent être stateless : pas de données locales critiques. Les sessions utilisateurs doivent être stockées dans un cache partagé (Redis, Memcached) ou une base. Si un serveur crash, un autre prend le relais instantanément parce qu'il n'y a pas d'état local à reconstruire. Sans stateless, le failover « marche » mais l'utilisateur perd sa session, son panier, son contexte, et il considère ça comme une panne complète.

4. HA, réplication, snapshot, sauvegarde, PITR, archive, DR : le vocabulaire

Ces sept mots désignent sept mécanismes différents, et les confondre est la première cause d'illusion de protection. Une équipe qui croit sauvegarder alors qu'elle réplique découvre le malentendu le jour où une commande malheureuse se propage instantanément sur les deux copies. Le tableau ci-dessous est le vocabulaire de référence de ce cursus : les autres pages s'y tiennent.

Terme	Ce qu'il fait	Contre quel risque il protège	Ce qu'il ne fait pas
Haute disponibilité (HA)	Continuer à rendre le service malgré la panne d'un composant	Panne matérielle, perte d'une zone	Ne protège d'aucune erreur logique
Réplication	Maintenir une autre copie vivante et à jour	Perte d'une machine, d'une zone ou d'une région	Propage les suppressions et les corruptions
Snapshot	Figer un état ponctuel d'un volume ou d'une base	Erreur récente, retour arrière rapide	Vit souvent au même endroit que la source
Sauvegarde	Produire une copie récupérable, avec une politique de conservation	Erreur humaine, corruption, rançongiciel	Ne rend pas le service, il faut restaurer
Restauration à un instant donné (PITR)	Revenir à une seconde précise grâce au journal des transactions	Erreur logique datée, « juste avant le DELETE »	Limitée à la fenêtre de rétention du journal
Archive	Conserver longtemps à faible coût	Obligation légale de conservation	Délai et coût de restitution élevés
Reprise après sinistre (DR)	Reconstruire le service complet ailleurs	Perte d'une région entière	N'est pas un mécanisme, c'est un plan

Glissez pour voir

La règle qui découle de ce tableau

Une réplication n'est jamais une sauvegarde. Elle est conçue pour que la copie ressemble à la source le plus vite possible, ce qui est exactement le contraire de ce qu'on attend d'une sauvegarde : conserver un état que la source n'a plus. Un DELETE malheureux, un chiffrement par rançongiciel ou une migration ratée se retrouvent sur le réplica en quelques secondes. C'est le même point que celui posé dans données et bases managées.

5. Stratégie de sauvegarde et de restauration

Même avec HA, les backups restent essentiels pour protéger contre les corruptions de données, les ransomwares, les erreurs humaines (DELETE FROM users WHERE 1=1;), et les bugs applicatifs qui détruisent les données. La HA réplique aussi les corruptions, un backup, lui, contient un état antérieur sain.

La règle 3-2-1 des sauvegardes

3 copies de vos données : 1 copie principale (production), 2 sauvegardes.

2 supports différents : 1 local (snapshot disque, backup région primaire), 1 distant (backup région secondaire ou autre cloud).

1 copie offline ou immuable : protection contre ransomware (backup verrouillé, non supprimable pendant X jours via Object Lock S3 ou équivalent).

Les mécanismes de sauvegarde, et celui qui n'en est pas un

Le tableau ci-dessous reprend le vocabulaire de la section précédente. La dernière ligne est volontairement séparée : la réplication figure dans beaucoup de tableaux de sauvegarde alors qu'elle n'en est pas une.

Mécanisme	Fréquence typique	RPO atteignable	Ce qu'il traite
Snapshot de volume	Horaire	l'intervalle entre deux snapshots	Retour arrière rapide, même région
Sauvegarde automatisée d'une base managée	Quotidienne, plus journal continu	quelques minutes avec la restauration à un instant donné	Base de données de production
Sauvegarde immuable	Hebdomadaire	l'intervalle entre deux sauvegardes	Rançongiciel, via un verrou de rétention
Archive à froid	Mensuelle	l'intervalle entre deux archives	Conservation légale sur plusieurs années
Réplication vers une autre région	continue	proche de zéro	Ce n'est pas une sauvegarde : elle répond à la perte d'une région, pas à une erreur de contenu

Glissez pour voir

Le RPO d'une base managée n'est pas de 24 heures

Beaucoup de supports résument la sauvegarde automatisée d'une base managée à « une par jour, donc RPO de 24 heures ». C'est faux dès que le service conserve le journal des transactions, ce que font les bases managées des grands fournisseurs : la sauvegarde quotidienne sert de point de départ, et le journal permet de rejouer jusqu'à une seconde précise à l'intérieur de la fenêtre de rétention. Le RPO réel se compte alors en minutes, et la vraie question n'est pas la fréquence des sauvegardes mais la profondeur de rétention du journal, qui est un réglage, souvent facturé.

Exemple de stratégie backup complète

1. Snapshot automatique toutes les heures (rétention 24 h) → RPO 1 h.

2. Backup quotidien à 3h du matin (rétention 30 jours) → récupération erreur humaine.

3. Backup hebdomadaire immuable (rétention 1 an) → protection ransomware via Object Lock.

4. Réplication vers une seconde région, continue, qui traite la perte de région et ne remplace aucune des trois lignes précédentes.

Ces quatre mécanismes se cumulent parce qu'ils couvrent des risques distincts. Leur coût dépend du volume, du taux de changement et de la région : chiffrez-le sur le calculateur de votre fournisseur plutôt que de retenir un montant type, en gardant en tête que la ligne la plus chère est presque toujours la réplication, qui maintient une seconde infrastructure vivante.

Un backup non testé n'est pas un backup

Planifiez des DR drills réguliers. Tous les 3 mois : restore de base de données en environnement de test, mesurer le temps réel pour vérifier que vous tenez votre RTO. Tous les 6 mois : DR drill complet (simule destruction du datacenter primaire, bascule complète vers la région secondaire, validation fonctionnelle bout en bout). Sans ces tests, vous découvrez vos limites le jour de l'incident, c'est trop tard.

6. Disaster Recovery : 4 patterns au choix

Selon votre RTO/RPO, choisissez un pattern DR adapté. Plus la promesse est forte, plus le coût mensuel suivra.

Pattern 1, Backup & Restore (RTO 4 h+, RPO 24 h)

Principe : backups réguliers stockés dans une région distincte, restore manuel en cas de disaster.

Coût : € (stockage backups uniquement, pas d'infrastructure secondaire active).

Scénario : disaster détecté, équipe alertée, provision manuel d'infrastructure région secondaire (Terraform), restore du backup le plus récent, redirection DNS vers nouvelle région, tests et mise en prod. Pour qui : applications non critiques, intranets, environnements dev/test.

Pattern 2, Pilot Light (RTO 1 h, RPO 15 min)

Principe : infrastructure minimale toujours active en région secondaire (base de données répliquée), reste à provisionner en cas de disaster.

Coût : €€ (base de données secondaire + stockage répliqué).

Scénario : disaster détecté, scale-up infra secondaire (autoscaling rapide), basculement DNS, perte de données limitée au delta de réplication. Pour qui : SaaS B2B, e-commerce moyenne taille.

Pattern 3, Warm Standby (RTO 15 min, RPO 5 min)

Principe : environnement secondaire actif mais sous-dimensionné, peut scaler rapidement.

Coût : €€€ (infrastructure secondaire + réplication continue).

Scénario : disaster détecté, autoscaling immédiat de la région secondaire, basculement load balancer global, perte minimale de données. Pour qui : plateformes SaaS critiques, fintech.

Pattern 4, Active-Active (RTO 0, RPO 0)

Principe : deux régions actives en parallèle, trafic réparti 50/50, réplication synchrone.

Coût : €€€€ (double infrastructure + réplication synchrone + orchestration complexe).

Scénario : disaster région A, détection automatique (health check), trafic immédiatement redirigé vers région B, zéro perte de données grâce à la réplication synchrone, utilisateurs ne voient rien. Pour qui : banques, bourses, services critiques gouvernementaux.

7. Patterns cloud-native pour la résilience applicative

Au-delà de l'infrastructure, votre code doit être conçu pour résister aux pannes des dépendances (services externes, bases de données surchargées, réseau instable). Quatre patterns sont devenus standards en 2026.

Circuit Breaker

Problème : un service dépendant tombe, votre application continue d'envoyer des requêtes qui échouent, cascade de timeouts qui sature votre pool de connexions et fait tomber tout le système.

Solution : détecter le service défaillant et ouvrir le circuit, retourner une erreur immédiate sans tenter l'appel, jusqu'à ce que le service redevienne disponible.

from circuitbreaker import circuit

@circuit(failure_threshold=5, recovery_timeout=60)
def call_external_service():
    return requests.get("https://api.external.com/data")

Si 5 échecs consécutifs, le circuit s'ouvre pendant 60 secondes (pas d'appel possible), puis réessai automatique avec un appel test.

Retry with Exponential Backoff

Problème : erreur temporaire (réseau instable, service en redémarrage), mais vous abandonnez immédiatement.

Solution : réessayer automatiquement avec délai croissant (1 s, 2 s, 4 s, 8 s, 16 s).

import time

def retry_with_backoff(func, max_retries=5):
    for i in range(max_retries):
        try:
            return func()
        except Exception:
            if i == max_retries - 1:
                raise
            time.sleep(2 ** i)  # 1s, 2s, 4s, 8s, 16s

L'exponential backoff évite de saturer un service qui se relève, chaque retry laisse plus de temps de récupération.

Bulkhead

Problème : un service lent monopolise toutes vos ressources, les autres services sont impactés par effet de bord (pool de threads saturé, connexions DB consommées).

Solution : isoler les ressources, pool de connexions séparé par service, comme les cloisons étanches d'un navire.

critical_pool = ThreadPoolExecutor(max_workers=10)
non_critical_pool = ThreadPoolExecutor(max_workers=5)

Si le service non critique sature, le service critique continue de fonctionner sur son propre pool.

Graceful Degradation

Problème : le service de recommandations produit tombe, et tout le site e-commerce tombe parce que le moteur de rendu attend la réponse du recommander.

Solution : afficher le site sans la fonctionnalité non critique plutôt que planter.

try:
    recommendations = get_recommendations(user_id)
except Exception:
    recommendations = []  # Dégradation gracieuse, pas d'erreur visible

Le site fonctionne, juste sans cette fonctionnalité, l'utilisateur achète, votre métier continue.

8. Chaos engineering, valider la résilience en cassant volontairement

Les patterns ci-dessus sont inutiles s'ils ne sont jamais testés. Le chaos engineering est la discipline qui consiste à provoquer volontairement des pannes en production (ou en pré-production proche) pour valider que votre architecture résiliente fonctionne réellement.

L'origine, Netflix Chaos Monkey

Le chaos engineering est né chez Netflix vers 2010 quand l'entreprise a migré vers AWS. La direction a constaté qu'aucun ingénieur ne validait jamais que les patterns de résilience écrits sur le papier marchaient en pratique. La réponse a été radicale : un outil, Chaos Monkey, qui détruit aléatoirement des instances EC2 en production pendant les heures ouvrées.

L'idée derrière la radicalité : si vos systèmes ne survivent pas à des destructions aléatoires limitées, ils ne survivront pas à un vrai disaster non plus, autant le découvrir maintenant, équipe disponible, plutôt qu'à 2 h du matin un dimanche. Cette approche s'est progressivement imposée dans l'industrie sous le nom de resilience engineering ou chaos engineering.

Les outils 2026

Outil	Type	Spécificité
AWS Fault Injection Simulator (FIS)	Service managé AWS	Injection de pannes EC2, RDS, ECS, EKS, programmable
Azure Chaos Studio	Service managé Azure	Pannes VM, AKS, Cosmos DB, NSG, en preview puis GA
Gremlin	SaaS multi-cloud	Outil pionnier commercial, riche catalogue d'attaques
Chaos Mesh	Open source CNCF	Spécialisé Kubernetes, très utilisé en production
LitmusChaos	Open source CNCF	Concurrent de Chaos Mesh, hub d'expériences
Toxiproxy	Open source Shopify	Proxy qui injecte de la latence et des coupures réseau

Glissez pour voir

Game Days, la mise en pratique organisationnelle

Au-delà des outils, le chaos engineering passe par des Game Days réguliers : sessions planifiées (1 par trimestre minimum) où l'équipe simule un scénario de panne et observe la réponse réelle. Format typique :

• Préparation : scénario écrit, hypothèses sur la résilience (« on s'attend à ce que la bascule prenne moins de 2 minutes »).
• Exécution : l'attaque est lancée à un moment connu, en heures ouvrées, équipe au complet.
• Observation : monitoring en direct, mesures (RTO réel, RPO réel), comportement utilisateur.
• Post-mortem : ce qui a marché, ce qui a échoué, actions correctives.

Ce que le chaos engineering permet de découvrir

Dans les retours de Game Days documentés publiquement, voici les découvertes récurrentes : timeouts de retry mal réglés (cascade de timeouts plus longue que la panne elle-même), runbook de bascule qui demande un mot de passe que l'astreinte n'a pas, alarme PagerDuty qui ne fonctionne pas parce que la billing AWS a expiré il y a 3 mois, base de données secondaire qui n'est en réalité pas synchronisée depuis 6 jours parce qu'un cron a échoué silencieusement.

Aucune de ces découvertes ne se fait sans chaos engineering. Elles attendent toutes le vrai disaster pour se révéler, et là c'est trop tard.

Comment commencer en chaos engineering

Démarrer petit. La première expérience n'est pas Chaos Monkey en production. Commencez par une expérience contrôlée en environnement de pré-production : couper le réseau d'une AZ pendant 10 minutes, observer le comportement, mesurer le RTO réel. Si ça marche, augmentez progressivement le périmètre, d'abord pré-production, puis production en heures creuses, puis production en heures ouvrées. La maturité chaos engineering se construit sur 2 à 3 ans, pas en un trimestre.

9. Comment construire et vérifier sa résilience

Une architecture résiliente sur le papier ne le devient réellement qu'après avoir été éprouvée par des tests concrets. Trois axes structurent une démarche de résilience qui tient en production.

Tester avant de déclarer résilient. La majorité des architectures décrites comme résilientes n'ont jamais subi de bascule réelle : le runbook DR n'a jamais été exécuté de bout en bout, le backup n'a jamais été restauré en grandeur nature, l'alarme n'a jamais déclenché un appel d'astreinte. Le chaos engineering, même sur un périmètre réduit, est la seule façon de prouver la résilience. Démarrer par des expériences contrôlées (couper une AZ en pré-production, mesurer le RTO réel) permet de monter progressivement en maturité, en cycle d'amélioration continue.

Calibrer le niveau de résilience sur le besoin métier. Investir dans une architecture multi-région active-active a un coût significatif (réplication, doublement de l'infrastructure, complexité opérationnelle), parfois de l'ordre de 30 à 50 % de la facture cloud. Ce coût n'est justifié que si le métier exige réellement un RTO de quelques minutes. Pour beaucoup d'applications, un RTO d'une heure bien tenu vaut mieux qu'un RTO de cinq minutes annoncé mais mal architecturé. La discipline consiste à fixer le RTO/RPO avec le métier avant la conception, et à éviter d'ajouter de la résilience par peur plutôt que par besoin.

Choisir entre DR multi-région et DR cross-cloud. Le DR multi-région chez le même fournisseur est généralement plus simple à tester et à exploiter : mêmes services, mêmes outils, mêmes mécanismes IAM, mêmes équipes formées. Le DR cross-cloud (production sur un fournisseur, secours sur un autre) apporte une protection supplémentaire contre la défaillance d'un fournisseur entier, mais demande aux équipes de maîtriser deux environnements en parallèle, y compris au moment du sinistre, où la pression est forte. Ce choix doit être motivé par une analyse de risque explicite, pas par une intuition de sécurité supplémentaire.

Bonnes pratiques de vérification continue : Game Days trimestriels qui simulent une panne réelle, restauration de backup testée au moins annuellement, runbook DR mis à jour à chaque évolution architecturale, post-mortem systématique sur tout incident de production.

À retenir

• HA et DR sont complémentaires : HA pour les pannes courantes, DR pour les catastrophes rares.
• RTO et RPO doivent être définis avec le métier avant la conception, pas après.
• L'architecture multi-AZ est la base de la HA, load balancer, app stateless, base répliquée.
• La règle 3-2-1 (3 copies, 2 supports, 1 immuable) reste la référence backup.
• Quatre patterns DR : Backup & Restore (€), Pilot Light (€€), Warm Standby (€€€), Active-Active (€€€€).
• Quatre patterns cloud-native : Circuit Breaker, Retry with Backoff, Bulkhead, Graceful Degradation.
• Le chaos engineering est la seule façon de prouver la résilience, Chaos Monkey, AWS FIS, Azure Chaos Studio, Chaos Mesh.
• Game Days trimestriels : sessions planifiées qui révèlent les failles que les tests automatiques ne voient pas.
• Tester ses backups régulièrement, un backup non testé n'est pas un backup.

Prochaines étapes

Régions et zones de disponibilité Le socle géographique de toute architecture HA et DR multi-région.

Modèles de déploiement Public, privé, hybride, multi, sovereign : où vivent vos backups et vos régions DR.

Limites et compromis du cloud Les contraintes réelles à anticiper, dont le coût de l'egress sur réplication cross-région.

Egress et data transfer Le piège financier classique de la réplication continue cross-région pour le DR.

×

📖 Voir la documentation →