Aller au contenu

AWS Mis à jour le 2026-07-04

Déplacer une instance EC2 vers une autre zone ou région : le runbook de copie d'AMI

On ne déplace pas une instance EC2 directement — on l'image et on la relance. Le runbook complet pour déplacer une instance vers une autre zone de disponibilité ou région : création d'AMI, copy-image, réseau et bascule.

Il n’y a pas de bouton « déplacer » pour une instance EC2 : les instances sont clouées à la zone de disponibilité où vivent leurs volumes pour toute leur vie. Le déplacement, c’est toujours imager-et-relancer — créer une AMI de l’instance, la copier vers la région cible si vous traversez des régions (un déplacement de zone dans la même région saute la copie), lancer une nouvelle instance à partir d’elle dans le sous-réseau cible, rebrancher le réseau et le DNS, puis retirer l’originale. Fait dans l’ordre, c’est un runbook sans drame avec une seule fenêtre de bascule planifiée, dimensionnée par la quantité de données qui changent entre l’instantané et la bascule.

Ce qui se passe

Une instance EC2, c’est des métadonnées enroulées autour de volumes EBS, et les volumes EBS existent physiquement dans exactement une zone. C’est pourquoi les déplacements de zone et de région sont la même opération à des rayons différents : empaqueter le volume racine (et les volumes de données) dans une AMI — en réalité un ensemble d’instantanés EBS plus des métadonnées de lancement — puis l’instancier là où vous voulez. Les instantanés sont limités à une région, alors un déplacement inter-région ajoute aws ec2 copy-image pour les expédier; un déplacement de zone exige seulement de lancer dans un sous-réseau de la zone cible, puisque les AMI sont utilisables dans toute la région.

Ce qui ne voyage pas avec l’AMI compte autant que ce qui voyage : l’IP privée (propre au sous-réseau), l’Elastic IP (propre à la région — réassociable entre zones de la même région, inutile entre régions), les volumes instance store (éphémères, jamais capturés dans une AMI), l’ID d’instance (tout ce qui y est accroché — surveillance, licences — doit être mis à jour), et les profils d’instance IAM plus les groupes de sécurité entre régions (les groupes de sécurité sont régionaux et doivent exister dans la cible d’abord). Les volumes chiffrés voyagent bien, mais une copie inter-région rechiffre avec une clé KMS de la région de destination — choisissez-la explicitement plutôt que de laisser le défaut.

Quoi vérifier en premier

  • Les volumes instance store. Les mappages de périphériques de aws ec2 describe-instances : tout ce qui est sur instance store meurt avec l’instance et exige son propre chemin rsync/sauvegarde.
  • Ce qui est accroché aux IP actuelles — enregistrements DNS, listes d’autorisation de partenaires, configs applicatives avec adresses codées en dur. Inter-région veut dire nouvelles IP publiques, point final.
  • Le taux de changement des données. Une base de données occupée diverge de son AMI en quelques minutes; le plan de bascule (gel, synchronisation finale ou réplication) en dépend.
  • Les prérequis côté cible : VPC, sous-réseaux, groupes de sécurité, paires de clés, profil d’instance, et la disponibilité du type d’instance dans la zone ou la région cible.
  • Les contraintes Marketplace ou de licences. Certaines AMI du Marketplace restreignent la copie entre régions; les licences apportées peuvent être liées à une région.

Comment vérifier

Cartographiez ce que vous vous apprêtez à déplacer :

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].[InstanceType,Placement.AvailabilityZone,SubnetId,PublicIpAddress,BlockDeviceMappings[].Ebs.VolumeId]'

Confirmez que la cible offre le type d’instance :

aws ec2 describe-instance-type-offerings \
  --region ca-central-1 --location-type availability-zone \
  --filters "Name=instance-type,Values=m7g.large" \
  --query 'InstanceTypeOfferings[].Location'

Après l’imagerie, suivez la progression de l’AMI et de la copie dans EC2 > AMIs (l’état doit atteindre available avant le lancement) ou :

aws ec2 describe-images --image-ids ami-0abc1234def567890 \
  --query 'Images[].[State,BlockDeviceMappings[].Ebs.SnapshotId]'

Le runbook

  1. Mettez au repos et imagez. Pour tout ce qui a un état, arrêtez les écritures (mode maintenance de l’application ou arrêt propre de l’instance) et créez l’AMI sans --no-reboot pour que le système de fichiers soit cohérent :

    aws ec2 create-image --instance-id i-0123456789abcdef0 \
  --name "web01-move-2026-07-04" \
  --description "Image pré-déplacement incluant tous les volumes EBS"

    Une image à chaud avec --no-reboot est acceptable pour des serveurs surtout statiques; les bases de données méritent le redémarrage ou leur propre export/réplication.

  2. Inter-région seulement — copiez l’AMI (sautez pour un déplacement de zone) :

    aws ec2 copy-image --source-region us-east-1 --region ca-central-1 \
  --source-image-id ami-0abc1234def567890 \
  --name "web01-move-2026-07-04" --encrypted

    Le temps de copie suit la taille des instantanés; les gros volumes peuvent prendre des heures, alors faites-le bien avant la fenêtre.

  3. Préparez la zone d’atterrissage : groupes de sécurité recréés (règles rebranchées sur les groupes côté cible selon le recueil de groupes de sécurité), un sous-réseau de la zone cible choisi délibérément — les questions de conception de sous-réseaux sont couvertes dans la conception de sous-réseaux multi-AZ — paire de clés présente, profil d’instance attaché au lancement.

  4. Lancez et vérifiez en isolation. Démarrez la nouvelle instance depuis l’AMI copiée, puis testez-la directement (sa propre IP, un contournement /etc/hosts ou un nom DNS de staging) avant qu’aucun trafic ne bouge. Vérifiez l’application, les agents, cron et la connectivité sortante.

  5. Synchronisez le delta des données à état. Entre l’imagerie et la bascule, rsyncez les fichiers changés ou rejouez les changements de base de données (réplication native si vous l’avez). Pour un déplacement de zone d’un volume de données dans la même région, un instantané frais restauré dans la zone cible est souvent plus simple qu’une synchronisation fichier par fichier.

  6. Basculez. Même région : réassociez l’Elastic IP à la nouvelle instance — quelques secondes de bosse. Inter-région : abaissez le TTL DNS à l’avance, puis basculez les enregistrements vers la nouvelle adresse, et attendez-vous à des retardataires aussi longtemps que durait l’ancien TTL. Gardez l’ancienne instance arrêtée, pas résiliée.

  7. Retirez délibérément. Après une période de rodage (des jours, pas des minutes), résiliez la source, supprimez les volumes restants, et désenregistrez les AMI et instantanés intermédiaires devenus inutiles — sinon ils se facturent comme stockage d’instantanés pour toujours.

Quand c’est le mauvais choix

Si l’instance est dans un groupe Auto Scaling, ne faites rien de tout ça — mettez à jour les sous-réseaux/zones du modèle de lancement et laissez l’ASG remplacer les instances; déplacer à la main des membres d’ASG combat l’automatisation. Si le vrai but est de survivre à la panne d’une zone, une instance déplacée vers une autre zone reste le même point de défaillance unique à une nouvelle adresse — il vous faut deux instances derrière un répartiteur de charge. Et pour les grands parcs ou les besoins de réplication continue, AWS offre de l’outillage de migration (AWS DRS / Application Migration Service) qui bat les copies d’AMI à la main; voir la documentation EC2 pour les options courantes.

Erreurs fréquentes

  • Imager une base de données occupée avec --no-reboot et découvrir que la copie est incohérente façon plantage au pire moment.
  • Oublier que l’Elastic IP ne suit pas entre régions, puis chercher pourquoi les partenaires frappent encore l’ancienne région.
  • Lancer la copie dans un sous-réseau dont la table de routage ou les NACL diffèrent de la source, de sorte que « le même serveur » se comporte autrement.
  • Résilier la source le même après-midi. L’ancienne instance est votre retour arrière; gardez-la arrêtée jusqu’à ce que la nouvelle ait survécu à du vrai trafic.

Prévention

  • Gardez les AMI dorées et les définitions IaC à jour pour que « déplacer » devienne « lancer notre construction standard là-bas » — la discipline du pipeline d’AMI dorées paie exactement ici.
  • Ne laissez jamais l’identité de production vivre sur une instance : des noms DNS, pas des IP, dans chaque config.
  • Roulez les services à état sur des plateformes gérées (RDS, EFS) dont l’histoire inter-zones est intégrée.
  • Répétez le runbook sur une instance de staging une fois; la première exécution ne devrait pas être celle de production.

Imager, copier, lancer, synchroniser, basculer, retirer — le déplacement lui-même est mécanique; le jugement est dans la synchronisation des données et le moment de la bascule. 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.