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

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. 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.

Déploiements Multi-AZ et Réplication

Les architectures Multi-AZ répondent à la défaillance d’un seul centre de données ou d’une seule zone de disponibilité — rien de plus. Cette distinction est le point le plus souvent mal compris dans la conception de la haute disponibilité. Un déploiement Multi-AZ tolère la perte d’une AZ au sein d’une seule Région ; il ne tolère pas une panne à l’échelle d’une Région, une dégradation de service régionale, ou la suppression accidentelle d’une ressource qui réplique immédiatement cette suppression vers l’instance de secours (standby). La réplication propage fidèlement les données erronées — corruption logique, erreurs de schéma, écritures de rançongiciels — c’est pourquoi la réplication et la sauvegarde sont complémentaires, et non des substituts.

Pour Amazon RDS, le Multi-AZ provisionne un réplica de secours (standby) synchrone dans une AZ différente. Les écritures sont validées (commit) sur les deux instances avant d’être acquittées, offrant un RPO effectivement nul et un RTO typiquement de 60 à 120 secondes lors d’un basculement (failover) automatique. Dans le déploiement Multi-AZ classique de type instance, l’instance de secours n’est pas lisible — elle existe uniquement pour la durabilité et le basculement. Les déploiements en cluster Multi-AZ (deux instances de secours lisibles) réduisent encore le temps de basculement et fournissent une certaine mise à l’échelle en lecture, mais restent confinés à une seule Région.

Pour la mise à l’échelle en lecture, ajoutez des réplicas en lecture (read replicas). Les réplicas en lecture utilisent la réplication asynchrone et servent à décharger les requêtes de reporting, d’analytique et de tableaux de bord. Considérer un réplica en lecture comme un mécanisme de basculement pour la haute disponibilité est une erreur pour trois raisons : la réplication est asynchrone (perte de données lors de la promotion), la promotion est manuelle ou scriptée (non automatique), et le point de terminaison (endpoint) principal n’est pas conservé. Lorsqu’une charge de travail croissante nécessite plus de capacité de lecture sans complexité supplémentaire, ajoutez un réplica en lecture ; lorsque l’exigence est un basculement automatique sans perte de données, utilisez le Multi-AZ. Lorsque le RPO/RTO doit survivre à une défaillance de Région pour un moteur relationnel, Aurora Global Database fournit une latence de réplication inter-régionale inférieure à la seconde et un RTO de basculement géré inférieur à la minute.

Amazon ElastiCache suit le même modèle avec les groupes de réplication. Un groupe de réplication Redis avec le Multi-AZ activé maintient un nœud principal (primary) et un ou plusieurs réplicas à travers les AZ ; si le principal tombe en panne, ElastiCache promeut un réplica et met à jour le point de terminaison principal. Pour la mise à l’échelle horizontale, Redis (avec le mode cluster activé) partitionne les données à travers des partitions (shards), chaque partition étant son propre groupe de réplication. Memcached, en revanche, ne réplique pas — la perte d’un nœud signifie la perte des données pour cette partition.

Amazon FSx propose des types de déploiement Multi-AZ pour FSx for Windows File Server et FSx for ONTAP, utilisant la réplication synchrone entre un serveur de fichiers principal (preferred) et un serveur de secours (standby). FSx for Lustre est généralement mono-AZ (scratch ou persistent) ; la durabilité pour Lustre provient des associations avec un référentiel de données S3, et non de la réplication entre AZ.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Sauvegardes Automatisées RDS et Récupération à un Instant Donné

Les sauvegardes automatisées de RDS combinent un snapshot quotidien avec des téléversements continus des journaux de transactions toutes les 5 minutes vers S3, offrant une récupération à un instant donné (PITR) à la seconde près dans la fenêtre de rétention de 1 à 35 jours. Si votre RPO est de 2 heures, les sauvegardes natives de RDS le couvrent déjà — aucune planification de snapshot supplémentaire n’est requise, et ajouter AWS Backup par-dessus est redondant, sauf si vous avez besoin de copies inter-régionales, d’une isolation inter-comptes, ou d’une sémantique Vault Lock au-delà de ce que fournit la copie de snapshot RDS. La sauvegarde automatisée par défaut est souvent la réponse correcte la moins chère pour des exigences de RPO modestes.

AWS Backup comme Plan de Contrôle Centralisé

AWS Backup est le plan de contrôle piloté par des politiques pour la sauvegarde sur EBS, EC2 (en tant qu’AMI), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3, et plus encore. Plutôt que de scripter une logique de snapshot spécifique à chaque service, vous définissez des plans de sauvegarde (backup plans) regroupant des règles qui décrivent la fréquence, la fenêtre de sauvegarde, les fenêtres de début/fin, les transitions de cycle de vie vers le stockage à froid (cold storage), la rétention et les coffres-forts (vaults) de destination. Les ressources sont inscrites via des affectations de ressources (resource assignments) par tag ou ARN, de sorte qu’une convention de tagging comme Backup=Daily devient le contrat opérationnel qui régit la couverture. Pour des flottes de centaines d’instances EC2, la sélection basée sur les tags est l’approche la moins coûteuse en effort — appliquez le tag et laissez AWS Backup faire l’énumération, plutôt que de créer des planifications par instance.

Un coffre-fort de sauvegarde (backup vault) est le conteneur chiffré par KMS où résident les points de restauration. L’accès est contrôlé par des politiques de ressources sur le coffre-fort.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Copies Inter-Régionales et Inter-Comptes

Le bloc CopyActions est le mécanisme pour les copies de reprise après sinistre (DR) inter-régionales. AWS Backup gère la copie du snapshot, le rechiffre avec une clé KMS de la Région de destination (le coffre-fort de destination doit référencer une clé dans cette Région), et applique un cycle de vie indépendant. Les snapshots EBS et RDS sont par défaut dans la Région source — si toute la Région est défaillante, les snapshots le sont aussi. Toute exigence réglementaire ou métier mentionnant la résilience régionale doit inclure une étape explicite de copie inter-régionale, que ce soit via les actions de copie d’AWS Backup, la copie inter-régionale de snapshots automatisés RDS, ou les politiques DLM avec des destinations inter-régionales.

Pour les copies inter-comptes, AWS Organizations délègue un compte administrateur pour AWS Backup ; la politique du coffre-fort source autorise le compte de destination, et le coffre-fort de destination autorise les copies depuis la source. C’est la manière économique de centraliser la reprise après sinistre : un compte de gestion détient les points de restauration de nombreux comptes de charge de travail et peut restaurer dans l’une ou l’autre Région. Pour EC2, une copie d’AMI vers une seconde Région ainsi que le partage de snapshots vous permettent de lancer des instances là-bas sans infrastructure pré-chauffée (warm infrastructure). Les snapshots chiffrés nécessitent le partage de la CMK — le compte ou la Région de destination a besoin de kms:CreateGrant et de l’accès à la clé. Omettre cela est la raison pour laquelle les restaurations inter-comptes échouent silencieusement.

Un RPO de 24 heures est satisfait à peu de frais par un snapshot automatisé quotidien copié entre Régions — bien moins coûteux qu’un réplica en lecture inter-régional ou un cluster de secours pré-chauffé (warm standby). Ne passez à la réplication continue que lorsque le RPO descend en dessous de ce que la cadence des snapshots peut fournir.

Cycle de vie des AMI et sauvegardes EC2

Deux mécanismes automatisent les sauvegardes EC2 : Data Lifecycle Manager (DLM) et AWS Backup. DLM est antérieur à AWS Backup et crée, selon un calendrier, des snapshots EBS ou des AMI basés sur des politiques, avec des actions de copie inter-régions et inter-comptes. AWS Backup englobe cette fonctionnalité et y ajoute une politique centralisée, Vault Lock, et une portée multi-services. Préférez AWS Backup si vous l’utilisez déjà pour d’autres services ; utilisez DLM pour des scénarios purement EBS/AMI où vous n’avez pas besoin des fonctionnalités de coffre-fort (vault).

Pour les niveaux web sans état (stateless) derrière un groupe Auto Scaling sans données locales persistantes, la sauvegarde d’instances EC2 en cours d’exécution est un gaspillage. La posture correcte consiste à créer une AMI renforcée (hardened) (via EC2 Image Builder ou un pipeline CI), à la référencer dans le modèle de lancement, et à laisser l’ASG gérer le remplacement des instances. L’effort de sauvegarde se concentre sur les niveaux avec état (stateful) dont les sauvegardes automatisées natives respectent le RPO.

Immuabilité : Vault Lock et Object Lock

Un simple snapshot dans votre compte peut être supprimé par quiconque disposant de la permission IAM appropriée — les snapshots seuls ne satisfont pas aux exigences d’immuabilité. Les régimes réglementaires (SEC 17a-4, FINRA, HIPAA, GDPR) exigent fréquemment une rétention de type WORM (write-once-read-many) que même les administrateurs ne peuvent contourner. Deux mécanismes AWS permettent d’y parvenir.

AWS Backup Vault Lock applique le mode WORM sur un coffre-fort de sauvegarde (backup vault) :

En mode conformité, une fois la période de réflexion écoulée, aucun utilisateur — y compris le compte root — ne peut raccourcir la durée de rétention, supprimer des points de restauration avant leur expiration, ou supprimer le verrou lui-même. Cela met en échec à la fois la suppression par un initié et par un opérateur de ransomware qui aurait entièrement compromis le compte.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock fournit une protection WORM au niveau de l’objet en mode Gouvernance (les utilisateurs privilégiés avec s3:BypassGovernanceRetention peuvent outrepasser) ou en mode Conformité (personne, y compris le compte root, ne peut supprimer ou raccourcir la durée de rétention). La conservation légale (Legal Hold) est indépendante des périodes de rétention. Object Lock nécessite le versioning et doit être activé à la création du bucket pour une protection complète.

Réservations de capacité pour la région de basculement

Un plan de reprise d’activité (DR) qui suppose que la région de basculement (failover) disposera de la capacité EC2 nécessaire le jour d’un événement à grande échelle n’est pas un plan viable. Lorsqu’une région tombe en panne, tout le monde bascule simultanément, et les types d’instances — en particulier les formes larges, GPU ou spécialisées — peuvent s’épuiser. Les On-Demand Capacity Reservations (ODCRs) dans la région cible garantissent la capacité pour un type d’instance, une plateforme et une AZ spécifiques, et sont facturées qu’elles soient utilisées ou non. Associez-les à un Savings Plan pour compenser le coût. Pour les engagements à long terme pour le GPU/ML, les Capacity Blocks s’appliquent ; pour une flexibilité au niveau de la famille, une Capacity Reservation Fleet couvre plusieurs familles d’instances. Le principe : si l’entreprise exige une capacité de calcul garantie dans la région de DR, réservez-la — ne vous fiez pas à la disponibilité en mode “best-effort” des instances à la demande (On-Demand).

Sélection de la stratégie de DR

AWS formalise quatre niveaux de DR, chacun avec un compromis coût/reprise distinct :

Le niveau correct est dicté par les RPO et RTO de l’entreprise — et non par une préférence architecturale. Un RPO de 24 heures tolère des copies quotidiennes de snapshots inter-régions (Sauvegarde et restauration). Un RPO de quelques secondes exige une réplication continue — réplicas en lecture inter-régions, Aurora Global Database, DynamoDB Global Tables, ou S3 Cross-Region Replication. Tenter d’atteindre un RPO de 5 minutes avec des snapshots nocturnes est architecturalement impossible, quel que soit le budget. Inversement, opter par défaut pour l’actif-actif pour chaque charge de travail est un anti-pattern en matière de coûts : cela exige des données globalement cohérentes (DynamoDB Global Tables ou Aurora Global avec write-forwarding), la duplication des ressources de calcul à pleine échelle, et un routage de trafic complexe via Route 53 ou Global Accelerator. Choisissez le modèle le moins cher qui respecte les RPO/RTO définis — pour un RPO de 2 heures, la sauvegarde et restauration ou la veilleuse suffisent généralement, et l’attente active relève de la sur-ingénierie.

Protection contre la suppression et protections en couches

La résilience ne se résume pas à « avons-nous des sauvegardes ? » — mais plutôt à « un acteur unique, une erreur ou une attaque peut-il les effacer ? ». Des contrôles en couches préviennent la catastrophe du « mauvais clic ».

• RDS : activer DeletionProtection et exiger un snapshot final lors de la suppression.
• EC2 : activer DisableApiTermination et DisableApiStop sur les instances critiques.
• DynamoDB : activer la protection contre la suppression et la restauration à un instant T (point-in-time recovery).
• S3 : Versioning + MFA Delete + Object Lock pour l’immuabilité.
• CloudFormation : DeletionPolicy: Retain sur les ressources avec état (stateful) et protection contre la terminaison de la pile.
• IAM SCPs : refuser backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance, et ec2:DeleteSnapshot en dehors des rôles d’urgence (break-glass).

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Combinés avec Vault Lock en mode conformité, ces mécanismes produisent une défense en profondeur : même un identifiant d’administrateur compromis ne peut pas détruire les points de restauration qui constituent la dernière ligne de défense.

Pièges courants

Considérer le Multi-AZ comme un plan de reprise d’activité (DR). RDS Multi-AZ, ElastiCache Multi-AZ et FSx Multi-AZ résident tous dans une seule Région. Une panne d’API régionale, une suppression accidentelle de table ou une migration de schéma mal appliquée affecte les deux nœuds. Toute exigence mentionnant « une autre Région », « panne régionale » ou « RPO inter-régional » impose une réplication ou une copie inter-régionale — le Multi-AZ seul ne répond pas à cette exigence.

Confondre les réplicas en lecture (read replicas) avec la haute disponibilité (HA). Les réplicas en lecture sont asynchrones, leur promotion est manuelle et leur point de terminaison (endpoint) change. Ils résolvent les problèmes de mise à l’échelle en lecture (read scaling), pas le basculement automatique (failover).

Supposer que les snapshots garantissent la conformité. Les snapshots sans Vault Lock (mode conformité) ou Object Lock peuvent être supprimés par tout principal disposant de la permission IAM adéquate et par le compte root. La rétention réglementaire WORM exige une configuration d’immuabilité explicite avec une période de réflexion (cooling-off period) verrouillée et écoulée.

Snapshots uniquement locaux pour un RPO régional. Les snapshots EBS et RDS sont créés par défaut dans la Région source. La résilience régionale nécessite une action de copie inter-régionale explicite.

Sauvegardes sans tests de restauration ni capacité réservée. Un snapshot que vous n’avez jamais restauré est une hypothèse, pas une sauvegarde. Les exercices de restauration révèlent des rôles IAM manquants, des problèmes d’accès aux clés KMS dans la Région et le compte de destination, et des types d’instances non disponibles. Sans réservations de capacité (Capacity Reservations) pour les charges de travail critiques, la Région de DR pourrait tout simplement ne pas avoir la configuration dont vous avez besoin lorsque tout le monde bascule simultanément — et le RTO devient alors illimité.

Sur-ingénierie vers un modèle actif-actif. Dupliquer la puissance de calcul mondiale, la réplication de données globalement cohérente et la gestion de trafic complexe coûtent cher. Si le RPO/RTO ne le justifie pas, une architecture de type « veilleuse » (pilot light) ou « secours tiède » (warm standby) est la solution adéquate.

Sauvegarder les niveaux sans état (stateless). Créer des snapshots de serveurs web éphémères derrière un ASG gaspille de l’argent et complique la restauration. Préparez des AMI, référencez-les dans des modèles de lancement (launch templates) et concentrez l’investissement de sauvegarde sur les données persistantes (stateful).

← Gestion · Tous les domaines

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

Parcourir Amazon →