Aller au contenu

AWS Mis à jour le 2026-10-10

Redimensionner une instance EC2 avec un minimum d'interruption (arrêt-changement-démarrage bien fait)

Redimensionnez une instance EC2 en l'arrêtant, en changeant son type et en la redémarrant, avec seulement quelques minutes d'interruption. Les vérifications faites avant l'arrêt évitent qu'un pilote manquant, une IP publique changée ou un manque de capacité transforme ce court changement en panne.

Vous pouvez donner plus ou moins de processeur et de mémoire à une instance EC2, un serveur virtuel d’AWS, avec seulement quelques minutes d’interruption. Quand le disque est sur EBS (le stockage en blocs réseau d’Amazon), la marche à suivre est simple : arrêter l’instance, changer son type, la redémarrer. Le redimensionnement lui-même est la partie facile. Les longues pannes viennent des vérifications qu’on saute avant.

Avant d’arrêter quoi que ce soit, confirmez quatre choses. Le nouveau type doit fonctionner avec votre AMI, l’image machine à partir de laquelle l’instance démarre, et avec ses pilotes. L’IP publique va changer, sauf si vous utilisez une Elastic IP, une adresse fixe qu’AWS vous laisse garder. Les données sur l’instance store, les disques locaux temporaires de certains types, sont effacées à l’arrêt. Enfin, le nouveau type doit avoir de la capacité libre dans votre zone de disponibilité, l’emplacement de centre de données AWS où s’exécute l’instance.

Ce qui se passe

Le type d’instance n’est qu’un attribut de l’instance, mais il ne peut être modifié que pendant que l’instance est arrêtée, parce que c’est le démarrage qui place l’instance sur un hôte physique de la nouvelle taille. C’est dans cette étape de placement que vit le risque : le démarrage peut échouer avec InsufficientInstanceCapacity si le type cible est rare dans cette zone, et le système d’exploitation peut refuser de démarrer si l’AMI n’a pas les pilotes que le nouveau matériel attend.

La compatibilité est la partie qui mérite qu’on ralentisse. On ne traverse pas les architectures de processeur — une AMI x86 ne démarrera pas sur un type Graviton (ARM) comme m7g; cette migration est une reconstruction, pas un redimensionnement. Les types de génération actuelle (Nitro) exigent les pilotes réseau ENA et les pilotes de stockage NVMe dans le système d’exploitation. Toute AMI des dernières années les a, mais une instance de longue date mise à niveau sur place depuis l’ère m3/m4 peut ne pas les avoir, et elle ne se relèvera pas sur un type Nitro. Windows et les vieilles images Linux sont les suspects habituels. Aussi, une instance arrêtée relâche sa place de capacité — voyez ce que l’arrêt vous coûte vraiment — donc sur les types rares, le démarrage n’est pas garanti de réussir immédiatement.

Quoi vérifier en premier

  • Correspondance d’architecture. Le nouveau type et l’AMI actuelle doivent être tous deux x86_64 ou tous deux arm64. aws ec2 describe-instances --query '...Architecture' tranche.
  • ENA activé. Requis pour tous les types de génération actuelle. Vérifiez avant d’arrêter, pas après l’échec du démarrage.
  • Volumes d’instance store. Toute donnée sur disques éphémères est détruite à l’arrêt. Si le type actuel ou cible a de l’instance store, inventoriez ce qui y vit.
  • Dépendance à l’IP publique. Sans IP élastique, l’IPv4 publique change à l’arrêt/démarrage. Trouvez chaque enregistrement DNS, règle de pare-feu et IP codée en dur qui pointe vers l’instance.
  • Protection d’arrêt et comportement d’extinction. Désactivez la protection d’arrêt si elle est active, et confirmez que le comportement d’extinction est stop, pas terminate.

Comment vérifier

Faites les vérifications de compatibilité en une passe :

# Architecture, prise en charge ENA, périphérique racine, type actuel
aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].[InstanceType,Architecture,EnaSupport,RootDeviceType,PublicIpAddress]' \
  --output table

EnaSupport doit être true et RootDeviceType doit être ebs pour un arrêt-changement-démarrage propre. Confirmez que le type cible existe dans la zone de l’instance :

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=location,Values=ca-central-1a Name=instance-type,Values=m7i.2xlarge

Prenez un instantané de sécurité du volume racine (ou créez une AMI) avant de toucher à quoi que ce soit :

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 \
  --description "pre-resize i-0123456789abcdef0 2026-07-04"

Savoir si la nouvelle taille est même le bon choix est une question distincte — les signaux de dimensionnement de Compute Optimizer valent le coup d’œil avant d’acheter une plus grosse machine pour régler ce qui est peut-être un problème d’application. La documentation complète du changement de type est à https://docs.aws.amazon.com/ec2/.

La procédure

  1. Annoncez et planifiez la fenêtre. Un redimensionnement propre, c’est trois à dix minutes d’interruption; engagez-vous sur une fenêtre de trente pour que la reprise de capacité ou un fsck du système d’exploitation ne fasse pas exploser l’estimation. Faites-le à l’heure la plus tranquille de la charge.

  2. Instantané d’abord. L’instantané pré-changement fait la différence entre « on redémarre l’ancien type » et un vrai incident si le nouveau type se comporte mal.

  3. Arrêtez l’instance et attendez l’état stopped. Éteignez proprement depuis le système d’exploitation ou avec aws ec2 stop-instances --instance-ids i-0123456789abcdef0. Si elle reste coincée en stopping plus de quelques minutes, un arrêt forcé est possible, au prix d’un système de fichiers non propre.

  4. Changez le type. Dans la console : EC2 > Instances > Actions > Paramètres de l’instance > Modifier le type d’instance. En CLI :

    aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --instance-type '{"Value": "m7i.2xlarge"}'

  5. Démarrez, et soyez prêt pour une reprise de capacité. aws ec2 start-instances --instance-ids i-0123456789abcdef0. Si le démarrage lance InsufficientInstanceCapacity, ne paniquez pas et ne revenez pas en arrière immédiatement — réessayez quelques minutes, puis repliez-vous sur une taille ou une génération voisine. Le guide complet de cette erreur est dans les contournements d’InsufficientInstanceCapacity.

  6. Vérifiez de l’intérieur vers l’extérieur. Les deux vérifications de statut au vert, les ports d’application qui répondent, et l’application qui utilise réellement la nouvelle capacité (bon nombre de vCPU et mémoire visibles par le système d’exploitation). Si l’IP publique a changé, mettez le DNS à jour maintenant — c’est l’étape que tout le monde oublie.

  7. Surveillez pendant trente minutes. Le comportement des crédits CPU (si vous avez migré vers ou depuis une famille t à capacité extensible), la bande passante EBS (les types plus gros en obtiennent plus) et les taux d’erreur applicatifs comptent. Ils vous disent si le redimensionnement a fait le travail pour lequel vous l’avez engagé.

Quand c’est la mauvaise approche

Si l’instance est dans un groupe Auto Scaling, ne la redimensionnez pas sur place — le prochain événement de mise à l’échelle ou de remplacement annule votre changement. Mettez plutôt à jour le type d’instance dans le modèle de lancement et roulez le groupe; c’est exactement à ça que servent les modèles de lancement, et un rafraîchissement d’instances vous donne une interruption presque nulle gratuitement. Même logique pour tout ce qui est derrière un répartiteur de charge avec plus d’un nœud : montez un remplaçant redimensionné, drainez l’ancien nœud, et sautez complètement la fenêtre d’interruption. L’arrêt-changement-démarrage est le bon outil pour les singletons — la machine de base de données isolée, le serveur d’application patrimonial — pas pour les flottes. Et si l’objectif est plus de disque ou un disque plus rapide plutôt que du CPU/RAM, redimensionnez le volume EBS à la place; c’est une opération distincte qui n’exige aucun arrêt.

Erreurs courantes

  • Sauter la vérification ENA/architecture et découvrir au démarrage que l’AMI ne peut pas démarrer sur le nouveau type — vous voilà en train de déboguer dans la fenêtre au lieu d’avant.
  • Oublier que l’IP publique change sans IP élastique, et passer la fenêtre d’interruption à chasser une « panne réseau » qui n’est que du DNS périmé.
  • Redimensionner une t3 vers une plus grosse t3 pour régler une charge CPU soutenue, quand le vrai problème est les crédits d’extension — une famille t à 100 % soutenu veut une famille m ou c, pas un plus gros seau.
  • Redimensionner un membre d’un groupe Auto Scaling à la main et s’étonner que le groupe le remplace en douce par l’ancien type.

Prévention

  • Gardez une IP élastique ou un nom DNS sur tout singleton auquel les gens se connectent directement, pour qu’un arrêt/démarrage ne déplace jamais la cible.
  • Prenez des instantanés sur un horaire, pas seulement avant les changements planifiés — les redimensionnements imprévus arrivent pendant les incidents.
  • Révisez le dimensionnement chaque trimestre avec des données d’utilisation plutôt que de redimensionner en réaction sous charge.
  • Gardez les AMI à jour pour que la compatibilité ENA/NVMe ne soit jamais une question.
  • Pour tout ce qui compte, roulez deux nœuds derrière un répartiteur de charge — les redimensionnements cessent alors complètement d’être des événements d’interruption.

L’arrêt-changement-démarrage lui-même est la partie facile; les opérateurs qui font ça bien passent dix minutes sur les vérifications et trois minutes sur le changement. 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.