Aller au contenu

AWS Mis à jour le 2026-09-28

EC2 : arrêter, terminer ou hiberner — ce que vous perdez avec chacun

Arrêtez une instance EC2 quand vous voulez la retrouver telle quelle, hibernez-la quand vous tenez aussi à ce qui est en mémoire, et terminez-la seulement si vous pouvez la reconstruire. Chaque action jette quelque chose de différent, et savoir ce qui survit vous évite de perdre des données ou de payer pour des disques oubliés.

Pour mettre un serveur de développement en pause la nuit ou retirer une vieille instance EC2, tout dépend de ce que vous devez garder. Arrêtez-la si vous voulez retrouver la même machine plus tard, disques intacts. Hibernez-la si vous voulez aussi retrouver sa mémoire, ce qui fonctionne seulement si l’hibernation a été activée au lancement. Terminez-la seulement si vous pouvez la reconstruire, parce qu’il n’y a pas de retour en arrière.

Chaque action jette quelque chose de différent. L’arrêt conserve les volumes EBS (les disques réseau rattachés à l’instance), l’ID d’instance et l’IP privée. Il perd la RAM, tout ce qui se trouve sur l’instance store (des disques temporaires sur l’hôte physique) et l’IP publique attribuée automatiquement. La terminaison supprime l’instance et, par défaut, son disque racine. L’hibernation écrit la RAM sur le volume racine chiffré, pour que la machine reprenne là où elle était. Les erreurs coûteuses viennent presque toujours du même oubli, celui de vérifier où se trouvent vos données avant de cliquer.

Ce que vous décidez

La vraie décision, c’est ce qui doit survivre à la pause, et ce que vous acceptez de continuer à payer pendant la pause.

Arrêter met fin à la facturation du calcul mais garde chaque volume EBS facturé aux tarifs de stockage normaux. Ce qui survit : tous les volumes EBS et leurs données, l’ID d’instance, l’IP privée, les IP élastiques, les interfaces réseau et la configuration de l’instance. Ce que vous perdez : tout ce qui est en RAM, tout ce qui est sur les volumes d’instance store (éphémères) — définitivement, voyez pourquoi les données d’instance store disparaissent — l’IPv4 publique auto-assignée, et votre place de capacité sur l’hôte. Ce dernier point compte : une instance arrêtée n’est pas garantie de redémarrer immédiatement si son type est rare dans la zone.

Terminer met fin à toute facturation de l’instance et, par défaut, supprime le volume EBS racine avec elle — DeleteOnTermination est par défaut à true sur les volumes racine et à false sur les volumes de données ajoutés. Une instance terminée emporte donc habituellement son disque de système d’exploitation dans la tombe mais laisse des volumes de données orphelins (qui facturent encore) dans EC2 > Volumes. Les IP élastiques sont détachées de l’instance mais restent allouées à votre compte, où elles continuent de facturer tant qu’elles sont inutilisées. Il n’y a pas de retour en arrière. La protection contre la terminaison (DisableApiTermination) existe précisément pour ça.

Hiberner est un arrêt qui écrit d’abord le contenu de la RAM sur le volume EBS racine, de sorte qu’un démarrage restaure les processus en cours, les caches et l’état local au lieu d’un démarrage à froid. Les préalables sont stricts : l’hibernation doit être activée au lancement (impossible à ajouter après), le volume racine doit être chiffré et assez gros pour contenir la RAM, la RAM doit respecter la limite prise en charge (jusqu’à 150 Gio selon le type et le système), et le type d’instance et le système d’exploitation doivent la prendre en charge. Une instance ne peut pas rester hibernée plus de 60 jours. Pendant l’hibernation, vous payez le stockage EBS — y compris l’espace qui contient l’image de la RAM — mais aucun calcul.

Quoi vérifier en premier

  • Où sont les données? EBS survit à l’arrêt; l’instance store ne survit ni à l’arrêt ni à la terminaison. RootDeviceType et la table des périphériques de bloc vous disent ce que vous avez.
  • À quoi est réglé DeleteOnTermination sur chaque volume? C’est ce drapeau, pas votre intention, qui décide ce que la terminaison détruit.
  • Quelque chose pointe-t-il vers l’IP publique? Sans IP élastique, un arrêt/démarrage vous donne une nouvelle adresse.
  • L’hibernation a-t-elle été activée au lancement? Sinon, hiberner n’est tout simplement pas au menu pour cette instance.
  • Le type est-il rare? Arrêter une instance GPU ou de toute dernière génération, c’est risquer une bataille de capacité au redémarrage.

Comment vérifier

Vérifiez ce qu’une terminaison supprimerait réellement, et si l’hibernation est disponible :

# DeleteOnTermination par volume attaché, plus le drapeau d'hibernation
aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].[HibernationOptions.Configured,BlockDeviceMappings[].[DeviceName,Ebs.VolumeId,Ebs.DeleteOnTermination]]'

# Ce type a-t-il des volumes d'instance store?
aws ec2 describe-instance-types --instance-types m5d.xlarge \
  --query 'InstanceTypes[].InstanceStorageInfo'

Dans la console, les mêmes faits vivent sous l’onglet EC2 > Instances > Stockage. La protection contre la terminaison est sous Actions > Paramètres de l’instance > Modifier la protection contre la terminaison. La référence complète des changements d’état est à https://docs.aws.amazon.com/ec2/, et si vous pesez l’économie pause-contre-marche, https://calculator.aws/ chiffre honnêtement le coût EBS seul d’une flotte arrêtée.

L’approche

  1. Arrêtez pour les pauses qui se mesurent en heures ou en semaines. Machines de développement la nuit, environnement de test entre les versions, tout ce que vous voudrez retrouver tel quel. Acceptez le changement d’IP publique ou attachez une IP élastique d’abord. Copiez tout ce qui est sur l’instance store vers EBS ou S3 avant d’arrêter.
  2. Hibernez pour l’état de réchauffement coûteux. Si l’instance prend vingt minutes à reconstruire ses caches, charger des modèles en mémoire ou rétablir de longs calculs, l’hibernation rachète ce temps au prix de l’espace EBS pour l’image de la RAM. Décidez au moment du lancement — impossible à ajouter après — et rappelez-vous le plafond de 60 jours.
  3. Terminez tout ce que vous pouvez reconstruire. Si l’instance vient d’une AMI, d’un modèle de lancement ou d’infrastructure en code, la terminaison est l’état final propre : pas de facturation EBS inutile, pas d’inventaire zombie. Prenez un instantané d’abord au moindre doute sur ce qui vit sur les volumes.
  4. Avant de terminer un animal de compagnie, parcourez la liste des volumes. Réglez DeleteOnTermination délibérément, prenez un instantané du volume racine, et vérifiez les IP élastiques orphelines après — les IP non attachées facturent jusqu’à leur libération.
  5. Protégez ce qui ne doit jamais mourir. Protection contre la terminaison sur les singletons avec état, protection d’arrêt sur les instances dont vous ne pouvez pas perdre la place de capacité, et sauvegardes planifiées sur tout ce dont les disques comptent.

Quand c’est la mauvaise approche

Arrêter des instances est le mauvais levier de coût pour les flottes de production — c’est le rôle de l’Auto Scaling, du bon dimensionnement et des rabais d’engagement; un nœud de production arrêté, c’est juste de l’indisponibilité que vous avez planifiée vous-même. L’hibernation est le mauvais outil pour archiver un état de machine à long terme (limite de 60 jours, et une AMI est plus propre de toute façon). Et le réflexe terminer-puis-reconstruire est le mauvais sur une instance dont personne n’a l’AMI ni la recette — l’archéologie sur un disque vivant bat l’archéologie sur l’instantané d’un disque déjà détruit.

Erreurs courantes

  • Supposer que l’arrêt préserve tout — la RAM et l’instance store disparaissent, et sur les types *d (m5d, c6gd, i4i) cet instance store contient peut-être la base de données qui vous tenait à cœur.
  • Terminer avec un volume de données attaché dont DeleteOnTermination est accidentellement à true — c’est le drapeau qui gagne, pas votre supposition.
  • Laisser traîner des instances arrêtées pendant des mois comme « sauvegardes » pendant que la facture EBS s’accumule — une AMI plus une terminaison, c’est moins cher et plus propre.
  • Compter sur l’hibernation pour une instance où elle n’a jamais été activée au lancement, et le découvrir pendant la fenêtre de maintenance.

Garder le contrôle

  • Étiquetez les instances avec un responsable et une politique de cycle de vie (stop-nightly, never-stop, disposable) pour que les changements d’état soient des décisions, pas des accidents.
  • Activez la protection contre la terminaison par défaut sur les singletons avec état; laissez-la désactivée pour le bétail géré par Auto Scaling.
  • Auditez DeleteOnTermination sur les volumes de données lors du provisionnement, pas pendant l’incident.
  • Balayez le compte chaque mois pour les instances arrêtées, les volumes non attachés et les IP élastiques inutilisées — les lignes discrètes d’un compte sans responsable.
  • Préférez les AMI et les modèles de lancement aux instances arrêtées longtemps comme façon de garder « une copie du serveur ».

Les trois verbes sont simples; les pertes ne sont pas symétriques. Sachez ce que chacun jette avant d’avoir besoin de la réponse sous pression. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.