Héberger vos charges critiques sur Amazon Web Services (AWS) ne transfère pas la responsabilité de la continuité. Dans le modèle de responsabilité partagée AWS, AWS garantit la résilience du cloud — mais la résilience dans le cloud vous incombe. Ce guide montre comment concevoir un programme BCDR (continuité d'activité & reprise après sinistre) AWS techniquement solide et prêt pour l'audit ISO 22301, DORA et NIS2 — et comment ResiPlan en fait une preuve vivante et démontrable.
Ce que « BCDR pour AWS » signifie vraiment
Le BCDR, ce sont deux disciplines complémentaires :
- Continuité d'activité (BC) — maintenir vos processus métier (personnes, fournisseurs, communications, décisions) quand quelque chose casse.
- Reprise après sinistre (DR) — la reprise technique des systèmes et des données.
Sur AWS, on est tenté de réduire le DR à de l'infrastructure (snapshots, multi-AZ, réplication). C'est ce qui fait échouer les audits. Les régulateurs veulent un DR dérivé d'un Bilan d'Impact sur l'Activité (BIA) — des objectifs de reprise qui découlent de la criticité métier, pas de ce que la plateforme sait faire.
Étape 1 — Fixer les RTO/RPO depuis l'impact métier, pas depuis AWS
Deux chiffres structurent tout DR :
- RTO (Recovery Time Objective) — durée d'indisponibilité tolérable avant dommage inacceptable.
- RPO (Recovery Point Objective) — perte de données tolérable (en temps).
Dérivez-les d'un BIA par processus, puis associez chaque palier à une stratégie DR AWS :
| Palier RTO / RPO | Stratégie DR AWS | Coût |
|---|---|---|
| RTO heures, RPO heures | Backup & Restore (S3, AWS Backup, copie inter-région) | $ |
| RTO ~10aines de min, RPO minutes | Pilot Light (données répliquées, infra dormante) | $$ |
| RTO minutes, RPO secondes | Warm Standby (copie active réduite) | $$$ |
| RTO quasi-nul, RPO quasi-nul | Multi-région Actif/Actif | $$$$ |
Utilisez un calculateur RTO/RPO gratuit pour traduire la criticité en paliers cibles avant toute architecture.
Étape 2 — Le multi-AZ, c'est de la haute disponibilité, pas du DR
Constat d'audit fréquent : des équipes annoncent du « DR » alors qu'elles n'ont que du multi-AZ. Les zones de disponibilité protègent d'une panne de datacenter dans une région. Elles ne protègent pas contre :
- une dégradation de service à l'échelle d'une région,
- un déploiement corrompu ou un ransomware qui se réplique instantanément,
- une compromission de compte ou une suppression accidentelle.
Un vrai DR exige une capacité inter-régions (au minimum Backup & Restore) et, pour les fonctions critiques, une stratégie multi-régions testée. Documentez quelle menace chaque couche couvre — les auditeurs le demandent.
Étape 3 — Une sauvegarde qui survit à un audit (et à un ransomware)
- AWS Backup avec copie inter-région et inter-compte (un attaquant dans votre compte prod ne doit pas pouvoir supprimer vos seules sauvegardes).
- S3 Object Lock / immuabilité (WORM) sur les coffres de sauvegarde — le contrôle le plus efficace contre la suppression de backups par ransomware.
- Chiffrement KMS et plan de récupération des clés documenté (une CMK perdue = données irrécupérables).
- Tests de restauration planifiés — une sauvegarde non testée n'est qu'une hypothèse. Chaque test = une preuve.
Étape 4 — Ne pas oublier le « business » dans BCDR
Un runbook DR parfait échoue si les humains ne sont pas prêts. Votre programme BCDR AWS doit aussi couvrir :
- Plans de continuité (PCA/PRA/PGC) par processus critique.
- Communication de crise et structure de commandement.
- Cartographie des dépendances tierces (AWS est lui-même un tiers critique — DORA le traite comme prestataire TIC).
- Exercices — tabletop et bascules techniques, au moins annuels.
Étape 5 — Aligner le BCDR AWS sur vos obligations de conformité
C'est là que la plupart des programmes DR cloud perdent des points :
- ISO 22301 — clauses 8.4 (stratégies de continuité), 8.5 (exercices), 8.4.4 (reprise). Vos paliers DR AWS sont vos stratégies de continuité.
- DORA (Règl. UE 2022/2554) — AWS est un prestataire TIC tiers : à inscrire au Registre d'Information, avec stratégie de sortie et tests de résilience (Art. 24-27). Les fonctions critiques exigent des justifications RTO/RPO documentées (Art. 11-12).
- NIS2 (Dir. UE 2022/2555) — continuité, gestion des sauvegardes et gestion de crise sont des exigences explicites (Art. 21).
Comment ResiPlan opérationnalise le BCDR pour AWS
ResiPlan est un SMCA (système de management de la continuité) conçu pour cet alignement :
- RTO/RPO issus du BIA qui alimentent votre paliérisation DR AWS, en traçabilité totale.
- Générateurs de plans IA (PCA/PRA/PGC) qui rédigent des runbooks de reprise spécifiques AWS.
- CMDB + cartographie des dépendances pour enregistrer AWS comme prestataire TIC critique (DORA).
- Modules exercices & maturité pour planifier, exécuter et prouver vos bascules (ISO 22301 clause 8.5).
- Tableaux de bord de conformité DORA, NIS2 et ISO 22301 depuis une source unique.
Commencez ici : la checklist de préparation DORA et la checklist ISO 22301, puis demandez une démo pour voir vos charges AWS reliées à un programme de continuité défendable.
Le BCDR pour AWS n'est pas une tâche de sauvegarde — c'est une décision métier, prouvée. ResiPlan maintient cette preuve à jour : votre prochain audit prend des heures, pas des semaines.