Sauvegarde et PRA sur AWS : le minimum viable pour une PME

En audit, la question « quel est votre plan de reprise d’activité ? » reçoit presque toujours la même réponse : « on a des snapshots automatiques ». C’est un backup, pas un PRA. La nuance paraît académique jusqu’au jour où un compte AWS est compromis, un admin supprime la mauvaise base en production, ou un ransomware chiffre les volumes EBS — et que personne n’a jamais testé une restauration complète en conditions réelles.

Sur la trentaine d’audits Well-Architected menés par Distribuée ces 18 derniers mois, le pilier Fiabilité (Reliability) est systématiquement celui qui remonte le plus de non-conformités — devant même le pilier Sécurité. Pas parce que les PME n’ont pas de backups, mais parce qu’elles n’ont jamais formalisé ni testé le scénario de reprise. Voici le socle minimum viable, sans sur-ingénierie.

Backup et PRA ne sont pas la même chose

Un backup répond à la question « puis-je récupérer un fichier ou une table supprimée par erreur ? ». Un plan de reprise d’activité (PRA) répond à une question plus large : « si toute ma région AWS, mon compte, ou mon infrastructure de production devient inutilisable, en combien de temps est-ce que je repars, et avec combien de données perdues ? ».

Ces deux métriques ont des noms précis dans le vocabulaire AWS Well-Architected :

• RPO (Recovery Point Objective) : combien de données vous acceptez de perdre, mesuré en temps depuis le dernier point de restauration valide.
• RTO (Recovery Time Objective) : combien de temps vous acceptez que le service soit indisponible avant d’être restauré.

La plupart des PME n’ont jamais posé ces deux chiffres par écrit. Résultat : le niveau de protection réel dépend de ce qu’un ingénieur a activé par défaut il y a deux ans, pas d’une décision consciente rapportée au coût qu’un sinistre représenterait réellement pour l’activité.

Les 4 niveaux de PRA et leur coût réel

Le whitepaper AWS sur la reprise d’activité définit quatre stratégies, du moins cher au plus cher. Elles ne sont pas interchangeables — chacune cible un couple RTO/RPO différent, et le bon choix dépend de ce que coûterait réellement une heure d’indisponibilité pour votre activité.

Pour la très grande majorité des PME (5-200 personnes) sans obligation contractuelle de disponibilité continue, le niveau 1 — Backup & Restore, bien configuré — couvre déjà l’essentiel des scénarios réels : suppression accidentelle, erreur de déploiement, ransomware, compte compromis. Les niveaux 3 et 4 ont un coût d’infrastructure permanent (capacité dupliquée qui tourne, même inactive) qui ne se justifie que si l’activité perd réellement de l’argent à chaque minute d’indisponibilité — un SaaS avec SLA contractuel, une plateforme de paiement, un service médical.

AWS Backup : le socle minimum viable

AWS Backup centralise la sauvegarde de la majorité des services (EBS, EFS, RDS, DynamoDB, Aurora, S3 depuis 2023) dans un service managé unique, avec politiques de cycle de vie et rétention. Le tarif de base :

• Stockage warm (accès immédiat) : environ 0,05 $/Go-mois pour EBS/EFS, 0,095 $/Go-mois pour RDS, 0,10 $/Go-mois pour DynamoDB.
• Stockage cold (rétention longue) : 70-80 % moins cher que le warm, mais rétention minimale de 90 jours — toute suppression avant terme est facturée au prorata du temps restant.
• Nouveau palier low-cost pour S3 (lancé fin 2025) : environ 0,035 $/Go-mois après 60 jours de rétention warm, soit ~30 % de moins que le palier standard.
• Restauration : environ 0,02 $/Go pour la plupart des ressources, 0,50 $ par requête pour une restauration au niveau fichier/objet individuel.

Le socle minimum pour une PME tient en trois éléments Terraform :

resource "aws_backup_vault" "main" {
  name = "prod-vault"
}

resource "aws_backup_plan" "prod" {
  name = "prod-daily"

  rule {
    rule_name         = "daily-backup"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 3 * * ? *)"

    lifecycle {
      cold_storage_after = 30
      delete_after        = 365
    }

    copy_action {
      destination_vault_arn = aws_backup_vault.dr.arn  # copie cross-région
      lifecycle {
        delete_after = 365
      }
    }
  }
}

resource "aws_backup_selection" "prod" {
  name         = "prod-resources"
  plan_id      = aws_backup_plan.prod.id
  iam_role_arn = aws_iam_role.backup.arn

  resources = ["arn:aws:rds:eu-west-3:*:db:*", "arn:aws:ec2:eu-west-3:*:volume/*"]
}

Trois points souvent absents dans les configurations qu’on audite :

1. La copie cross-région n’est presque jamais activée. Un vault de backup dans la même région que la production ne protège pas contre une défaillance régionale — rare, mais c’est exactement le scénario qu’un PRA doit couvrir.
2. Aucun Vault Lock. Sans verrouillage, un compte compromis (identifiants admin volés, ransomware avec accès IAM) peut supprimer les backups avant de chiffrer les données de production — un mode opératoire de plus en plus courant.
3. La restauration n’a jamais été testée. Un backup qui n’a jamais été restauré dans un environnement isolé n’est pas un plan validé, c’est une hypothèse.

Vault Lock et vault air-gapped : la protection anti-ransomware

AWS Backup Vault Lock, en mode Compliance, rend les points de restauration immuables : la durée de rétention ne peut plus être réduite, et aucun principal — y compris le compte root — ne peut supprimer un backup avant expiration. C’est le mécanisme qui casse un scénario ransomware classique où l’attaquant, une fois dans le compte, supprime les sauvegardes avant de déclencher le chiffrement pour forcer le paiement de la rançon.

resource "aws_backup_vault_lock_configuration" "prod" {
  backup_vault_name = aws_backup_vault.main.name
  changeable_for_days = 3   # fenêtre de grâce avant verrouillage définitif
  min_retention_days  = 30
  max_retention_days  = 365
}

Le mode Compliance est irréversible une fois la fenêtre de grâce passée — la seule façon de le lever est de fermer le compte AWS entier, ce qui supprime aussi les backups. C’est une décision à prendre consciemment, pas à cocher par défaut.

Pour une isolation encore plus forte, AWS propose depuis août 2024 le logically air-gapped vault : les copies sont stockées dans un compte géré par AWS, chiffrées, verrouillées par défaut, et partageables en lecture seule via AWS Resource Access Manager pour restauration directe sans dépendre du compte source. En juillet 2026, AWS a étendu la disponibilité de ce vault à six régions supplémentaires — signe que ce mécanisme, initialement pensé pour les grands comptes réglementés, devient un standard accessible aussi aux PME qui traitent des données sensibles (santé, finance, données personnelles).

Elastic Disaster Recovery : seulement si le RTO l’exige vraiment

AWS Elastic Disaster Recovery (DRS) réplique en continu des serveurs (on-prem ou EC2) vers une région AWS, avec un RTO de quelques minutes. Le tarif affiché est simple — 0,028 $/serveur/heure, environ 20,44 $/serveur/mois — mais c’est trompeur : ce tarif ne couvre que le service de réplication. Le coût réel additionne le stockage EBS des copies répliquées et le staging compute, qui représentent généralement les deux tiers du total. Sur l’exemple officiel AWS à 100 serveurs, la facture mensuelle totale atteint environ 6 389 $, soit ~64 $/serveur/mois en moyenne — trois fois le tarif affiché en tête de page.

DRS a un vrai usage en PME : migration de charge on-prem vers AWS avec fenêtre de bascule courte, ou protection d’une charge unique et critique (ERP, plateforme de paiement) qui ne tolère pas plusieurs heures d’indisponibilité. Mais l’activer par défaut sur l’ensemble du parc, « pour être tranquille », revient à payer un PRA de niveau 3 pour un besoin de niveau 1. C’est l’erreur de sur-investissement la plus fréquente qu’on corrige en audit — le miroir exact de l’erreur inverse (pas de PRA du tout) qui domine encore la majorité des PME.

Le minimum viable, concrètement

Pour une PME de 5 à 200 personnes sans obligation de disponibilité continue contractuelle :

1. AWS Backup sur toutes les ressources stateful (RDS, EBS, DynamoDB, EFS), planifié quotidien, rétention 30 jours warm puis cold jusqu’à 1 an.
2. Copie cross-région vers un vault dans une deuxième région AWS — le coût marginal est faible comparé au risque couvert.
3. Vault Lock en mode Compliance, avec une fenêtre de grâce de 3 jours pour valider la configuration avant verrouillage définitif.
4. Un test de restauration trimestriel documenté — pas en théorie, une vraie restauration dans un compte ou VPC isolé, avec le temps réel mesuré et comparé au RTO cible.
5. DRS réservé aux charges où le calcul économique le justifie — comparez le coût d’une heure d’indisponibilité au coût mensuel du niveau 3 avant d’étendre au-delà du périmètre critique.

Ce socle coûte, pour une infrastructure PME typique (quelques centaines de Go à quelques To de données stateful), de l’ordre de quelques centaines d’euros par mois — largement inférieur au coût d’une seule journée d’indisponibilité non planifiée pour la plupart des activités.

Conclusion

Le PRA n’est pas un sujet qu’on peut déléguer à un réflexe technique — « on a des snapshots » — sans jamais poser les deux chiffres qui comptent : combien de données peut-on perdre, combien de temps peut-on rester indisponible. Une fois ces chiffres posés, le choix entre AWS Backup seul, Vault Lock, et Elastic Disaster Recovery devient un calcul économique simple, pas une question de prudence abstraite.

Si votre dernière restauration testée remonte à plus d’un an — ou si vous ne savez pas répondre à la question sans regarder — parlons de votre architecture : un audit de résilience type prend 3 à 5 jours et pose noir sur blanc le RTO/RPO réel de votre infrastructure, avant tout investissement.