Amazon SOA-C02: Haute disponibilité, tolérance aux pannes et reprise après sinistre — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-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.

Ce domaine couvre la conception de systèmes qui restent disponibles et récupérables en cas de défaillance de composants, de services ou de régions entières. Il englobe les stratégies de sauvegarde et d’instantanés, les modèles de réplication et de basculement, ainsi que les tests opérationnels nécessaires pour atteindre les objectifs métier RTO (Objectif de temps de reprise) et RPO (Objectif de point de reprise). L’importance opérationnelle est élevée : les pannes et les pertes de données ont un impact direct sur les SLA, les revenus et la conformité. Les conceptions efficaces équilibrent le coût, la complexité et le risque acceptable de perte de données et d’indisponibilité.

Stratégies de sauvegarde, instantanés et rétention

Les sauvegardes doivent être automatisées, cohérentes avec l’état de l’application et conservées conformément à la politique définie. Utilisez AWS Backup pour centraliser les plans, la rétention et les règles de cycle de vie (créer un plan de sauvegarde avec un coffre-fort, assigner des ARN d’ID de ressource ou des balises). Pour les volumes EBS, utilisez Data Lifecycle Manager (DLM) pour planifier les instantanés (console ou

undefined

) ; exemple de création d’instantané en CLI :

undefined

. Pour RDS, utilisez les instantanés automatisés ou les instantanés de base de données manuels (

undefined

). Activez les sauvegardes automatisées RDS pour la restauration à un instant T (point-in-time recovery) ; activez la surveillance améliorée et la rétention des instantanés pour respecter les SLA de rétention.

La rétention, l’immuabilité et les copies inter-régions sont des décisions critiques :

Des RPO/RTO courts nécessitent des instantanés fréquents et des fenêtres de suppression pour la rétention courtes ; cela augmente les coûts.
Pour l’immuabilité réglementaire, utilisez AWS Backup Vault Lock ou S3 Object Lock pour la conservation à des fins juridiques (legal hold).
Pour la durabilité inter-régions, copiez les instantanés (

undefined

) et activez le versioning S3 avant la réplication inter-régions.

Capturez toujours un état cohérent avec l’application : pour EC2, utilisez AWS Systems Manager Run Command ou des scripts pour vider/verrouiller les systèmes de fichiers avant de créer des instantanés ; pour les bases de données, préférez les instantanés natifs du moteur (RDS/Aurora) ou les sauvegardes logiques (

undefined

) pour une validation à un instant T.

Réplication inter-régions et modèles de reprise d’activité

Les stratégies inter-régions réduisent le rayon d’impact d’une défaillance régionale. La réplication inter-régions S3 (CRR) nécessite le versioning, un rôle IAM de réplication et une configuration de réplication (console ou

undefined

). RDS prend en charge les réplicas en lecture inter-régions (

undefined

) et Aurora Global Database pour les architectures de lecture/écriture inter-régions à faible latence avec un basculement contrôlé. DynamoDB Global Tables réplique les données de manière asynchrone entre les régions et convient aux lectures multi-régions avec des considérations de cohérence à terme (eventual consistency).

Choisissez un modèle de reprise d’activité (DR) en fonction du RTO/RPO et du coût :

Veilleuse (Pilot Light) : répliquer les données critiques vers une région secondaire (S3, instantanés, réplicas de BDD) mais avec une infrastructure en exécution minimale ; montée en charge rapide via des modèles IaC.
Attente tiède (Warm Standby) : une empreinte active plus petite dans la région secondaire avec des données répliquées en continu et des services à échelle réduite qui peuvent être augmentés automatiquement.
Multi-régions actif-actif : exécuter des piles complètes dans plusieurs régions avec un routage du trafic et une résolution des conflits ; nécessite une réplication globale (DynamoDB global tables, Aurora Global DB, gestion des conflits au niveau de l’application).

Prenez en compte la cohérence de la réplication : la réplication synchrone minimise le RPO mais augmente la latence et peut ne pas être prise en charge entre les régions ; la plupart des options inter-régions sont asynchrones et introduisent un décalage de réplication (replication lag) qui définit un RPO réaliste.

Choix d’architecture Multi-AZ et Multi-Régions

Le Multi-AZ est la solution par défaut pour la haute disponibilité au sein d’une région ; il fournit un basculement automatique pour de nombreux services gérés avec un RTO minimal. RDS Multi-AZ et Aurora répliquent le stockage sur plusieurs AZ — le basculement est généralement automatique et utilise une commutation DNS. Pour EC2, placez les instances dans plusieurs AZ derrière un Application Load Balancer et des groupes Auto Scaling ; utilisez des vérifications de l’état inter-AZ pour détecter et remplacer les cibles défaillantes.

Le Multi-Régions ajoute de la résilience contre les pannes à l’échelle d’une région mais augmente la complexité (réplication des données, routage global, conformité). Critères de décision :

Utilisez le Multi-AZ lorsque vous avez besoin d’une haute disponibilité avec une faible latence à l’intérieur d’une région et que vous souhaitez un basculement automatique géré à moindre coût.
Utilisez le Multi-Régions pour la reprise d’activité après la perte d’une région ou pour la réduction de la latence dans une architecture globale actif-actif.

Considérations de conception :

TTL DNS : des TTL bas (par ex., 60s) sont nécessaires pour un basculement rapide basé sur le DNS mais augmentent la charge des requêtes DNS.
Localisation des données et conformité : certaines données doivent rester dans une région ; concevez la réplication et le chiffrement en conséquence.
Coût vs RTO/RPO : une architecture multi-régions actif-actif augmente les coûts mais minimise le RTO.

Mécanismes de basculement (vérifications de l’état de santé Route53, automatisées)

Le basculement automatisé utilise des vérifications de l’état de santé, des stratégies de routage et l’orchestration. Route53 prend en charge les vérifications de l’état de santé et le routage par basculement/pondéré/latence. Configurez les vérifications de l’état de santé Route53 pour sonder les points de terminaison (HTTP, TCP ou alarmes CloudWatch) et un jeu d’enregistrements de basculement qui bascule vers une ressource secondaire lorsque la ressource principale échoue. Exemple de mise à jour CLI : aws route53 change-resource-record-sets –hosted-zone-id Z123456 –change-batch file://changes.json. Utilisez les alarmes CloudWatch (les actions d’alarme déclenchent AWS Lambda) pour orchestrer le basculement pour les actions non liées au DNS.

Intégrez les Load Balancers et Auto Scaling : les vérifications de l’état de santé des groupes cibles ALB/NLB suppriment les instances défaillantes, tandis qu’Auto Scaling les remplace automatiquement. Pour le basculement de base de données, fiez-vous aux mécanismes au niveau du service : basculement automatisé RDS Multi-AZ ou Aurora, et pour la promotion inter-régions, utilisez des réplicas en lecture ou la promotion contrôlée d’Aurora Global DB.

Deux modèles opérationnels :

Basculement DNS (Route53) : rapide à mettre en œuvre, mais dépendant du TTL DNS et de la mise en cache client.
Basculement du plan de contrôle (Lambda/Step Functions + appels API) : orchestre la promotion, la réaffectation d’IP/EIP et les mises à jour de Route53 dans une séquence prévisible pour les applications complexes.

Planification, test et validation RTO/RPO

Le RTO est la durée d’interruption maximale acceptable ; le RPO est la perte de données maximale acceptable. Définissez des objectifs mesurables pour chaque charge de travail et alignez les choix d’architecture : la réplication synchrone réduit le RPO mais peut augmenter la latence ; la réplication asynchrone réduit les coûts mais augmente la fenêtre de perte de données potentielle. Traduisez les SLA métier en fréquence de rétention et de réplication : RPO = retard de réplication + intervalle de sauvegarde ; RTO = temps de détection + temps d’orchestration du basculement + temps de validation de la reprise.

Les tests sont essentiels : exécutez des exercices de reprise après sinistre (DR) planifiés qui valident les procédures de restauration, le basculement DNS et l’intégrité de l’application. Validez les sauvegardes en les restaurant dans un compte ou un VPC isolé (utilisez CloudFormation/CloudFormation StackSets ou Terraform pour automatiser les reconstructions). Capturez des métriques pendant les tests (temps de propagation DNS, point de reprise, vérifications au niveau de l’application) et itérez sur l’automatisation pour réduire le RTO.

Pièges courants et critères de décision

Présumer que les snapshots équivalent à la capacité de restauration : effectuez toujours des restaurations dans un environnement distinct et validez la cohérence applicative ; utilisez des snapshots natifs du moteur ou mettez les applications au repos (quiesce) avant de créer un snapshot.
Concevoir des systèmes mono-région pour des charges de travail critiques mondiales : choisissez des modèles Multi-Région ou une veille tiède (warm standby) lorsque une défaillance régionale impacte les clients ; tenez compte de la souveraineté des données.
Ignorer le RTO/RPO dans la conception : définissez le RTO/RPO par charge de travail et sélectionnez la réplication/les sauvegardes en conséquence ; faites correspondre le RPO à la fréquence de réplication et le RTO à l’automatisation de l’orchestration.
Des TTL DNS longs qui bloquent un basculement rapide : définissez des TTL bas pour les enregistrements de basculement critiques et n’utilisez l’accélération globale que lorsqu’un routage stable est requis.
Négliger les permissions IAM pour la réplication inter-régions : la CRR, la copie de snapshot et l’accès au coffre-fort de sauvegarde (backup vault) nécessitent des rôles et des politiques de ressources corrects ; testez les chemins IAM de la réplication.
Ne pas surveiller le retard de réplication et l’état de santé : instrumentez les métriques CloudWatch (ReplicaLag, CPU, réseau) et alertez lorsque les seuils approchent des limites du RPO.

Problème pratique : Scénario d’utilisation

AcmePayments exploite une API de transaction soumise à la norme PCI dans la région us-east-1 et nécessite un RTO < 5 minutes et un RPO quasi nul pour les données de transaction essentielles en cas de panne régionale.

Définir RTO=5 min et RPO≈0 en sélectionnant Aurora Global Database avec une base de données primaire accessible en écriture dans us-east-1 et une secondaire dans eu-west-1 pour une réplication inter-régions rapide.
Activer le Multi-AZ synchrone/par région pour la haute disponibilité intra-région (réplicas Aurora + Multi-AZ), et publier le DNS via Route53 avec des vérifications de l’état de santé et un TTL bas (60s) pour le routage de basculement.
Utiliser des snapshots automatisés inter-régions et des copies dans un coffre-fort AWS Backup comme copie immuable supplémentaire avec rétention et verrouillage du coffre-fort (vault lock).
Automatiser le playbook de basculement avec Step Functions et Lambda pour valider la promotion du réplica, mettre à jour les enregistrements Route53 (aws route53 change-resource-record-sets), exécuter des tests de fumée (smoke tests) et effectuer un rollback si des défaillances sont détectées.
Planifier des exercices de reprise après sinistre (DR) trimestriels restaurant les sauvegardes dans un VPC isolé et mesurer les RTO et RPO réels, puis affiner l’automatisation et les politiques de mise à l’échelle.

Justification : la combinaison d’un produit de base de données mondial à faible latence (Aurora Global) avec un routage basé sur le DNS et une orchestration automatisée permet de respecter des RTO/RPO stricts tout en gardant les étapes opérationnelles répétables et testables. Une validation régulière garantit que les sauvegardes et les réplicas sont réellement restaurables.

← Surveillance · Tous les domaines · Déploiement →

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