Amazon SAP-C02: Résilience, reprise après sinistre et haute disponibilité — Guide d'étude

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fait partie du AWS Solutions Architect Professional SAP-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.

Planification RTO et RPO : quantifier la tolérance et cartographier l’architecture

Le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective) guident chaque choix de résilience, du dimensionnement des ressources de calcul à la topologie de réplication. Commencez par classer les charges de travail en fonction de leur impact métier et du coût de l’indisponibilité, puis traduisez ces priorités en objectifs mesurables : des RPO de l’ordre de la milliseconde imposent une réplication synchrone ou des bases de données mondiales spécialisées, tandis que des RPO de la minute à l’heure permettent une réplication asynchrone, la planification d’instantanés (snapshots) ou l’envoi de journaux par lots. Utilisez les services AWS qui correspondent à vos objectifs : Amazon Aurora Multi‑AZ et Aurora Global Database pour des RTO/RPO faibles à grande échelle, RDS Multi‑AZ pour une haute disponibilité synchrone dans une seule région, des réplicas en lecture inter-régions pour la reprise et le reporting, et AWS Elastic Disaster Recovery (DRS) pour une réplication quasi temps réel des serveurs sur site avec des modifications applicatives minimales. Un piège courant consiste à concevoir uniquement pour la charge moyenne plutôt que pour les opérations de reprise dans le pire des cas ; un autre est de supposer que les snapshots seuls suffisent à atteindre le RPO pour les systèmes transactionnels, car les snapshots peuvent être espacés de plusieurs minutes et manquer de cohérence applicative. Les arbitrages décisionnels sont clairs : la réplication synchrone augmente le coût et la latence en écriture mais réduit le RPO ; la réplication asynchrone réduit la latence et le coût mais augmente la perte de données potentielle. Testez le plan avec des tests de chaos, des basculements planifiés et des exercices de restauration pour valider les RTO/RPO réels et identifier les dépendances cachées comme l’authentification externe, le DNS ou les listes blanches d’adresses IP.

Architectures Multi‑AZ et Multi-Région et stratégies de basculement

Les architectures Multi‑AZ protègent contre les pannes d’AZ en plaçant des ressources de calcul, de réseau et de stockage redondantes dans plusieurs zones de disponibilité ; le Multi-Région étend la tolérance aux pannes au niveau de la région, aux catastrophes naturelles ou aux partitions réseau de grande ampleur. Choisissez un modèle d’architecture — pilot light, warm standby, actif-passif ou actif-actif — en fonction du coût et des besoins de reprise. Le modèle Pilot light utilise des ressources minimales dans une région secondaire pour minimiser les coûts et monte en charge lors d’un basculement ; le warm standby maintient des services à échelle réduite en fonctionnement pour une reprise plus rapide ; l’actif-actif sert le trafic dans plusieurs régions pour le RTO le plus bas, mais exige une réplication de données robuste et une résolution des conflits. Utilisez Route 53 avec des bilans de santé (health checks) et le routage de basculement, Amazon CloudFront ou Global Accelerator pour la gestion du trafic mondial, et des services de données comme DynamoDB Global Tables ou Aurora Global Database pour la réplication inter-régions. Les pièges courants incluent le fait de se fier à des TTL DNS trop longs, de ne pas valider le basculement des services avec état (stateful) (magasins de sessions, caches), et de négliger les coûts de transfert de données inter-régions et les contraintes de conformité. Mettez en balance la complexité et le coût d’un déploiement multi-région avec l’indisponibilité et la perte de données acceptables ; en cas de doute, instrumentez et modélisez les temps de basculement pour étayer l’analyse de rentabilité (business case).

Modèles de résilience applicative : statelessness, découplage et gestion de l’état

Concevez pour la panne (Design for failure) en minimisant l’état attaché aux nœuds de calcul individuels et en découplant les composants pour que les pannes partielles ne se propagent pas en cascade. Des nœuds applicatifs sans état (stateless) derrière un Application Load Balancer ou un Network Load Balancer permettent une mise à l’échelle horizontale et un remplacement rapide. Pour l’état de session, préférez des magasins externes comme Amazon DynamoDB ou Amazon ElastiCache plutôt que des sessions persistantes (sticky sessions) ; pour les partages de fichiers, utilisez Amazon S3, Amazon EFS ou FSx en fonction du protocole et des besoins de performance. Les modèles asynchrones utilisant Amazon SQS, SNS ou Kinesis absorbent les pics de charge, permettent les nouvelles tentatives, lissent la contre-pression (backpressure), et réduisent les dépendances synchrones pendant un basculement. Implémentez des disjoncteurs (circuit breakers), des cloisons (bulkheads) et une temporisation exponentielle (exponential backoff) dans les clients pour isoler les sous-systèmes défaillants. Un piège fréquent pour les architectes est de sous-estimer les temps de démarrage à froid (cold-start) ou de montée en charge — les limites de simultanéité de Lambda, les délais de récupération (cooldowns) d’Auto Scaling et les stratégies de préchauffage (warm-up) affectent le RTO. Un autre est de considérer la mise en cache comme de la durabilité ; les caches doivent pouvoir être reconstruits. Les arbitrages coût/résilience se manifestent dans le dimensionnement des tampons (buffers) et la réplication : une plus grande résilience nécessite souvent plus de capacité réservée ou une réplication inter-régions, ce qui augmente les coûts ; choisissez la redondance minimale viable qui satisfait les RTO/RPO tout en garantissant l’observabilité et l’automatisation pour détecter les pannes et y remédier.

Sauvegardes, réplication, gouvernance et préparation opérationnelle

Les sauvegardes sont une assurance ; les éléments cruciaux sont la cohérence, la sécurité, la rétention et la capacité de restauration. Utilisez AWS Backup pour des politiques de sauvegarde centralisées sur EBS, RDS, DynamoDB, EFS et FSx, et imposez des copies de sauvegarde inter-comptes et inter-régions pour la résilience géographique. Pour les données objet, activez la gestion des versions S3 avec des règles de cycle de vie (Lifecycle rules) et S3 Replication (CRR) pour une durabilité inter-régions. Assurez des snapshots cohérents au niveau applicatif pour les bases de données et les systèmes de fichiers Windows en tirant parti des sauvegardes natives des bases de données, des snapshots automatisés RDS, ou d’AWS DRS avec le support VSS. La réplication inter-comptes et le principe du moindre privilège IAM sont essentiels pour prévenir les suppressions accidentelles. Des exercices de restauration réguliers révèlent des problèmes liés à des rôles IAM manquants, au réseau (chevauchements de CIDR de VPC) ou à des intégrations externes. Automatisez les runbooks avec Systems Manager Automation et codifiez les procédures de basculement dans CloudFormation ou Terraform pour réduire les erreurs manuelles. Les pièges courants incluent le fait de se fier uniquement aux snapshots à un instant T (point-in-time) sans possibilité d’exportation, de ne pas chiffrer les sauvegardes avec des clés gérées par le client, et de ne pas surveiller la réussite des tâches de sauvegarde. Équilibrez la rétention et les coûts de stockage par rapport aux exigences réglementaires ; hiérarchisez les sauvegardes plus anciennes vers S3 Glacier pour maîtriser les coûts tout en gardant les sauvegardes récentes rapidement accessibles pour des restaurations rapides.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Events Inc., une entreprise mondiale d’événements en direct, exploite une application de billetterie dans une seule région AWS en utilisant des groupes EC2 Auto Scaling derrière un ALB, avec un cluster PostgreSQL à 3 nœuds sur EC2 dans une seule AZ et des snapshots EBS nocturnes. L’organisation doit réduire le RTO à moins de 10 minutes et le RPO à moins de 5 minutes tout en minimisant la charge opérationnelle et les coûts.

Défi : Atteindre une disponibilité quasi continue et une faible perte de données pour la base de données à travers les AZ/régions avec un basculement prévisible et des modifications minimales de l’application.

Approche recommandée :

1. Configurer Amazon RDS for PostgreSQL avec un déploiement Multi-AZ ou migrer vers Amazon Aurora PostgreSQL en Multi-AZ et activer les sauvegardes continues automatisées et les exportations rapides de snapshots ; activer les sauvegardes automatisées avec une fenêtre de rétention appropriée.
2. Ajouter une réplication inter-régions en utilisant Aurora Global Database (ou la réplication logique/physique RDS vers une réplique en lecture dans une région secondaire) pour atteindre les objectifs de RPO géographiques, et configurer le routage basé sur la latence de Route 53 avec des bilans de santé (health checks) pour permettre un basculement de région contrôlé.
3. Remplacer le PostgreSQL sur EC2 en mono-AZ par un service managé pour éliminer la maintenance des hôtes, et refactoriser la logique de connexion de l’application pour utiliser les points de terminaison du cluster ou RDS Proxy pour le regroupement de connexions (connection pooling) et une gestion plus rapide du basculement.
4. Mettre en œuvre une vérification continue de la réplication et l’automatisation des runbooks : exercices de basculement planifiés à l’aide de Systems Manager Automation et de modèles CloudFormation pour une recréation rapide des ressources ; instrumenter les métriques et exécuter des alertes via CloudWatch et SNS.

Justification : L’utilisation de services de base de données managés et Multi-AZ ainsi que la réplication inter-régions réduisent la complexité opérationnelle et permettent d’atteindre des objectifs de RTO/RPO agressifs ; l’automatisation et les exercices périodiques garantissent que le plan fonctionne en pratique, tandis que RDS/Aurora minimisent les étapes de basculement manuel et le temps de basculement.

← Migration et modernisation · Tous les domaines · Optimisation des coûts et gouvernance →

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

Parcourir Amazon →