Restauration RDS depuis un Snapshot : Nouvelle Instance ou Écrasement ?

Quand une restauration RDS depuis un snapshot devient urgente — après une migration ratée ou une corruption de données — la première question qui bloque les équipes en production est toujours la même : est-ce que ça écrase l'instance existante, ou est-ce qu'une nouvelle instance est créée avec un endpoint différent ? La réponse a des conséquences directes sur la stratégie de bascule et le temps d'indisponibilité.

TL;DR — Restauration RDS depuis un Snapshot

QuestionRéponse
Écrase l'instance existante ?Non. AWS crée toujours une nouvelle instance RDS distincte.
Endpoint identique ?Non. La nouvelle instance reçoit un endpoint différent.
L'instance source est-elle affectée ?Non. Elle continue de fonctionner normalement.
Groupes de sécurité conservés ?Non. Le groupe par défaut est assigné — reconfiguration manuelle requise.
Parameter group conservé ?Non. Le groupe par défaut est appliqué — vérification obligatoire.
Bascule de trafic automatique ?Non. Vous devez mettre à jour les chaînes de connexion manuellement.

Comment fonctionne la restauration RDS depuis un Snapshot

Un snapshot RDS est une sauvegarde du volume de stockage de l'instance à un instant T. Quand vous lancez une restauration, RDS provisionne un nouveau cluster de calcul, attache un volume restauré depuis ce snapshot, et démarre une instance indépendante. L'instance d'origine n'est jamais touchée.

Ce comportement est intentionnel. AWS ne propose pas de restauration 'in-place' qui écraserait l'instance existante. La logique est simple : si la restauration échoue ou si les données restaurées sont incorrectes, vous avez toujours l'instance originale opérationnelle. C'est une protection contre les erreurs humaines, pas une limitation technique.

La conséquence directe : la nouvelle instance reçoit un endpoint DNS généré automatiquement, distinct de celui de l'instance source. Vos applications ne basculent pas automatiquement — elles continuent de pointer vers l'ancien endpoint jusqu'à ce que vous modifiiez explicitement les chaînes de connexion.

graph TD A["Snapshot RDS
Volume à instant T"] --> B["Commande restore-db-instance-from-db-snapshot"] B --> C["Nouvelle Instance RDS
Nouvel endpoint DNS"] B --> D["Instance Originale
Toujours active"] C --> E["Reconfiguration Manuelle
Security Group / Parameter Group"] E --> F["Bascule Applicative
Mise à jour des chaînes de connexion"] D --> G["Suppression optionnelle
Après validation"] style C fill:#2e7d32,color:#fff style D fill:#1565c0,color:#fff style F fill:#e65100,color:#fff
  1. Snapshot source : capture du volume de stockage de l'instance originale à un instant T.
  2. Instance originale : reste active et accessible pendant toute la durée de la restauration.
  3. Nouvelle instance RDS : provisionnée indépendamment avec un nouveau endpoint DNS.
  4. Reconfiguration réseau : groupes de sécurité, parameter group et subnet group doivent être reappliqués manuellement.
  5. Bascule applicative : les chaînes de connexion doivent être mises à jour explicitement pour pointer vers la nouvelle instance.

Paramètres non conservés lors d'une restauration RDS depuis un Snapshot

C'est là que la plupart des incidents post-restauration se produisent. La restauration recrée les données, pas la configuration opérationnelle de l'instance. Plusieurs paramètres critiques reviennent à leurs valeurs par défaut.

Groupes de sécurité : la nouvelle instance est associée au groupe de sécurité VPC par défaut. Si votre instance source avait des règles d'entrée spécifiques — accès restreint à certains CIDR ou à d'autres groupes de sécurité — elles ne sont pas transférées. L'instance restaurée est potentiellement inaccessible ou, pire, trop ouverte selon la configuration du groupe par défaut.

Parameter group : le groupe de paramètres par défaut du moteur est appliqué. Si l'instance source utilisait un parameter group personnalisé — pour ajuster max_connections, innodb_buffer_pool_size, ou d'autres paramètres moteur — ces réglages sont perdus. Une application qui dépend de ces paramètres peut se comporter différemment ou échouer au démarrage.

Option group : pour les moteurs qui utilisent des option groups (Oracle, SQL Server notamment), le groupe par défaut est appliqué.

Classe d'instance : vous pouvez spécifier une classe différente lors de la restauration. Si vous ne la spécifiez pas explicitement, AWS utilise la même classe que celle enregistrée dans le snapshot.

Restauration depuis un Snapshot : Procédure CLI Complète

La commande de base pour restaurer une instance RDS depuis un snapshot est restore-db-instance-from-db-snapshot. Vous devez spécifier un nouvel identifiant d'instance — c'est ce qui confirme qu'une nouvelle instance est créée, pas une restauration in-place.

🔽 Restauration d'une instance RDS depuis un snapshot (CLI) 
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-restored-db \
  --db-snapshot-identifier my-db-snapshot-2024-01-15 \
  --db-instance-class db.t3.medium \
  --db-subnet-group-name my-subnet-group \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-parameter-group-name my-custom-parameter-group \
  --no-publicly-accessible \
  --region us-east-1

Vérifier l'état de la restauration jusqu'à ce que le statut passe à available :

aws rds describe-db-instances \
  --db-instance-identifier my-restored-db \
  --query 'DBInstances[0].{Status:DBInstanceStatus,Endpoint:Endpoint.Address}' \
  --region us-east-1

Lister les snapshots disponibles pour identifier l'identifiant exact à utiliser :

aws rds describe-db-snapshots \
  --db-instance-identifier my-original-db \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Time:SnapshotCreateTime,Status:Status}' \
  --output table \
  --region us-east-1

Stratégie de Bascule après Restauration

Vous avez maintenant deux instances actives : l'originale et la restaurée. La question devient : comment basculer le trafic vers la nouvelle instance avec un impact minimal ?

graph LR A["Instance Restaurée
Disponible"] --> B["Validation des données"] B --> C{"Données correctes ?"} C -->|"Non"| D["Identifier le bon snapshot
Relancer la restauration"] C -->|"Oui"| E["Instance source
en lecture seule"] E --> F["Mise à jour endpoint
DNS ou config app"] F --> G["Validation applicative"] G --> H{"Application OK ?"} H -->|"Non"| I["Rollback vers
instance source"] H -->|"Oui"| J["Suppression instance source
Conserver le snapshot"] style J fill:#2e7d32,color:#fff style I fill:#c62828,color:#fff style D fill:#c62828,color:#fff
  1. Validation des données : vérifier que les données restaurées sont cohérentes avant toute bascule.
  2. Mise en lecture seule de l'instance source : empêcher les nouvelles écritures pendant la bascule pour éviter la divergence.
  3. Mise à jour DNS ou chaînes de connexion : pointer les applications vers le nouvel endpoint.
  4. Validation applicative : confirmer que les applications fonctionnent correctement avec la nouvelle instance.
  5. Suppression de l'instance source : uniquement après confirmation complète — conserver le snapshot original.

Si vous utilisez Route 53 avec un enregistrement CNAME pointant vers votre endpoint RDS, la bascule DNS est plus propre qu'une modification des chaînes de connexion dans chaque service. Mais attention au TTL — un TTL élevé sur l'enregistrement CNAME allonge le délai de propagation.

Penser à la bascule RDS comme à un déménagement d'appartement : les données sont dans les cartons (snapshot), mais vous devez changer votre adresse (endpoint) auprès de tous vos correspondants (applications) manuellement. Personne ne fait ça automatiquement à votre place.

Cas Réel : Le Parameter Group Silencieux

Voici un pattern d'incident qui revient régulièrement. L'équipe restaure une instance MySQL depuis un snapshot après une corruption partielle. La restauration réussit, les données semblent correctes, la bascule est effectuée. Deux heures plus tard, l'application commence à retourner des erreurs de connexion intermittentes sous charge.

Le diagnostic initial pointe vers un problème réseau ou un bug applicatif. Les logs RDS ne montrent rien d'évident. On passe du temps sur les groupes de sécurité, les timeouts applicatifs, les connection pools.

La vraie cause : l'instance restaurée utilise le parameter group par défaut, qui fixe max_connections à une valeur calculée automatiquement en fonction de la mémoire de l'instance — souvent bien inférieure à la valeur configurée dans le parameter group personnalisé de l'instance source. Sous charge normale, le pool de connexions de l'application dépasse la limite, et RDS refuse les nouvelles connexions.

La vérification prend dix secondes :

aws rds describe-db-instances \
  --db-instance-identifier my-restored-db \
  --query 'DBInstances[0].DBParameterGroups' \
  --region us-east-1

Si la sortie affiche default.mysql8.0 au lieu de votre parameter group personnalisé, vous avez trouvé le problème. Appliquer le bon parameter group et redémarrer l'instance résout le comportement. La leçon : toujours vérifier le parameter group actif immédiatement après une restauration, avant la bascule de trafic.

IAM — Permissions Requises pour la Restauration RDS

L'opération de restauration nécessite des permissions spécifiques. Voici une politique IAM minimale pour permettre la restauration depuis un snapshot :

🔽 Politique IAM pour la restauration RDS depuis un snapshot 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestoreFromSnapshot",
      "Effect": "Allow",
      "Action": [
        "rds:RestoreDBInstanceFromDBSnapshot",
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBInstances",
        "rds:AddTagsToResource"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PassSubnetAndParameterGroup",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSubnetGroups",
        "rds:DescribeDBParameterGroups",
        "rds:DescribeOptionGroups"
      ],
      "Resource": "*"
    }
  ]
}

Note : rds:RestoreDBInstanceFromDBSnapshot nécessite "Resource": "*" pour les actions de description. Vérifiez les permissions exactes dans la Service Authorization Reference pour RDS.

Checklist Opérationnelle — Restauration RDS depuis un Snapshot

Avant de basculer le trafic vers l'instance restaurée, vérifier chaque point :

  • ☐ Statut de l'instance restaurée : available
  • ☐ Parameter group correct appliqué (pas le groupe par défaut)
  • ☐ Groupes de sécurité corrects assignés
  • ☐ Subnet group correct (même VPC que les applications)
  • ☐ Chiffrement : si le snapshot est chiffré, la nouvelle instance l'est aussi — vérifier que la clé KMS est accessible
  • ☐ Multi-AZ : à réactiver manuellement si nécessaire
  • ☐ Sauvegardes automatiques : vérifier la fenêtre de backup et la période de rétention
  • ☐ Validation des données applicatives avant bascule
  • ☐ Endpoint noté et chaînes de connexion prêtes à être mises à jour

Conclusion et Prochaines Étapes — Restauration RDS depuis un Snapshot

La restauration RDS depuis un snapshot crée systématiquement une nouvelle instance avec un endpoint distinct. L'instance source n'est jamais modifiée. La bascule de trafic est entièrement manuelle et nécessite une reconfiguration explicite des groupes de sécurité, du parameter group, et des chaînes de connexion applicatives.

Pour aller plus loin :

Glossaire

TermeDéfinition
Snapshot RDSSauvegarde du volume de stockage d'une instance RDS à un instant T, initiée manuellement ou automatiquement.
Endpoint RDSNom DNS généré par AWS pour se connecter à une instance RDS. Unique par instance.
Parameter GroupEnsemble de paramètres moteur (MySQL, PostgreSQL, etc.) appliqués à une instance RDS. Non transféré lors d'une restauration.
Subnet GroupEnsemble de sous-réseaux VPC dans lesquels RDS peut placer l'instance. Détermine l'accessibilité réseau.
Restauration Point-in-Time (PITR)Mécanisme RDS permettant de restaurer une instance à n'importe quel instant dans la fenêtre de rétention des logs de transactions.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite