Niveaux RTO, RPO et DR

Le Recovery Time Objective (RTO) est le délai maximal acceptable entre la survenue d’un sinistre et le rétablissement du fonctionnement de votre système. Si votre RTO est de 4 heures, votre entreprise peut tolérer 4 heures d’interruption. Le Recovery Point Objective (RPO) est la quantité maximale acceptable de données perdues, exprimée en durée : si votre RPO est d’une heure, vous devez pouvoir restaurer un état situé au plus une heure avant le sinistre. Ces deux métriques sont définies par les exigences métier, et non par des préférences techniques.

AWS définit quatre stratégies principales de reprise après sinistre, classées du coût le plus faible / RTO le plus élevé au coût le plus élevé / RTO le plus faible : 1) Sauvegarde et restauration — la moins coûteuse, avec un RTO de plusieurs heures. 2) Pilot Light — les composants essentiels restent toujours actifs, avec un RTO de quelques minutes à quelques heures. 3) Warm Standby — une copie réduite mais fonctionnelle, avec un RTO de quelques minutes. 4) Multi-Site Active-Active — la plus coûteuse, avec un RTO proche de zéro. Votre choix dépend du coût métier d’une interruption comparé au coût de l’infrastructure de reprise après sinistre.

Avec la sauvegarde et la restauration, vous effectuez régulièrement des instantanés de vos données et les stockez dans un autre emplacement (par exemple, S3 avec réplication entre régions). En cas de sinistre, vous restaurez la sauvegarde la plus récente. Il s’agit de la stratégie la moins coûteuse, car aucune infrastructure de secours n’est exécutée. En contrepartie, elle offre le RTO le plus long (plusieurs heures pour restaurer de grandes bases de données à partir d’instantanés) et le RPO le plus élevé (les données créées depuis la dernière sauvegarde sont perdues). AWS Backup automatise les planifications d’instantanés pour EC2, RDS, EFS, DynamoDB, etc.

La stratégie Pilot Light maintient les composants essentiels de votre système en fonctionnement dans une région de reprise après sinistre, à capacité minimale — comme une veilleuse capable d’allumer rapidement une flamme complète. En général, cela signifie que votre base de données est répliquée en continu vers la région de reprise et qu’une infrastructure réseau de base (VPC, sous-réseaux, groupes de sécurité) est maintenue. Les serveurs d’application ne sont NOT pas en cours d’exécution, mais peuvent être lancés rapidement à partir d’AMI ou de modèles de lancement préconfigurés. Le RTO est généralement de 30 minutes à plusieurs heures, selon la quantité de travail manuel nécessaire.

La stratégie Warm Standby exécute une copie entièrement fonctionnelle mais réduite de votre environnement de production dans la région de reprise après sinistre. Contrairement à Pilot Light, le niveau applicatif est actif (peut-être avec 1 ou 2 instances au lieu de 20), et la base de données est une base secondaire Aurora Global Database ou une réplique en lecture RDS. Lors du basculement, vous augmentez la capacité de l’environnement de reprise pour qu’elle corresponde à celle de la production. Le RTO est généralement inférieur à 15 minutes. Il s’agit de la stratégie de reprise après sinistre la plus courante pour les charges de travail d’importance moyenne à élevée.

Multi-Site Active-Active exécute simultanément la capacité complète de production dans au moins deux régions. Toutes les régions traitent du trafic réel et les données sont répliquées en quasi-temps réel (ou selon un modèle multimaître). Il n’y a aucun délai de basculement : lorsqu’une région tombe en panne, Route 53 ou Global Accelerator achemine immédiatement tout le trafic vers les régions restantes en bon état. Cette stratégie offre les RTO et RPO les plus faibles, mais aussi le coût le plus élevé, car vous payez en permanence la capacité complète de production dans toutes les régions.

Votre RPO détermine directement la technologie de réplication dont vous avez besoin. Un RPO = 0 nécessite une réplication synchrone : aucune donnée n’est perdue. Un RPO de quelques secondes nécessite une réplication asynchrone en quasi-temps réel, comme Aurora Global Database (retard <1 s). Un RPO de quelques minutes permet une réplication asynchrone avec un faible retard (DynamoDB Streams, répliques en lecture RDS). Un RPO de plusieurs heures peut être obtenu avec des instantanés périodiques (planification horaire d’AWS Backup). Définissez clairement l’exigence de RPO de votre entreprise avant de choisir une technologie.

Les architectures sans serveur (Lambda, DynamoDB, API Gateway) sont naturellement plus résilientes, mais nécessitent tout de même une planification de reprise après sinistre. Les tables globales DynamoDB fournissent un fonctionnement actif-actif multirégion pour le niveau de base de données. Lambda peut être déployé dans une deuxième région à partir du même pipeline CI/CD. API Gateway doit être approvisionné dans la région de reprise après sinistre. Le principal risque est la dérive de configuration entre les régions : utilisez AWS CDK ou Terraform pour déployer une infrastructure identique dans les deux régions à partir de la même base de code.

Considérez une entreprise dont le chiffre d’affaires annuel s’élève à 10 M$. Si une interruption coûte 1 000 $ par minute, une panne de 8 heures (RTO=8 h) coûte 480 000 $. Une infrastructure de secours Warm Standby active-passive avec un RTO de 15 minutes réduit la perte potentielle à 15 000 $ par incident. Si l’infrastructure de secours coûte 5 000 $ par mois (60 000 $ par an), elle n’est économiquement justifiée que si vous subissez plus d’une interruption importante par an. Cette analyse de justification des coûts correspond exactement à ce que l’examen SAA-C03 vous demande d’effectuer lors de la sélection de stratégies de reprise après sinistre.

Un plan de reprise après sinistre qui n’a jamais été testé n’est qu’un document. AWS recommande vivement d’effectuer régulièrement des exercices de reprise après sinistre : entraînez-vous aux procédures de basculement, mesurez les RTO et RPO réels et identifiez les lacunes. Utilisez AWS Fault Injection Simulator (FIS) pour simuler de manière contrôlée une dégradation régionale. Documentez des guides opérationnels décrivant les étapes de basculement afin que, sous la pression d’un incident réel, l’équipe d’astreinte suive une procédure claire et testée plutôt que d’improviser.

De nombreux secteurs sont soumis à des exigences réglementaires en matière de reprise après sinistre. PCI DSS exige la documentation et le test des plans de reprise après sinistre. HIPAA exige des procédures de sauvegarde des données et de reprise après sinistre. SOC 2 évalue les contrôles de disponibilité, notamment ceux liés à la reprise après sinistre. Utilisez AWS Config et AWS Audit Manager pour évaluer et documenter en continu la configuration correcte de vos ressources de reprise après sinistre (sauvegardes, répliques, vérifications d’intégrité). Vous disposez ainsi de preuves pour les audits de conformité sans collecte manuelle.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : le RTO correspond à la durée maximale d’indisponibilité acceptable et le RPO à la perte de données maximale acceptable, les quatre niveaux de DR établissent un compromis entre le coût et la rapidité de récupération, et votre exigence de RPO détermine la technologie de réplication à utiliser. Testez toujours votre plan de DR afin de valider les valeurs réelles du RTO et du RPO. Nous allons maintenant étudier en détail la stratégie Backup and Restore.