Migration de VM vers AWS EC2 : Guide pratique avec Application Migration Service (lift-and-shift)
La migration d’infrastructure vers le cloud représente un enjeu stratégique majeur pour les organisations cherchant à moderniser leur infrastructure informatique. Selon AWS, 75% des charges de travail d’entreprise restent encore sur site, souvent hébergées sur des logiciels vieux de plus de vingt ans. Face à cette réalité, la question n’est plus de savoir s’il faut migrer, mais comment le faire efficacement, avec un minimum de risques et de temps d’arrêt.
AWS Application Migration Service (AWS MGN) s’impose comme une solution particulièrement adaptée pour les équipes DevOps et les architectes cloud qui cherchent à réhoster des machines virtuelles vers Amazon EC2. Contrairement aux approches traditionnelles qui nécessitent de provisionner manuellement de nouvelles instances et de reconfigurer les applications depuis zéro, AWS MGN automatise l’essentiel du processus de migration tout en minimisant les interruptions de service.
Ce guide pratique détaille les étapes concrètes pour migrer une ou plusieurs machines virtuelles vers AWS en utilisant Application Migration Service. Que vous gériez une migration ponctuelle ou que vous planifiez une transformation cloud à grande échelle, cette approche méthodologique vous permettra de comprendre les phases critiques du processus, d’anticiper les points de friction potentiels et d’assurer une transition réussie vers l’infrastructure AWS.
Comprendre AWS Application Migration Service : Une approche lift-and-shift optimisée
AWS Application Migration Service représente une évolution significative dans les méthodes de migration cloud. Le service permet de répliquer des serveurs physiques, virtuels ou hébergés dans d’autres environnements cloud vers AWS, sans nécessiter de modifications applicatives majeures. Cette approche « lift-and-shift » s’appuie sur une réplication continue au niveau des blocs de stockage, compressée et chiffrée, qui assure une synchronisation constante entre les serveurs sources et l’environnement AWS cible.
L’architecture du service repose sur trois composants principaux. Dans le datacenter source, des agents légers installés sur chaque serveur capturent les modifications en temps réel. Sur AWS, une zone de staging héberge des serveurs de réplication temporaires qui orchestrent le transfert des données. Enfin, une zone de ressources migrées contient les instances EC2 finales utilisées pour les tests puis la production. Cette séparation claire entre staging et production permet de valider minutieusement chaque migration avant le basculement définitif.
L’avantage décisif d’AWS MGN par rapport à une migration manuelle réside dans sa capacité à réduire drastiquement la fenêtre de coupure. La réplication continue signifie que seuls les derniers changements doivent être synchronisés au moment du cutover final, transformant une interruption potentielle de plusieurs heures en quelques minutes seulement. Pour les organisations où la disponibilité applicative est critique, cette caractéristique justifie à elle seule l’adoption du service.
Du point de vue réseau, AWS MGN supporte plusieurs topologies de connectivité. Les entreprises peuvent utiliser une connexion Internet publique pour des migrations simples, mais les architectures d’entreprise privilégient généralement AWS Direct Connect ou un VPN site-à-site pour garantir sécurité et bande passante prévisible. Cette flexibilité permet d’adapter la stratégie de migration aux contraintes spécifiques de chaque organisation.
Préparer la migration : Configuration initiale et prérequis techniques
La phase de préparation détermine largement le succès d’un projet de migration. Avant toute installation d’agent, plusieurs prérequis doivent être validés. Le compte AWS doit être actif dans une région supportant Application Migration Service, et une connectivité réseau stable doit être établie entre les serveurs sources et AWS. Cette connectivité peut emprunter différents chemins selon les contraintes de sécurité et de performance de l’organisation.
La configuration IAM constitue la première étape technique concrète. AWS MGN nécessite un rôle IAM spécifique avec la politique AWSApplicationMigrationAgentInstallationPolicy attachée. Ce rôle, généralement nommé MGN_Agent_Installation_Role, permet aux agents installés sur les serveurs sources de communiquer de manière sécurisée avec les services AWS. La bonne pratique consiste à utiliser des credentials temporaires générés via AWS STS plutôt que des clés IAM permanentes, limitant ainsi l’exposition en cas de compromission.
La génération de ces credentials temporaires s’effectue via AWS CLI ou CloudShell avec la commande aws sts assume-role. Les valeurs AccessKeyId, SecretAccessKey et SessionToken obtenues restent valides pendant une heure, délai généralement suffisant pour l’installation initiale des agents. Pour les migrations impliquant de nombreux serveurs répartis dans le temps, cette procédure devra être répétée, ce qui renforce l’intérêt d’automatiser cette étape via des scripts.
Une fois les droits configurés, l’initialisation du service dans la console AWS permet de créer le template de configuration de réplication. Cette étape détermine les paramètres cruciaux de la zone de staging : sous-réseau, type d’instance des serveurs de réplication (t3.small par défaut), type de volume EBS (gp3 recommandé pour l’équilibre coût-performance), et chiffrement des volumes. Pour les organisations disposant d’une connectivité réseau privée vers AWS, l’option « Use private IP for data replication » doit être activée pour éviter de transiter par Internet. Le throttling de bande passante peut également être configuré pour éviter de saturer les liens réseau existants pendant les heures de production.
Exécuter la migration : Installation des agents et réplication des données
L’installation des agents AWS Replication Agent marque le début effectif du processus de migration. Cette opération diffère légèrement selon le système d’exploitation cible. Sur les serveurs Linux, un script d’installation unique télécharge et configure l’agent en utilisant les credentials temporaires préalablement générés. Sur Windows, le processus implique le téléchargement d’un fichier d’installation puis son exécution avec les mêmes credentials.
Dès l’agent installé et les credentials validés, le serveur source apparaît dans la section « Source servers » de la console Application Migration Service. La réplication initiale démarre automatiquement, synchronisant l’intégralité des données du serveur vers la zone de staging AWS. La durée de cette phase varie considérablement selon le volume de données à transférer et la bande passante disponible. Un serveur avec 500 Go de données sur une connexion 100 Mbps nécessitera plusieurs heures de réplication initiale, mais ce temps sera masqué puisque le serveur source reste pleinement opérationnel durant tout le processus.
La console fournit un suivi en temps réel de l’état de réplication via le champ « Data replication status ». Le statut « Healthy » indique une réplication fonctionnelle, tandis que tout autre état nécessite une investigation immédiate. Les causes courantes de problèmes incluent des restrictions firewall bloquant les communications sur les ports requis, des credentials expirés, ou une saturation de la bande passante réseau. La surveillance proactive de ces indicateurs permet d’identifier et de résoudre rapidement les blocages avant qu’ils n’impactent le planning de migration.
Une fois la réplication initiale terminée, le serveur passe en mode de synchronisation continue. Seuls les changements incrémentiels sont désormais répliqués, maintenant la cohérence entre source et cible avec un impact minimal sur la bande passante. Cette phase permet de configurer les paramètres de lancement dans l’onglet « Launch settings » de chaque serveur. Ces réglages déterminent les caractéristiques de l’instance EC2 finale : type d’instance, groupe de sécurité, sous-réseau de destination, et options de stockage. Une configuration précise à cette étape évite des ajustements tardifs durant la phase de cutover.
Valider et finaliser : Tests rigoureux et basculement contrôlé
La phase de test représente une étape non négociable avant tout basculement en production. AWS MGN permet de lancer des instances de test sans interrompre la réplication continue des serveurs sources. Cette fonctionnalité offre un environnement de validation complètement isolé où les équipes peuvent effectuer des tests d’acceptance utilisateur approfondis. La documentation AWS recommande d’allouer au minimum deux semaines pour cette phase, délai nécessaire pour identifier et corriger les incompatibilités potentielles.
Le lancement d’une instance de test s’effectue directement depuis la console Application Migration Service en sélectionnant les serveurs dont le statut « Migration lifecycle » indique « Ready for testing ». L’action « Launch Test Instance » provisionne alors des instances EC2 avec la configuration spécifiée précédemment. Ces instances contiennent une réplique exacte des données du serveur source au moment du lancement, permettant de valider le bon fonctionnement applicatif dans l’environnement AWS cible. Les tests doivent couvrir non seulement les fonctionnalités applicatives mais également les performances, la connectivité réseau, et l’intégration avec les autres systèmes.
Une fois les tests validés avec succès, la phase de cutover peut être planifiée. La meilleure pratique consiste à coordonner cette opération avec toutes les parties prenantes et à prévoir une fenêtre de maintenance durant laquelle un impact utilisateur est acceptable. Le processus de cutover suit une séquence similaire au test : sélection des serveurs, marquage comme « Ready for cutover », puis lancement des instances de cutover. La différence critique réside dans le fait que ces instances deviennent les serveurs de production définitifs.
Durant le cutover, Application Migration Service synchronise les derniers changements survenus sur le serveur source depuis le début de l’opération. Cette synchronisation finale ne prend généralement que quelques minutes grâce à la réplication continue préalable. Une fois les instances de cutover lancées et validées, l’action « Finalize cutover » marque la fin officielle de la migration. Les serveurs sources peuvent alors être désactivés selon le calendrier de décommissionnement prévu.
Les bonnes pratiques pendant cette phase incluent le maintien du serveur source opérationnel jusqu’à la finalisation complète du cutover, la surveillance constante des statuts de réplication pour détecter toute anomalie, et la documentation précise de chaque étape pour faciliter les éventuelles investigations post-migration. Les organisations matures en DevOps automatisent ces workflows via des scripts utilisant l’API AWS MGN, permettant de gérer des migrations à grande échelle avec une intervention humaine minimale.
Vers une migration cloud maîtrisée
AWS Application Migration Service transforme ce qui était autrefois un projet complexe et risqué en un processus standardisé et reproductible. L’approche méthodologique présentée dans ce guide—préparation rigoureuse, installation progressive, tests exhaustifs, et cutover contrôlé—permet aux équipes DevOps de migrer leurs charges de travail vers AWS avec une confiance renforcée et un risque minimisé.
Les organisations qui réussissent leurs migrations partagent plusieurs caractéristiques communes. Elles investissent du temps dans la phase de préparation, notamment la configuration réseau et IAM. Elles ne négligent jamais la période de test, même sous pression calendaire. Elles documentent méticuleusement chaque migration pour capitaliser sur l’expérience acquise. Enfin, elles reconnaissent quand l’expertise externe peut accélérer le processus tout en réduisant les risques.
La migration vers AWS représente bien plus qu’un simple changement d’hébergement. C’est une opportunité de moderniser l’infrastructure, d’améliorer la résilience applicative et de réduire les coûts opérationnels à long terme. Toutefois, la complexité technique et les enjeux business associés justifient de s’entourer d’experts qualifiés qui maîtrisent non seulement les outils de migration mais aussi les subtilités architecturales propres à chaque environnement AWS.
Chez Unicorne, nous accompagnons les entreprises québécoises dans leurs projets de migration cloud, en privilégiant des architectures qui allient performance, sécurité et optimisation des coûts. Notre expertise en migration AWS et notre approche pragmatique permettent de transformer ces projets techniques en véritables leviers de transformation business.
Phase 1 : Configuration IAM et Credentials
| Tâche | Description |
| Créer le rôle IAM AWS Replication Agent | Créer un rôle IAM avec la politique AWSApplicationMigrationAgentInstallationPolicy nommé MGN_Agent_Installation_Role via la console IAM |
| Générer les credentials temporaires | Utiliser AWS CLI ou CloudShell pour exécuter aws sts assume-role et obtenir AccessKeyId, SecretAccessKey et SessionToken (valides 1 heure) |
Phase 2 : Initialisation du service et configuration
| Tâche | Description |
| Initialiser Application Migration Service | Accéder à la console AWS, sélectionner Application Migration Service et cliquer sur « Get started » |
| Créer et configurer le template de Replication Settings | Configurer : sous-réseau staging, type d’instance de réplication (t3.small), type de volume EBS (gp3), chiffrement EBS, groupe de sécurité MGN, IP privée pour réplication VPN/DirectConnect, et throttling réseau si nécessaire |
Phase 3 : Installation des agents et réplication
| Tâche | Description |
| Préparer les credentials AWS | Avoir à disposition les credentials temporaires (AccessKeyId, SecretAccessKey, SessionToken) pour l’installation des agents |
| Installer l’agent sur serveurs Linux | Copier la commande d’installation, se connecter aux serveurs sources Linux et exécuter l’installateur avec les credentials |
| Installer l’agent sur serveurs Windows | Télécharger le fichier d’installation sur chaque serveur Windows et exécuter l’installateur avec les credentials |
| Attendre la réplication initiale | Surveiller la console MGN jusqu’à ce que les serveurs apparaissent avec le statut « Data replication status: Healthy » |
Phase 4 : Configuration des paramètres de lancement
| Tâche | Description |
| Spécifier les détails du serveur | Accéder à la section « Source servers », sélectionner un serveur pour accéder aux détails |
| Configurer les Launch Settings | Dans l’onglet « Launch settings », configurer : type d’instance EC2, groupe de sécurité, sous-réseau, template de lancement EC2, et options de stockage |
Phase 5 : Tests et validation
| Tâche | Description |
| Lancer les instances de test | Vérifier que « Migration lifecycle » = « Ready for testing » et « Data replication status » = « Healthy », puis sélectionner les serveurs et cliquer sur « Launch Test Instance » |
| Vérifier le succès du lancement de test | Confirmer que le statut « Alerts » affiche « Launched » pour chaque serveur |
| Effectuer les tests applicatifs | Exécuter les tests d’acceptance utilisateur (UAT) : fonctionnalités, performances, connectivité réseau, intégration (minimum 2 semaines recommandées) |
Phase 6 : Cutover et finalisation
| Tâche | Description |
| Planifier la fenêtre de cutover | Coordonner avec toutes les équipes concernées pour définir une fenêtre de maintenance appropriée |
| Exécuter le cutover | Sélectionner les serveurs, cliquer sur « Mark as ‘Ready for cutover' », vérifier le statut, puis « Launch cutover instances » |
| Vérifier le succès du cutover | Confirmer que le statut « Alerts » affiche « Launched » pour tous les serveurs de cutover |
| Tester le serveur de cutover | Effectuer des tests de validation pour confirmer le bon fonctionnement en production |
| Finaliser le cutover | Cliquer sur « Finalize cutover » pour terminer officiellement le processus de migration |
Pour plus de renseignements
- AWS Prescriptive Guidance – « Migrate an on-premises VM to Amazon EC2 by using AWS Application Migration Service »
- AWS Application Migration Service User Guide
- AWS – « AWS Application Migration Service »
- Amazon EC2 FAQs
FAQ
Comment migrer une machine virtuelle vers AWS EC2 avec AWS Application Migration Service?
Pour migrer une machine virtuelle vers AWS EC2 avec AWS Application Migration Service, aussi appelé AWS MGN, il faut d’abord configurer le rôle IAM requis et les paramètres de réplication, puis installer l’agent AWS Replication Agent sur le serveur source. AWS MGN réplique ensuite le serveur en continu vers une zone de staging dans AWS. Une fois la réplication stable, les équipes peuvent lancer des instances de test, valider l’environnement, planifier le cutover et finaliser la migration en production sur Amazon EC2.
À quoi sert AWS Application Migration Service dans une migration lift-and-shift?
AWS Application Migration Service sert à réhéberger des serveurs physiques, virtuels ou hébergés dans d’autres environnements cloud sur AWS sans modifications applicatives majeures. Dans une migration lift-and-shift, AWS MGN réplique les serveurs sources au niveau des blocs de stockage, maintient la synchronisation avec l’environnement AWS cible, puis les lance sous forme d’instances Amazon EC2 pour les tests et la production. Cette approche aide les équipes DevOps à migrer des charges de travail vers AWS tout en réduisant le provisionnement manuel et les reconfigurations complexes.
Comment AWS MGN réduit-il le temps d’arrêt pendant une migration de VM vers AWS?
AWS MGN réduit le temps d’arrêt grâce à la réplication continue au niveau des blocs avant le cutover final. Au lieu d’attendre la fenêtre de migration pour copier l’ensemble du serveur, AWS Application Migration Service garde le serveur source et l’environnement de staging AWS synchronisés tout au long du processus. Pendant le cutover, seuls les changements les plus récents doivent être synchronisés, ce qui peut réduire considérablement la fenêtre d’interruption des charges de travail en production.
Que doivent configurer les équipes DevOps avant de migrer des serveurs avec AWS MGN?
Avant de migrer des serveurs avec AWS MGN, les équipes DevOps doivent configurer la connectivité réseau, les permissions IAM, les credentials AWS temporaires et le template de paramètres de réplication. Les éléments clés incluent le sous-réseau de staging, le type d’instance de réplication, le type de volume EBS, le chiffrement EBS, les groupes de sécurité, le throttling de bande passante et la réplication par IP privée lorsque l’environnement utilise un VPN ou AWS Direct Connect. Bien configurer ces paramètres dès le départ permet d’éviter les échecs de réplication et les retards au moment du cutover.
Quelle est la différence entre la zone de staging AWS MGN et les instances EC2 finales?
La zone de staging AWS MGN est un environnement temporaire utilisé pour recevoir et gérer les données répliquées depuis les serveurs sources. Elle contient les ressources de réplication nécessaires au processus de migration. Les instances EC2 finales sont les serveurs migrés lancés à partir de ces données répliquées pour les tests, puis pour la production. Cette séparation entre staging et production permet aux équipes DevOps de valider la migration avant de procéder au cutover final.
Comment tester une VM migrée avant le cutover dans AWS Application Migration Service?
Pour tester une VM migrée avant le cutover, les équipes DevOps peuvent lancer des instances de test directement depuis AWS Application Migration Service lorsque le serveur source affiche un statut de réplication sain et qu’il est prêt pour les tests. Ces instances EC2 de test contiennent une réplique des données du serveur source et permettent de valider les fonctionnalités applicatives, les performances, la connectivité réseau, les groupes de sécurité, les intégrations et les paramètres de lancement avant de basculer le trafic de production vers AWS.
Que se passe-t-il pendant le cutover final d’une migration AWS MGN?
Pendant le cutover final, AWS MGN synchronise les derniers changements du serveur source, lance les instances EC2 de cutover et permet à l’équipe de valider l’environnement de production. Une fois les serveurs migrés confirmés comme fonctionnels, le cutover est finalisé dans Application Migration Service. Les serveurs sources d’origine peuvent ensuite être décommissionnés selon le calendrier prévu par l’organisation.
AWS MGN peut-il être utilisé pour des migrations de serveurs à grande échelle?
Oui. AWS MGN peut être utilisé pour migrer un serveur individuel ou pour exécuter des programmes de migration plus vastes impliquant de nombreuses machines virtuelles. Pour les migrations à grande échelle, les équipes DevOps devraient standardiser les paramètres de réplication, automatiser l’installation des agents, surveiller l’état de réplication et utiliser des scripts ou l’API AWS MGN pour gérer les tests et les cutovers. Cette approche rend le processus plus répétable et réduit les risques d’erreurs manuelles.
Quels sont les problèmes les plus fréquents pendant une migration AWS MGN?
Les problèmes les plus fréquents pendant une migration AWS MGN incluent les credentials temporaires expirés, les règles de pare-feu qui bloquent les communications requises, une bande passante insuffisante, des groupes de sécurité mal configurés, des paramètres de lancement incomplets et des statuts de réplication qui ne sont pas sains avant les tests ou le cutover. Les équipes DevOps devraient surveiller attentivement le champ Data replication status et résoudre les anomalies avant de passer à la phase suivante de la migration.
Quand une entreprise devrait-elle utiliser AWS MGN plutôt que reconstruire ses applications sur AWS?
Une entreprise devrait utiliser AWS MGN lorsque la priorité est de déplacer rapidement des serveurs existants vers AWS, avec un minimum de modifications applicatives et un temps d’arrêt réduit. Cette approche est particulièrement utile pour réhéberger des applications legacy, sortir des charges de travail d’un datacenter sur site ou créer une première phase de migration cloud avant une modernisation plus profonde. La refonte ou le refactoring peuvent venir plus tard, mais AWS MGN permet d’amener les charges de travail sur Amazon EC2 avec une approche lift-and-shift contrôlée.