Reprise après sinistre sur AWS : stratégies pour les PME

Protéger votre activité contre les interruptions

Un plan de reprise après sinistre (disaster recovery) définit comment votre entreprise reprend son activité après une panne majeure : défaillance matérielle, erreur humaine, cyberattaque ou catastrophe naturelle. Sur AWS, plusieurs stratégies existent avec des niveaux de protection et de coût différents. Le choix dépend de deux métriques : le RTO (temps de reprise acceptable) et le RPO (perte de données maximale acceptable).

Les quatre stratégies de disaster recovery

Backup and restore

La stratégie la plus simple et la moins coûteuse. Vos données sont sauvegardées régulièrement vers Amazon S3 dans une autre région. En cas de sinistre, vous recréez l’infrastructure et restaurez les données. Le RTO est de plusieurs heures (le temps de recréer l’infrastructure) et le RPO dépend de la fréquence de vos sauvegardes.

Cette stratégie convient aux applications non critiques et aux PME avec un budget limité. Le coût se limite au stockage S3 des sauvegardes, soit quelques euros par mois pour la plupart des PME.

Pilot light

Une infrastructure minimale tourne en permanence dans une seconde région AWS : base de données répliquée, configuration réseau prête. En cas de sinistre, vous démarrez les serveurs d’application et basculez le trafic. Le RTO est de 30 minutes à 2 heures et le RPO est de quelques minutes grâce à la réplication continue de la base de données.

Le coût est modéré car seule la base de données et quelques composants réseau tournent en permanence. Les serveurs d’application ne sont démarrés qu’en cas de besoin.

Warm standby

Une version réduite de votre infrastructure tourne en permanence dans la seconde région. Les serveurs d’application sont actifs mais avec une capacité réduite. En cas de sinistre, vous augmentez la capacité et basculez le trafic. Le RTO est de quelques minutes et le RPO est quasi nul.

Active-active (multi-site)

Votre infrastructure tourne à pleine capacité dans deux régions simultanément. Le trafic est réparti entre les deux régions. En cas de défaillance d’une région, l’autre absorbe tout le trafic automatiquement. Le RTO et le RPO sont quasi nuls, mais le coût est le double de votre infrastructure normale.

Les services AWS pour le disaster recovery

AWS Backup centralise la gestion des sauvegardes pour EC2, RDS, DynamoDB, EFS et S3. Vous définissez des politiques de sauvegarde (fréquence, rétention, réplication inter-régions) et AWS Backup les exécute automatiquement.

Amazon RDS supporte la réplication multi-AZ (haute disponibilité dans une région) et les réplicas en lecture inter-régions (disaster recovery). Aurora offre une réplication globale avec un basculement automatique en moins d’une minute.

Route 53 gère le basculement DNS avec des health checks. Si votre infrastructure principale ne répond plus, Route 53 redirige automatiquement le trafic vers l’infrastructure de secours.

Tester votre plan régulièrement

Un plan de disaster recovery non testé est un plan qui ne fonctionne pas. Planifiez des tests trimestriels qui simulent un sinistre et mesurent le RTO et le RPO réels. Documentez les résultats et ajustez le plan en conséquence.

LCMH conçoit des plans de disaster recovery sur AWS adaptés au budget et aux exigences des PME alsaciennes.

Pour l’optimisation des coûts, consultez notre article sur les 7 leviers d’optimisation AWS.

Sources

1. AWS, Disaster Recovery of Workloads on AWS. docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws
2. AWS, AWS Backup. aws.amazon.com/backup
3. AWS, Reliability Pillar - Well-Architected Framework. docs.aws.amazon.com/wellarchitected/latest/reliability-pillar