Migrer une machine Linux d’un compte AWS à un autre peut rapidement devenir un enfer : volumes EBS, configurations systémiques, services sensibles, fichiers obscurs… Sans parler des restaurations qui cassent car un driver ou un point de montage ne correspond plus etc.

Hier, j’ai dû déplacer plusieurs instances EC2 d’un compte AWS A vers un compte AWS B.
Et j’ai trouvé une solution plus simple, plus propre, plus fiable : passer par une AMI partagée.

Je te documente tout le process ici.
Tu peux refaire exactement la même chose de ton côté.

Pourquoi les backups/restores Linux sont souvent une galère ?

Quand tu manipules une machine :

  • Volumes critiques montés sur des chemins non standards
  • Services custom avec configs spécifiques
  • Démons qui se lancent au boot et dépendent de fichiers précis
  • Paquets compilés ou installés à la main
  • Fichiers de configuration dispersés partout dans /etc, /opt, /usr/local, etc.

Faire une restauration propre devient difficile — voire impossible — sans perdre des morceaux du système.

Et c’est là que l’AMI devient une vraie bénédiction :
C’est un snapshot complet du système à un instant T, comme une photo figée.

Étape 1 — Transformer l’EC2 en AMI

Je commence dans le compte AWS A.

Je sélectionne la machine → Create Image (AMI).

AWS prend alors :

  • le root volume
  • les volumes attachés
  • la configuration système
  • le bootloader
  • l’état complet de la machine

C’est littéralement une duplication binaire propre.

Assurez-vous d’avoir votre root EBS sélectionné et ‘Delete on Termination’ décoché.

Étape 2 — Partager l’AMI avec un autre compte AWS

Une fois l’AMI créée, je la rends disponible pour mon autre compte (compte B).

D’abord je la sélectionne en allant sur la liste des AMIs puis je clique sur ‘Edit AMI Permissions’.

Une fois sur la page d’Edit, je prends simplement l’Account ID du compte destination, 

puis :

AMI → Modify Image Permissions → Ajouter l’Account ID

AWS permet maintenant au compte B de voir l’AMI dans sa liste Shared with me. 🚀

Maintenant vous pouvez aller voir sur le compte secondaire.

Problème rencontré : l’AMI est dans la mauvaise région

L’AMI partagée est dans eu-central-1 (Frankfurt).

Mais mon compte B travaille dans us-east-1 (N. Virginia).

Une AMI n’est visible que dans sa région.
Pas de magie inter-régions.

Donc je dois copier cette AMI vers ma région cible.

💡 Étape 3 — Depuis le compte AWS B, copier l’AMI vers la bonne région

Je me connecte sur le compte B,
je me mets dans la région Frankfurt,
puis je vais dans Images → AMIs → Shared With Me.

Bingo : l’AMI apparaît.

Ensuite, je lance :

Actions → Copy AMI → Destination region : us-east-1

Cette étape est cruciale parce que :

  • la copie change l’Owner ID : elle devient mon image
  • elle devient utilisable dans ma région
  • elle est totalement indépendante de l’AMI source

Une fois copiée, l’AMI apparaît dans ma liste personnelle d’images dans us-east-1.

Étape 4 — Préparer le réseau (VPC, Subnets, Security Groups)

Avant de lancer l’instance, je m’assure que tout l’environnement réseau est propre.

Je recrée :

  • les Security Groups compatibles avec ceux de l’ancienne machine
  • le subnet adapté (public ou privé selon les besoins)
  • la route table correcte
  • éventuellement le NAT, Internet Gateway, etc.

⚠️ Pourquoi c’est important ?

Parce que si ta machine était initialement dans un subnet public
→ elle doit BOOTER dans un subnet public
Sinon, pas d’accès SSH, pas d’accès internet.

Et inversement pour un subnet privé.

Étape 5 — Lancer la nouvelle instance depuis la nouvelle AMI

Maintenant que tout est prêt, je fais :

Launch Instance → From AMI → Sélectionner l’AMI copiée

Je choisis :

  • le bon type d’instance
  • les bons SG
  • le bon subnet
  • la bonne clé SSH
  • le bon disque EBS (d’ailleurs il doit être par défaut celui contenu dans l’AMI)

En quelques secondes, la machine démarre — exactement comme l’originale, sans aucune modification.

Étape 6 — Reconfigurer l’IP (Elastic IP ou IP privée)

Il ne restait plus qu’à associer :

  • soit une Elastic IP
  • soit la private IP voulue

Et HOP 🤯 :
Tous mes services sont revenus instantanément.
Même configuration, même données, même comportement.

Ce que je retiens ?

👉 Pas de rsync complexe
👉 Pas de sauvegardes volumineuses
👉 Pas de restores aléatoires
👉 Pas trop de config à refaire manuellement

L’AMI partagée + copie inter-régions = la meilleure façon selon moi de cloner/transférer une machine de manière complète, stable et fonctionnelle vers un autre compte AWS. 

Souko deiffei gnou guisseiwate 🚀