Amazon DOP-C02: Haute disponibilité, résilience et reprise après sinistre — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La haute disponibilité et la reprise après sinistre sur AWS se concentrent sur la réduction du temps d’arrêt (RTO) et de la perte de données (RPO) en cas de défaillance de composants, de Zones de disponibilité (AZ) ou de Régions. Les conceptions Multi-AZ absorbent les défaillances d’AZ sans perte de données et avec un impact minimal sur le service ; les conceptions Multi-Région répondent aux perturbations régionales et aux événements à grande échelle. Le choix entre les stratégies actif/actif, actif/passif (veille tiède / warm standby) et veilleuse (pilot light) est dicté par les objectifs RTO/RPO de l’entreprise, les exigences de cohérence et le coût. Atteindre ces objectifs nécessite une conception cohérente englobant le routage DNS, l’élasticité de la puissance de calcul, le load balancing, la réplication/le basculement des bases de données, le stockage d’objets durable avec réplication/versioning, la sauvegarde centralisée et la vérification continue de la résilience via l’injection de pannes.

Architectures pour le RTO/RPO et le routage intelligent

Multi-AZ et Multi-Région :

• Multi-AZ : Placez des instances redondantes dans au moins deux sous-réseaux situés dans des AZ différentes derrière un load balancer. Utilisez des bases de données gérées avec réplication synchrone (RDS Multi-AZ, cluster Aurora Multi-AZ). Le RPO est généralement de zéro pour le stockage synchrone ; les objectifs de RTO vont de moins d’une minute (Aurora) à quelques minutes (basculement RDS Single-Instance Multi-AZ).
• Multi-Région : Choisissez l’actif/actif pour le RTO le plus bas avec une isolation régionale et une faible latence, ou la veille tiède (warm standby)/veilleuse (pilot light) pour une reprise après sinistre optimisée en termes de coûts. La réplication des données doit respecter le RPO : réplicas de base de données asynchrones, Aurora Global Database (RPO typique <1 s), tables globales DynamoDB (multi-Région, multi-actif) et S3 Cross-Region Replication (CRR) avec l’option Replication Time Control (RTC) pour une réplication adossée à un SLA.

Politiques de routage et vérifications de l’état de Route 53 :

• Routage par basculement : Créez deux enregistrements pour le même nom : Primaire (Primary) et Secondaire (Secondary). Associez une vérification de l’état à l’enregistrement Primaire (ou utilisez « Evaluate Target Health » pour un alias vers un ALB/NLB). En cas de défaillance, le trafic bascule vers le Secondaire. Maintenez un TTL bas (par ex., 60 s) pour réduire la latence du cache DNS, et surveillez l’état de la vérification de l’état avec des alarmes CloudWatch.
• Routage basé sur la latence : Acheminez les utilisateurs vers la Région offrant la plus faible latence mesurée. Associez des vérifications de l’état à chaque enregistrement pour garantir que seuls les points de terminaison sains reçoivent du trafic. Associez cette politique à des piles multi-Région et à des magasins de données régionaux qui prennent en charge la cohérence éventuelle (eventual) ou forte (strong) selon les besoins.
• Routage pondéré : Répartissez le trafic par pourcentage pour prendre en charge les déploiements canary, les tests A/B ou une préparation à la reprise après sinistre « au goutte-à-goutte » (par exemple, 1 % vers le secondaire en continu). Combinez avec des vérifications de l’état pour que les poids des cibles non saines soient exclus. Utilisez des poids changeant progressivement pour migrer le trafic lors d’une évacuation régionale.
• Vérifications de l’état : Sondez des points de terminaison HTTP(S)/TCP ou des alarmes CloudWatch. Pour les alias d’ALB/NLB, activez « Evaluate Target Health » pour hériter de l’état du groupe cible. Concevez les points de terminaison de vérification de l’état pour qu’ils reflètent la disponibilité réelle (dépendances joignables, migrations appliquées). Pour les applications avec état (stateful), incluez des vérifications de dépendances (base de données, cache) pour éviter de router le trafic vers des instances partiellement saines.

Modèles résilients par objectif :

• RPO faible, RTO inférieur à la minute au niveau mondial : Actif/actif avec routage basé sur la latence et vérifications de l’état de Route 53, puissance de calcul sans état (stateless) locale à la région, tables globales DynamoDB ou Aurora Global Database, S3 CRR avec RTC pour les objets critiques.
• RPO modéré (≤15 min), RTO ≤4 heures : Veille tiède (Warm standby) avec un secondaire à échelle réduite, réplica de base de données asynchrone (réplica en lecture inter-régional RDS ou Aurora Global), routage par basculement Route 53, runbooks ou automatisation pour monter en charge et promouvoir lors du basculement.
• Reprise après sinistre optimisée en termes de coûts : Veilleuse (Pilot light) pour les services de données principaux uniquement, infrastructure-as-code pour étendre la couche applicative lors de l’invocation, RPO déterminé par la fréquence de réplication, RTO par le temps de provisionnement et le rattrapage des données.

Elastic Load Balancing et Auto Scaling

Elastic Load Balancing :

• Application Load Balancer (ALB) : Couche 7, routage par hôte/chemin, WebSocket/HTTP/2, WAF intégré, adhérence via les cookies du groupe cible et vérifications de l’état basées sur les requêtes. Utilisez l’équilibrage de charge interzone et le délai de désenregistrement (drainage des connexions) pour drainer progressivement les cibles lors d’un scale-in ou de déploiements. Configurez le démarrage lent et la détection des anomalies pour un préchauffage inégal du backend.
• Network Load Balancer (NLB) : Couche 4, latence ultra-faible, adresses IP statiques/IP élastiques, pass-through/terminaison TLS, préserve l’adresse IP source et prend en charge les connexions de longue durée. À utiliser pour les protocoles TCP/UDP, les charges de travail à haut débit ou lorsque la visibilité de l’IP client est obligatoire. Les vérifications de l’état sont TCP/HTTP/HTTPS en Couche 4/7 selon la configuration.
• Drainage des connexions (délai de désenregistrement) : Définissez un délai approprié (par exemple, 60–300 s) pour permettre aux requêtes en cours de se terminer. Assurez-vous que les événements de déploiement et de terminaison Auto Scaling respectent ce délai pour éviter toute interruption pour l’utilisateur.

Groupes Auto Scaling :

• Politiques de mise à l’échelle :
  • Mise à l’échelle par suivi de cible : Maintenir une métrique (CPUUtilization, ALB RequestCountPerTarget) à une valeur cible. C’est la politique la plus simple et la plus adaptative pour les flottes web/API.
  • Mise à l’échelle par paliers : Mettre à l’échelle par étapes définies lorsque les métriques franchissent des seuils. Utile pour un trafic en rafales avec des schémas prévisibles.
  • Mise à l’échelle planifiée : Pré-dimensionner pour des événements connus (soldes, lancements) afin d’éviter une capacité à froid.
  • Mise à l’échelle prédictive : Prévoir facultativement la demande en utilisant le ML pour les schémas quotidiens/hebdomadaires.
• Hooks de cycle de vie : Launching:Wait et Terminating:Wait vous permettent de contrôler la préparation et l’arrêt des instances. Utilisez les hooks pour :
  • Amorcer les instances (SSM Automation, achèvement des données utilisateur, hydratation de l’AMI) avant leur entrée en service.
  • Collecter les journaux et les artefacts avant la terminaison pour l’analyse des causes profondes.
  • Coordonner les déploiements blue/green ou sur place qui doivent confirmer les signaux de préparation (par ex., cfn-signal).
• Warm pools : Gardez des instances pré-initialisées à l’état Arrêté ou En cours d’exécution attachées à l’ASG pour réduire drastiquement la latence de scale-out. Les Warm pools se marient bien avec de longues étapes d’amorçage (installation de gros paquets, téléchargements de modèles). Configurez une capacité préchauffée minimale et des politiques de réutilisation. Combinez avec le hook de cycle de vie Launching:Wait pour ne terminer le hook que lorsque les vérifications de préparation de l’application réussissent, garantissant des temps de basculement cohérents.
• Paramètres de résilience : Activez Capacity Rebalance pour Spot, plusieurs types/allocations d’instances, des vérifications de l’état liées à la santé du groupe cible, et l’actualisation d’instance pour des mises à jour progressives sécurisées avec des garde-fous de santé.

Résilience, réplication et sauvegardes de la couche de données

Bases de données relationnelles :

• RDS Multi-AZ : Réplication synchrone vers une instance de secours dans une autre AZ ; le basculement automatisé met à jour le point de terminaison DNS vers l’instance de secours. Cela protège contre les pannes d’AZ et d’instance avec un RPO ≈ 0 et un RTO généralement de quelques minutes pour les instances de base de données Single-AZ avec une instance de secours Multi-AZ. Le nouveau cluster de bases de données Multi-AZ pour MySQL/PostgreSQL offre un basculement plus rapide avec plusieurs instances de secours en lecture.
• Réplicas en lecture : Réplication asynchrone pour la mise à l’échelle en lecture et la DR. Utilisez des réplicas en lecture inter-régions pour la DR ; la promotion est manuelle (ou automatisée avec des runbooks/fonctions Serverless) et entraîne un RPO > 0. Assurez-vous que le binlog ou la réplication logique est correctement configuré et que le retard de réplication est surveillé.
• Aurora : Aurora Multi-AZ (cluster) utilise un stockage partagé avec des réplicas dans plusieurs AZ ; le basculement est généralement inférieur à la minute. Aurora Global Database fournit une réplication physique basée sur le stockage vers des régions secondaires avec un RPO typique < 1 s et un RTO < 1 min. Utilisez le basculement planifié géré pour des migrations sans perte de données, ou le basculement non planifié pour les événements de sinistre. Les points de terminaison d’écriture/lecture abstraient la topologie ; les applications doivent implémenter une nouvelle tentative avec backoff exponentiel.

Stockage d’objets et DR :

• Gestion des versions S3 : Activez la gestion des versions pour vous protéger contre les écrasements/suppressions et pour prendre en charge la CRR. Configurez des politiques de cycle de vie pour faire passer les anciennes versions vers un stockage moins cher et définissez une rétention appropriée.
• Réplication inter-régions S3 (CRR) : Nécessite la gestion des versions sur la source et la destination. Utilisez un rôle IAM de réplication ; si les buckets sont inter-comptes, ajoutez une politique de bucket de destination autorisant le rôle source s3:ObjectOwnerOverrideToBucketOwner et les permissions d’écriture. Pour les objets chiffrés avec KMS, accordez au rôle kms:Decrypt sur la clé source et kms:Encrypt sur la clé de destination. Considérez :
  • Replication Time Control (RTC) pour 99,9 % des objets répliqués en moins de 15 minutes avec des métriques/alertes.
  • Réplication des marqueurs de suppression et des contrôles de propriété selon les besoins.
  • S3 Batch Replication pour les objets

Ingénierie du chaos et AWS Fault Injection Simulator (FIS)

Les expériences de chaos valident que les mécanismes de haute disponibilité (HA) et de reprise après sinistre (DR) se comportent comme prévu. AWS FIS orchestre des pannes contrôlées avec des garde-fous (guardrails) :

• Les modèles d’expérience (experiment templates) définissent des actions (par exemple, arrêter ou redémarrer un pourcentage d’instances EC2 dans un ASG, injecter une charge sur le CPU ou la mémoire via SSM, ajouter de la latence réseau/perte de paquets sur les instances, tuer des pods EKS, arrêter des tâches ECS, déclencher un basculement RDS/Aurora) et des cibles (tags de ressource, ARN).
• Contrôles de sécurité : Spécifiez des conditions d’arrêt sur alarme CloudWatch, des limites de temps, des contraintes de rayon d’impact (blast radius) via des tags/filtres, et des vérifications préalables (pre-checks). Exécutez d’abord en non-production, puis en production avec des garde-fous stricts et l’approbation du métier.
• Observabilité : Instrumentez les indicateurs de performance clés (KPI) (taux d’erreur, latence de queue (tail latency), âge de la file d’attente, retard de réplication (replica lag)) et vérifiez les réponses automatisées, y compris les réactions d’Auto Scaling, la convergence de l’état de santé du load balancer, le basculement Route 53, la promotion de la base de données et le comportement du disjoncteur (circuit breaker).
• Résilience continue : Intégrez les expériences dans les pipelines/gamedays pour empêcher la dérive de configuration (configuration drift) d’éroder la résilience. Utilisez Parameter Store ou AppConfig pour les feature toggles et pour coordonner des déploiements sécurisés.

Scénario de problème pratique

Expedia Group exploite une API mondiale de recherche de voyages qui doit fournir un RTO inférieur à 60 secondes et un RPO quasi nul pour les données de réservation critiques, tout en maintenant une faible latence pour les utilisateurs en Amérique du Nord et en Europe. L’équipe subit des pannes partielles régionales (brownouts) occasionnelles et une instabilité induite par les déploiements, et les auditeurs exigent des sauvegardes immuables inter-comptes et des exercices de reprise après sinistre documentés.

Approche étape par étape :

1. Établir des stacks multi-régions, actif/actif

• Déployez des stacks d’API sans état (stateless) dans us-east-1 et eu-west-1 sur plusieurs AZ derrière des ALB. Utilisez le routage basé sur la latence de Route 53 avec des vérifications de l’état de santé (health checks) et l’option Evaluate Target Health sur les enregistrements d’alias. Cela fournit un routage à faible latence et une évasion régionale automatique si un point de terminaison (endpoint) est défaillant.

2. Datastore mondial à faible RPO

• Migrez les données de réservation et de session vers Amazon Aurora Global Database (compatible MySQL) avec us-east-1 comme région primaire et eu-west-1 comme secondaire. Un RPO typique < 1 s et un RTO < 1 min répondent à l’objectif en cas de panne. Utilisez les points de terminaison de cluster et de lecture (cluster and reader endpoints) dans la configuration de l’application avec une logique de nouvelle tentative/interruption-reprise (retry/backoff) pour tolérer les basculements.

3. Mise à l’échelle résiliente et transitions en douceur

• Configurez le suivi de cible (target tracking) d’Auto Scaling sur ALB RequestCountPerTarget avec une capacité minimale dans les deux régions. Ajoutez des pools pré-chauffés (warm pools) dimensionnés pour absorber le pic de trafic 10x lors d’événements majeurs et des hooks de cycle de vie Launching:Wait pour retarder l’enregistrement jusqu’à ce que les vérifications de disponibilité de l’application réussissent. Activez un délai de désenregistrement (deregistration delay) de l’ALB de 120 secondes pour préserver les requêtes en cours (in-flight) lors des scale-in et des déploiements.

4. Reprise après sinistre pour les objets durables

• Activez le versioning S3 (S3 Versioning) et la CRR avec RTC pour les documents d’itinéraire de us-east-1 vers eu-west-1. Utilisez un rôle IAM de réplication dédié et des clés KMS dans les deux régions, en accordant kms:Decrypt sur la source et kms:Encrypt sur la destination. Les métriques et alertes RTC donnent confiance dans les SLA de réplication.

5. Contrôles DNS pour le canary et le basculement

• Ajoutez des enregistrements pondérés (weighted) Route 53 (flux constant de 1% vers eu-west-1) pour solliciter continuellement le chemin secondaire. Combiné avec les health checks, cela garantit que le standby est prêt pour la production et détecte la dérive avant une crise.

6. Sauvegardes centralisées et immuables

• Dans un compte de sauvegarde appartenant à la sécurité, créez des coffres-forts (vaults) AWS Backup avec Vault Lock et des CMK KMS. Définissez des politiques de sauvegarde au niveau de l’organisation pour planifier des sauvegardes quotidiennes et des copies inter-comptes pour RDS, DynamoDB, EFS et EBS. Assignez les ressources par le tag Backup_Frequency. Cela permet d’obtenir une résistance aux ransomwares et une séparation des tâches.

7. Orchestration de basculement automatisée

• Implémentez une règle EventBridge pour détecter les signaux de défaillance du primaire Aurora et invoquer une fonction Lambda qui promeut la région secondaire et met à jour un point de terminaison d’application stocké dans Parameter Store. Les applications chargent le point de terminaison au démarrage et le rafraîchissent en cas d’erreurs de connexion, minimisant les étapes manuelles.

8. Validation par le chaos avec AWS FIS

• Créez des modèles d’expérience FIS pour : terminer 10% des instances de l’ASG, injecter 150 ms de latence et 1% de perte de paquets sur EC2 via SSM, et déclencher un basculement Aurora. Protégez avec des conditions d’arrêt sur alarme CloudWatch sur la latence p95 et le taux d’erreur. Organisez des gamedays mensuels pour valider la vitesse de basculement de Route 53, la récupération de l’ASG, la convergence de l’état de santé de l’ALB et le RTO de la promotion Aurora.

Pourquoi ces services :

• Le routage basé sur la latence et le routage pondéré de Route 53 fournissent à la fois une latence utilisateur optimale et une mise en forme contrôlée du trafic pour la préparation à la reprise après sinistre.
• ALB plus ASG avec des warm pools et des hooks de cycle de vie assurent une mise à l’échelle rapide et en douceur, sans pénalités de démarrage à froid (cold-start) ni interruption pour l’utilisateur.
• Aurora Global Database est le seul à répondre à un RPO quasi nul et à un RTO inférieur à la minute entre les régions avec des changements d’application minimes.
• Le versioning S3 et la CRR avec RTC fournissent une réplication auditable et adossée à un SLA pour les artefacts critiques.
• AWS Backup avec des coffres-forts inter-comptes et Vault Lock crée des sauvegardes immuables et gouvernées de manière centralisée, alignées sur les besoins de conformité.
• AWS FIS fournit une injection de pannes sûre et automatisée pour prouver continuellement la posture de résilience et empêcher la dérive de configuration de saper le plan de reprise après sinistre.

← Conteneurs et opérations serverless · Tous les domaines · Architectures événementielles et automatisation →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →